Jump to content
You must now use your email address to sign in [click for more info] ×
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Publisher 2.5.0.2463 Clicking before a paragraph moves the cursor to the previous line on Mac


Recommended Posts

4 minutes ago, Hangman said:

Out of interest, did the sample file start life in v2.4.2 or was it created natively in the 2.5 Beta?

The file was probably created back in 2.0.
The file I uploaded to the forum was created in 2.4.2, and I placed the text frame from the 2.0 file into it

Link to comment
Share on other sites

1 minute ago, anto said:

The file was probably created back in 2.0.
The file I uploaded to the forum was created in 2.4.2, and I placed the text frame from the 2.0 file into it

I'll investigate further to see if I can figure out what is going on...

Affinity Designer 2.5.3 | Affinity Photo 2.5.3 | Affinity Publisher 2.5.3
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.5, Magic Mouse

Link to comment
Share on other sites

4 minutes ago, Hangman said:

That makes sense, I figured it must have been created in an earlier version based on a couple of settings in the Text Style Editor...

I did not change the settings of this style from 2.0. I need it for interviews, like dialogs. And today I saw this strange thing in 2.5

Link to comment
Share on other sites

18 minutes ago, anto said:

I did not change the settings of this style from 2.0. I need it for interviews, like dialogs. And today I saw this strange thing in 2.5

I assume it was working correctly in v2.0?

Looking at both the text styles in your source document the option is enabled for both 'TEXT1' and 'Que'...

CaseSensitiveForms.png.f9844bc92e0cc3daef1b0cc1fd9800fe.png

Affinity Designer 2.5.3 | Affinity Photo 2.5.3 | Affinity Publisher 2.5.3
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.5, Magic Mouse

Link to comment
Share on other sites

This does indeed look as though it may be a bug... Like you say this works without issue on Windows even with 'Case Sensitive Forms' enabled though only with the Google Fonts version of Lato... If using the Developer version you will experience the same issue...

Affinity Designer 2.5.3 | Affinity Photo 2.5.3 | Affinity Publisher 2.5.3
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.5, Magic Mouse

Link to comment
Share on other sites

7 hours ago, EmT said:

We have now been able to reproduce this when using the Lato font installed via Creative Cloud. 
This does not appear to occur if you download Lato from Google fonts. 

Lato from Google Fonts is v1.104.
It does not have hyphenminus in the case feature.
So it does not affect this.

Lato from Creative Cloud is v2.015
(also from developer's website, and FontSquirrel, and a few other places)
It does have hyphenminus in the case feature.
hyphenminus is changed to hyphenminus.case
And this appears to confuse things.

 

Link to comment
Share on other sites

20 minutes ago, kenmcd said:

Lato from Google Fonts is v1.104.
It does not have hyphenminus in the case feature.
So it does not affect this.

I can’t recall where I downloaded my version of Lato on Mac though I suspect it was directly from the developers website but the version I’m running does have hyphen-minus along with an En Dash both of which are used in @anto’s file… both appear in the Glyph Browser for the font…

On Windows I did download the version from Google Fonts so I’ll check both versions tomorrow to compare version numbers…

27 minutes ago, kenmcd said:

It does have hyphenminus in the case feature.
hyphenminus is changed to hyphenminus.case
And this appears to confuse things.

Could you explain what that means in practice?

Affinity Designer 2.5.3 | Affinity Photo 2.5.3 | Affinity Publisher 2.5.3
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.5, Magic Mouse

Link to comment
Share on other sites

31 minutes ago, Hangman said:
1 hour ago, kenmcd said:

It does have hyphenminus in the case feature.
hyphenminus is changed to hyphenminus.case
And this appears to confuse things.

Could you explain what that means in practice?

The OpenType Case Sensitive Forms (case) feature is most commonly used to move punctuation, various dashes, etc. up just a bit so they align better with uppercase characters.
When this OpenType replacement is done in Lato 2 the hyphenminus glyph is replaced with an alternate glyph named hyphenminus.case.

For example - below is Lato v2.015 with a few of the characters.
The hyphenminus is the dash.

case-hyphenminus-2024-05-21_13-50-53.thumb.gif.61e613bfbd92b97c3f08fd99e84d0b45.gif

There have been some other issues when OpenType glyph replacements are done which have broken the text runs, or paragraph breaks, etc.
This appears to be an issue with the Affinity text shaper.

Link to comment
Share on other sites

I assume hyphenminus.case would or should have a different Unicode Reference from the standard ‘hypenminus (U+2013) glyph and likewise the En Dash (U+002D) should too in its endash.case form or is that not so?

Affinity Designer 2.5.3 | Affinity Photo 2.5.3 | Affinity Publisher 2.5.3
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.5, Magic Mouse

Link to comment
Share on other sites

37 minutes ago, Hangman said:

I assume hyphenminus.case would or should have a different Unicode Reference from the standard ‘hypenminus (U+2013) glyph and likewise the En Dash (U+002D) should too in its endash.case form or is that not so?

No. The Unicode code point stays the same.
Just the glyph (or shape) associated with that code point is substituted.
This is the way OpenType substitutions work (generally).

Same thing when the first A in a word is replaced with a swashy A.
The code point does not change - just the glyph changes (the shape changes).
It is still a Unicode A - so search still works, screen readers still work, copy-and-paste still works, etc.

Tabular Lining figures are still the same code points as Proportional Oldstyle figures.
They look different, but they are still the same numbers (same Unicode code points).
The glyphs are substituted for those code points to get the different shapes.

It appears that sometimes when these OpenType substitutions are done the Affinity text shaper, which is doing these substitutions, appears to get a bit confused.
This appears to be one of those cases.

Link to comment
Share on other sites

18 hours ago, EmT said:

We have now been able to reproduce this when using the Lato font installed via Creative Cloud. 
This does not appear to occur if you download Lato from Google fonts. 

Hi @anto,

Just to confirm what @EmT and @kenmcd have said above...

I've tested the official developer release of Lato on both Mac and Windows, i.e., v2.015 and as mentioned, this version does cause the case issue when running in the Affinity apps...

The Google Fonts edition of Lato, v1.104 doesn't, though there are only ten weights in the Google Fonts version of Lato vs eighteen weights in the official version on the Developer's website...

Hopefully, the Developers (at Serif) can take a look into this specific issue and find a solution...

Affinity Designer 2.5.3 | Affinity Photo 2.5.3 | Affinity Publisher 2.5.3
MacBook Pro M3 Max, 36 GB Unified Memory, macOS Sonoma 14.5, Magic Mouse

Link to comment
Share on other sites

11 hours ago, Hangman said:

Hopefully, the Developers (at Serif) can take a look into this specific issue and find a solution...

They kinda have to - this is very common in the case feature.
So it is going to be an ongoing issue.
My guess is the interaction of the case substitution with the handling of the hypenminus, hyphen, and the softhyphen is the issue.
 

11 hours ago, Hangman said:

The Google Fonts edition of Lato, v1.104 doesn't, though there are only ten weights in the Google Fonts version of Lato vs eighteen weights in the official version on the Developer's website...

Lato v1.104  vs.  Lato v2.015
10 styles  vs.   18 styles
275 glyphs/261 characters  vs.  3,023 glyphs/2,163 characters
Latin (basic) script  vs.  Latin (extended), Greek, and Cyrillic
4 OpenType features  vs.  22 OpenType features
So v2 is a much more advanced font.

And the character spacing is tighter in v2.
Which is why GF reversed it back to v1 - reflow issues caused a large user reaction.

Lato v3 development is currently stalled.
When that ever gets finished it will end up in GF, but probably named Lato 3.
 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.