[Setting custom dpi on Windows 10 crashes Affinity]

@Callum

Hi there!

One more thing: I've installed Affinity 2.1.0 on another PC with an AMD card (RX 5700xt) and set the display scaling to 115%, too. Result: no issues. So, with my devices the crashes happen only on the nVidia machine.

Best,
Volker

 

[Setting custom dpi on Windows 10 crashes Affinity]

On 5/30/2023 at 1:34 PM, Callum said:

Hi VolkerMB,

I'm struggling to recreate this crash here, just to clarify are you using the display scaling slider or setting a custom value using the advanced scaling setting? If you are are using a custom value which value are you entering?

Thanks
C

Hi @Callum,

thanks for looking into that.

Some infos about my system: Windows 10 22H2 (built 19045), Intel i7-7500U, 16 GB RAM, nVidia Geforce 940MX with driver version 531.79, Windows custom scaling set to 115%.

The same laptop worked fine with Affinity 2.0.4 and still does with 1.10.6, but crashes with 2.1.0 without warning or crash report as described initially.

Best,
Volker

 

[Setting custom dpi on Windows 10 crashes Affinity]

Hi there!

While 1.10.x and 2.0.4 do work fine at my end with setting custom dpi to anything but 100/125/150/175%, the new 2.1.0 doesn't. That is a step backward.

The Affinity apps do start despite having set Windows 10 to a custom dpi value, but the moment I want to call the colour dialogue in Affinity the apps crash without any warning or any crash report. The are also reports here in the forum that it does happen with the gradient tool, too.

Would be highly appreciated if this regression could be fixed with the next version/update.

Best, Volker

[Getting ICC profiles to work on Win 10]

Okay, I am back in business! How so?

After I had done the test drive with my friend's Benq display I encountered some wiered situations with my original display configuration: During a session with Affinity Photo both my display went black. Only a restart brought the displays back. The same happend two more times the next day. The reason: Windows switched back to its basic display drivers and discarded AMD's drivers. In total I had to reinstall them three times.

Fortunately I got hold of a used Nvidia RTX 2070 and installed it. What can I say? Colors are rendered correctly on both screens and Windows sticks to Nvidia's drivers. Apparently something was wrong with either my RX 5700xt or AMD's drivers. Who knows...

So, thanks for all the input and suggestions. They've deepend my understanding of color management a lot.

[Getting ICC profiles to work on Win 10]

Just want to report the results of a test drive: Thanks to a friend I was able to connect a Benq display to my computer. To no avail. With my friend's computer the Benq rendered decent colors (also in combination with a LG-sRGB-display next to it), but with my computer it is a different story (yes, I used a fresh icc profile I created with my X-Rite colorimeter). Therefore, I took the Eizo to my friend's place to test it with his computer. The result: decent colors.

So, my conlusion is: Something is broken or misconfigured under the hood of my pc. But without a degree in computer science I might not be able to get to the core of the issue. On the surface everything looks configured correctly, but somehow it is not. At least I can roule out that the display hardware is broken.

On a sidenode: If I switch off icc settings with my second display (Dell) and let Windows decide how to address colors, both monitors look very similar in terms of tonality (temperature). Still, the Eizo is way oversaturated and overly bright, but the Dell shows warmer colors now. If I go back to icc profiles for the Dell, it renders colors much cooler, darker and dull, again. 

Next, I will try to get hold of a different graphics adapter...

 

[Getting ICC profiles to work on Win 10]

@rvst At least Windows flags the sRGB IEC61966-2.1 profile as a display profile... But I am not an expert.

Therefore, I did install a dedicaded profile for the Dell U2417H from TFTCentral as suggested by @v_kyr. However, my eyes don't spot a difference to the sRGB IEC61966-2.1 profile. After having looked at several test images for at least 10min I'm under the impression that there is a tiny, tiny, tiny difference in how green is rendered. But apart from that...

Unfortunately the Dell display is not the troublemaker here. It is the Eizo display. So, I called some friends and get hold of a Benq wide gamut monitor which I will install later today for test purposes. I'll report back later.

