Unit conversion incorrect in Text Wrap window?

[joe_l]

1. Set up document with mm as unit.

2. Now change the unit on the ruler corner to px.

3. Add an element an give a text wrap.

4. Type 4 mm into one field.

5. Change the unit on the ruler corner back to mm.

Now there are 1,28 mm in the field.

Skipping step 2 and step 5 and switching the units from the ruler corner shows the correct values. I am definitely missing something here, woke up too early. 🤦‍♂️

[Hangman]

Hi @joe_l,

The only way that would happen is if you changed the document dpi from 96 dpi to 300 dpi after Step 4... i.e., before changing the units back to mm in Step 5... In which case this would be the correct behaviour...

[joe_l]

3 minutes ago, Hangman said:

The only way that would happen is if you changed the document dpi from 96 dpi to 300 dpi after Step 4

No. Document dpi was not touched.

[Hangman]

Just now, joe_l said:

No. Document dpi was not touched.

Could you make a quick screen recording as there must be a step missing in the process...

If I follow your steps without changing the document dpi switching the units back to mm still shows 4 mm on both Windows and Mac (for me at least)...

[joe_l]

17 minutes ago, Hangman said:

Could you make a quick screen recording as there must be a step missing in the process...

Looks more like a slide show ... sorry.

 

[Hangman]

On 8/28/2024 at 10:40 AM, joe_l said:

Looks more like a slide show ... sorry.

No problem...

This appears to be a bug on Windows... When entering 4 mm in the Top text entry field, because you have a 300 dpi document the value should change from 15.1 px to 47.2 px (which it does on Mac)...

The value you see after hitting the enter or tab key, i.e., 15.1 px isn't 4 mm, it's 1.28 mm when translated from px at 300 dpi which is why you see what you see...

25.4 mm = 300 px
1.0 mm = 300 / 25.4 = 11.811 px
4.0 mm = 11.811 x 4 = 47.2 px
 

This is how it looks on Mac and how it should work on Windows

[walt.farrell]

I see that same behavior (works on macOS, fails on Windows), too, @Hangman. I think on Windows it's assuming 96 DPI rather than using the true document DPI.

[Hangman]

11 minutes ago, walt.farrell said:

I think on Windows it's assuming 96 DPI rather than using the true document DPI.

Except that Windows correctly translates units in other areas of the UI, e.g., try the same exercise using both a 72 dpi and a 300 dpi document with Paragraph Spacing, say Left Indent...

Change the document from mm to px and you'll see the following:

72 dpi Document - Left Indent

Enter 4 mm and it's correctly translated to 11.3385 px

25.4 mm = 72 px
1.0 mm = 72 / 25.4 = 2.8346 px
4.0 mm = 2.834645 x 4 = 11.3385 px

300 dpi Document - Left Indent

Enter 4 mm and it's correctly translated to 47.2440 px

25.4 mm = 300 px
1.0 mm = 300 / 25.4 = 11.8110 px
4.0 mm = 11.8110 x 4 = 47.2440 px

Switch both documents back to mm and the left indent for both shows 4 mm

[walt.farrell]

3 minutes ago, Hangman said:

Except that Windows correctly translates units in other areas of the UI, e.g., try the same exercise using both a 72 dpi and a 300 dpi document with Paragraph Spacing, say Left Indent...

But for this specific case (Text Wrap Settings), I'm seeing calculations based on 96 DPI on Windows when typing non-px units into the fields, when the document is set to px units. It's wrong, whatever it's doing.

[Hangman]

2 minutes ago, walt.farrell said:

But for this specific case (Text Wrap Settings), I'm seeing calculations based on 96 DPI on Windows when typing non-px units into the fields, when the document is set to px units. It's wrong, whatever it's doing.

I've just rechecked and you're not wrong, it is indeed based on 96 dpi regardless of the document's dpi so definitely wrong...

[Callum]

Hi All, I have logged this with our developers to be fixed and will update this thread once I have more info.

Thanks
C

[Hangman]

Thanks @Callum...

[Affinity Info Bot]

The issue "[Win] Text wrapping unit conversion incorrect" (REF: AF-4226) has been fixed by the developers in the latest beta build (2.6.0.2805). The fix is planned for inclusion in the next customer release.
Customer beta builds are announced here and you can participate by following these instructions.
If you still experience this problem once you are using that build version (or later) please reply to this thread including @Affinity Info Bot to notify us.