[Getting ICC profiles to work on Win 10]

I made a simple test without using any photo. I just created a new document in sRGB color space in APhoto 2 and draw some rectangles on it. One in orange, one in green and one in purple. It renders completely different on both displays.

Then I switched the Eizo internally to sRGB (and changed the Windows color management for the Eizo to sRGB as well) and compared both displays. Now, they are in line (almost). Which, again, leaves me to believe that something is broken here. 

[Getting ICC profiles to work on Win 10]

@debraspicher Sorry for the somewhat snarky comment at night time.

Apparently I didn't explain the situation well enough. So, here is my second attempt:

• My computer runs Windows 10 (22H2) and features a AMD Radeon RX5700XT graphics adapter.
• Windows own color management is configured to use a bespoke AdobeRGB color profile for my first display (EIZO) and a standard sRGB profile for my second dsiplay (DELL).
• The profile has been created by me using Eizo's ColorNavigator7 and the X-Rite i1 Display pro colorimeter. The color space target was AdobeRGB.
• The Eizo display itself is set to AdobeRGB while there is no such setting for the Dell display (it is not capable of displaying anything beyond sRGB).

I am aware the the Windows UI and plenty of apps are not color managed at all. But: Lightroom, DXO Photolab and the Affinity apps are color managed. Let us focus on them - and how colors are actually rendered in these apps on my systems.

One example: Affinity Photo 2 is set to AdobeRGB as the standard color space. So any new document using the standard color space will show quite powerful colors on the Eizo display and "muted" colors on the Dell display. That is expected.

However: If I create a new document within the sRGB color space in Affinity, I only expect a mild difference in rendering the image on both displays. As sRGB is the much smaller color space, the color managed Eizo should be able to reproduce the colors propperly. But that is not the case. They remain unnaturally bright and powerful as if they were still in AdobeRGB. 

I took a laptop of mine with a sRGB display and hold it next to the Dell display. The result: very minor differences in color rendering. So, I guess the Dell renders the sRGB colors decently. With the Eizo it is a different story - no matter what I set as the color space in Affinity. Always bright and oversaturated (skin tones are a joke).

The same behaviour is visible with Lightroom and Photolab. It looks as if there is no color management at all.

So, I'm lost.

 

 

 

 

[Getting ICC profiles to work on Win 10]

Well, I doubt that the CS240(28990025)03AdobeRGB.icc is a standard profile shiped with the display instead of a bespoke one. And the last time I checked I was able to tell the difference between a tiny button on my monitor from an iStudio colorimeter.

However, thanks for looking into the issue.

[Getting ICC profiles to work on Win 10]

3 hours ago, debraspicher said:

Each display must be calibrated individually. It can be done manually or with hardware (x-rite, etc). Hardware creates an individualized ICC profile for each monitor that contain the adjustments required for the LUT table to match. No match is perfect though, so there will always be some variation. Generally, this is done monthly because monitors change over time or as often as the user requires. For example, projects that require working with delicate spot colors.

I couldn't agree more. But my displays are hardware calibrated on a regular base and use that specific profile. However, the contrast in colour between the two displays is so strong, that I have a hard time to believe that everything works according to plan.

@v_kyr Thanks for that link. Looks like a long read...

[Getting ICC profiles to work on Win 10]

Hi there!

I've an issue with colour management on Windows 10 (22H2) that is not limited to Affinity. But in the Affinity Apps the issue is clearly visible - and drives me nuts!

That is my setup:

• Windows 10 (22H2), AMD Radeon RX 5700 XT
• 1. display: EIZO CS240, runs in AdobeRGB mode
• 2. display: Dell U2417H, runs in sRGB mode
• Windows Color Management: Display 1 set to individual ICC profile (AdobeRGB, created by ColorNavigator7)
• Windows Color Management: Display 2 set to sRGB IEC61966-2.1 (see screenshots)

One would expect that all colors that are within the sRGB range are displayed in the same way on both monitors (at least in color managed applications). But that is not the case. On the EIZO everything is saturated and bright, on the DELL all colors are dull and dimmed. As if Windows doesn't respect the ICC profiles.

If I add a sRGB softproof layer in Affinity (1.10.6) in a AdobeRGB document the EIZO shows also no difference in color - which surprises me.

Any ideas what I am doing wrong?

Thanks,
Volker

 

[Using "New From Clipboard" Pastes Incorrectly in Affinity Photo 2.0.3]

I did run some tests to verify what I claimed to have discovered... Well, it is complicated...

Test A

1. Started Firefox and XnViewMP, but not Affinity.
2. Grabbed a screenshot of the browser.
3. Created an empty image in XnViewMP and pasted the screenshot in it.
4. Result: Everyting is displayed correctly.
5. Started Affinity and pasted screenshot via "new from clipboard"
6. Result: The screenshot ist broken (by 3 pixels on the left that belong to the right side)

Test B

1. Started Firefox, XnViewMP and Affinity.
2. Grabbed a screenshot of the browser.
3. Created an empty image in XnViewMP and pasted the screenshot in it.
4. Result: Everything is displayed correctly.
5. Pasted the same screenshot in Affinity via "new from clipboard".
6. Result: The screenshot is broken.

Test C

1. As 1 - 6 in Test B.
2. Created an empty document of 1920 x 1080 px and pasted the screenshot in it.
3. Result: still broken.

Test D

1. Started Firefox, XnViewMP and Affinity.
2. Grabbed a screenshot of the browser.
3. Created an empty image in XnViewMP and pasted the screenhot in it.
4. Copied within XnViewMP the pasted screenshot to the clipboard.
5. Pasted the image in Affinity via "new from clipboard".
6. Result: Image looks fine.

So, somehow Affinity treats screenshots made by Windows differently from image data transfered via clipboard from other apps.

 

 

 

[Using "New From Clipboard" Pastes Incorrectly in Affinity Photo 2.0.3]

It is not just Affinity that is affected by the issue. I've just tried to paste a screenshot in a new image using XnViewMP with the same outcome: The three right-most pixel are placed on the left side of the pasted image. However, if I do a second screenshot it gets pasted correctly once in a while. Again, if I copy the incorrectly pasted image from XnViewMP and paste it in Affinity, the offset is gone... Unfortunately I can't reproduce this behaviour every single time. To me it looks very random. So it might be a issue with Windows? (in my case: Win10 22H2)

 

[Affinity Designer V2 getting really slow and laggy after some time]

20 hours ago, Dangerous said:

Have you tried the 22H2 update?

 

I am on 22H2 already... 😞

[Affinity Designer V2 getting really slow and laggy after some time]

It seems that all the apps have lost steam... at least on my computer (Ryzen 7 3700, 32GB RAM, 1TB SSD, RX5700XT (8GB)). I've encountered a similar problem to @4dimage with the glyph browser, too. Without having measured it precisely, I'd say all V2.0 apps run half as fast as V1.x, sometimes even slower. Currently I prefer to use the older iterations of the Affinity apps if none of the newer features are required for the job.

Let's hope, V2.0.1 will fix some of the issues.

[Affinity Publisher: Hyphenation bug]

Hmm, I'm not convinced that we really deal with a problem here. If your document is meant for printing then it is no fun at all for users to read these long URLs or even to type them in a browser to get to the ressource. A shortend ULR would serve the user better. But if the original URL is needed under all circumsdances (e.g. legal reasons) putting it in a footnote/endnote (haha, good joke ;-)) with manually set line breaks could be the better option. The average user is capabale of reading them properly (as far as my eperience goes).

[Affinity Publisher: Hyphenation bug]

@Pyanepsion Hi, I can confirm this. However, is it relevant?

Usually, if you want to include a hyperlink to your document you use the hyperlink panel. Here, no line break of any sort is inserted and the hyperlink does work just fine in the final PDF. So, the display of the link to the human eye is not that relevant.

Indeed, it is a different story with pasting such long URLs in a document without setting a hyperlink explicitly. Then it comes down to the guesswork by any pdf reader what the correct URL might be. And - in case of Acrobat - it fails.

[Hyphenation in exported svg files could be improved]

Hi,

today I came across an interessting behaviour of exported svg files... and I am not sure whether its a shortcoming or a bug - and who is to blame!

I was creating a larger graphic with some text frames in AD. For a proper text flow I inserted manually some soft hyphens and exported the design in the svg format eventually. In order to keep the file size small, I did not convert the text to curves.

Afterwards I imported the svg file to MS Word (current version). The within the imported graphic displayed an interesstion behaviour: Whenever a hyphen was needed to smoothen the text flow within the graphic Word inserted another hyphen. So I ended up with "--" instead of a simple "-" plenty of times when a line had to be wraped. It doesn't matter whether automatic hypenation ist switched on or off in Word.

You'll find all files needed to recreate the issue attached.

Cheers, Volker

 

textumbruch.afdesign textumbruch.svg

[HELP! Printing PDF Designs - GREY PRINTING BROWN?!]

Indeed, it looks like a color management issue. Has Cancon provided any ICC profiles with the printer as they usually sort out these issues?

[Fehler bei Textumbruch]

Hallo Herby,

aus mir nicht bekanntem Grund ist die sog. "Umbruchkontur" weit nach rechts ausgedehnt (siehe Screenshot 2). Entweder Du nutzt den Befehl "Umbruchkontur bearbeiten" oder setzt sie mit "Umbruchkontur zurücksetzen" wieder auf den Ursprungswert zurück (siehe Screenshot 1). Dann verschwindet  der auf der rechten Seite entstandende Leerraum.

VG, Volker

[Fehler bei Textumbruch]

Hallo Herby49,

APub verhält sich hier korrekt. In dem Dialogfenster "Textumbruch" wird der (äußere) Abstand zu den umgebenden Elementen festgelegt. Wenn der Text im Rahmen selbst (also die Bildzeile) mehr (Innen-)Abstand bekommen soll, ist dieses im Dialog "Textrahmen" (Menü: Ansicht -> Studio -> Textrahmen) festzulegen. Siehe beigefügten Screenshot.

Viele Grüße,
Volker

[Older documents shut down APub .1127 + .1135 immediately]

Thanks @Pauls for looking into these files.

Unfortunately your workaround doesn't work for me. No matter where the files are located, APub (.1127 + .1135) crashes while loading. However, these files open fine with APub 1.9.2. So I used the older version to replace the ressources in question and saved the files under a new name. Now, they open fine with APub .1134

Nevertheless, APub 1.10 shouldn't crash because of a missing(?) ressource.

Best, Volker

 

 

[Older documents shut down APub .1127 + .1135 immediately]

@Pauls Done! Thanks for looking into the issue.

[Older documents shut down APub .1127 + .1135 immediately]

Hi,

unfortunately roughly 3 out of 10 of my older APub documents (created with versions 1.7, 1.8 and 1.9 in the first place) do crash the current retail version (.1127) and the latest beta version (.1135) of Publisher. APubs quits while loading without an warning. Two dump files of the latest crashs are attached.

Fun fact: The next time I start APub it offers me to open a recovery file - which causes APub to crash as well.

In case you need the files causing the issue, please do provide me with an upload link.

Best, Volker

 

b88c0894-3c82-4a75-8f39-d5b03bfd5e9c.dmp 764c60d5-e059-40d1-81cc-7ebeed4689b9.dmp

[Please force integers on Artboard pixel dimensions]

I know it is my fault, however, every time I use artboards I run into this issue. And it takes some extra steps to correct it (I always exort it first before I realize something is wrong...).

One example: Create two artboards of size A4 with "force pixel alignment" and "move by whole pixels" switched on. The initial position of the artboards is fine, but the size is not: 2480,3 x 3507,9 px. If you move one of the artboards for any reason and let it snap to the other one you are in trouble afterwards. When moving the artboards now, the position is never an intereger value again but a floating one.

The solution is to swich off "move by whole pixels" so that the artboard position can fall back to full interger values. However, it is a bit counter-intuitive... Maybe a different default setting could help.