‘Standard Ligatures’ (liga) feature should not be autogenerated for alphabetic presentation forms

[Rutherford]

When using a font which does not contain a ‘standard ligatures’ (liga) OTL feature, but which does support the Unicode codepoints U+FB01 (‘fi’) or U+FB02 (‘fl’), Affinity Publisher’s default behaviour is seemingly to automatically generate a ligature feature which substitutes these fi/fl glyphs for f_i and f_l combinations.

This is absolutely not what should happen. The U+FB01 & U+FB02 codepoints are legacy alphabetic presentation forms, and type designers (like myself in this case) sometimes include them for compatibility or technical reasons without any intention for them to be used stylistically. If the type designer/font manufacturer chose not to include them in a ‘liga’ feature, Affinity should not assume it was a mistake to be corrected, but should respect the feature code as it appears in the font.

In the case where I discovered this issue, I had included the above codepoints as single-width glyphs in a monospace typeface, so that they appear visually distinct from f_i and f_l character sequences in text. The on-by-default automatic substitution not only looks bad, but actually makes the correct character sequences appear to be incorrect:

I’ve tested this with fonts from other manufacturers and the same behaviour applies. Happy to share an example font if necessary.

(Using Publisher v2.0.4 on macOS 12.6.3; the issue occurs with new and existing documents, apparently with any font which includes the U+FB01/U+FB02 codepoints without a standard ligatures/‘liga’ feature.)

[kenmcd]

IIRC these are in the Auto-Correct (nothing to do with OpenType liga).

Both LibreOffice and Word also have these in Auto-Correct - which often leads to user confusion, and annoyance. 

So check the entries in Auto-Correct.

Note: I have seen some font designers leave these legacy ligature characters out of their fonts to avoid this confusion.

[walt.farrell]

21 minutes ago, kenmcd said:

IIRC these are in the Auto-Correct (nothing to do with OpenType liga).

I do not see any Auto-Correct settings that would affect this.

[Rutherford]

34 minutes ago, kenmcd said:

IIRC these are in the Auto-Correct (nothing to do with OpenType liga).

Both LibreOffice and Word also have these in Auto-Correct - which often leads to user confusion, and annoyance.

I’m not sure I follow. I can understand autocorrect changing the underlying text, but that’s not what’s happening here — the text itself contains f_i or f_l character sequences, which Affinity renders as fi/fl glyphs. Disabling ‘standard ligatures’ in the Typography panel (which I’d argue should not be an option if the ‘liga’ feature isn’t present in the font) prevents the incorrect substitution.

I’m also not seeing the same issue in LibreOffice. Text displays normally, without legacy characters.

[kenmcd]

Sounds like my first guess appears to be wrong.

Interesting note about LibreOffice - maybe they finally removed it, will check that and Word to be sure.

Note: on my phone at the moment so I cannot actually check this in APub until later today.

8 minutes ago, Rutherford said:

but that’s not what’s happening here — the text itself contains f_i or f_l character sequences, which Affinity renders as fi/fl glyphs. Disabling ‘standard ligatures’ in the Typography panel (which I’d argue should not be an option if the ‘liga’ feature isn’t present in the font) prevents the incorrect substitution.

Does your font have no liga feature? Can I test with your actual font? You can send it via PM if need be.

Based your and Walt's comments it sounds like something is wrong, but I will not be able to test this until later today.

[Rutherford]

Thanks for your response!

I’ve put together a demo font (limited character set, but including the fi & fl codepoints) with no OpenType features which I’m happy to share here. The issue is reproducible with it, anyway.

MDIO0.5Trialliga-Regular.otf

[kenmcd]

I was trying to find an old real TrueType font (so no OpenType features) with the legacy ligatures to test before I checked back here - and this is basically what your test font is (so thanks).

This one made me laugh. My reaction was like... WTF?
I guess they are trying to be helpful. 😄
Since it is not in the Auto-Correct, this must be happening in the text shaper.
So the shaper is doing a ligature replacement, even if it is not OpenType.
Unfortunately, even as dumb as this is, this is not likely to get fixed.

Just for the halibut I tested this in InDesign.
It does what you expect - nothing.
The text stays the same. No odd ligatures.
When you highlight the text, a small OpenType logo icon appears.
Click on this icon and it displays a message: "OpenType properties are not applicable."
Which makes sense for a font that contains zero OpenType features.
So ID got that one right.

Work-arounds are:
- turn-off Standard Ligatures (duh)
- remove the legacy ligatures

I do wonder why monospace fonts have any ligatures (makes no sense to me).

I have seen some fonts where the font developer put even these old legacy ligatures into Discretionary Ligatures.
Basically they put all normal text ligatures into dlig.
Wonder how that would work here.
No telling what it will do with it. Could end-up with both, or? Dunno.
Give it a try.
 

Note: I checked both LibreOffice and Word and it appears both no longer do this auto-correct.
So I need to update my personal knowledge-base (brain).
But we do still have to beware of old docs and PDFs which do have these replacements in them.

 

[MikeW]

Dave mentioned this behavior in a different topic. I think. 

[kenmcd]

It's not even an OpenType issue.

It is an old leftover from word processors dealing with all the Type 1 fonts with MacRoman encoding being converted to TrueType. MacRoman encoding includes the fi and fl ligatures. So the word processors had a helpful auto-correct to get those fancy ligatures in these new fangled fonts. I can remember when both LibreOffice and Word still did this. Thankfully they have both removed this "helpful" feature. And obviously ID dumped it too (if it ever had it).

Who is this helping?

With what fonts does this make sense?

Affinity is all about modern OpenType fonts and modern Unicode encoding... and then...

Just mindlessly automatically doing these replacements is like some old dumb word processor. 

Again...

Who is this helping?

With what fonts does this make sense?

 

[MikeW]

I understand it's not an OT feature issue in this thread.

@Dave Harris seems to combine two concepts in that post, one, at the end of the post saying he is using OT feature code if present. But at the beginning of his post he seems  to indicate that if the code points are present, he uses them.

And I agree. It's not desired behavior. 

[walt.farrell]

3 hours ago, MikeW said:

But at the beginning of his post he seems  to indicate that if the code points are present, he uses them.

But they are only used if the user has requested them, either via the OpenType features or the Ligature setting in Positioning and Transform. Thus it's entirely in the user's control, though I suppose one might suggest that the default for non-OpenType ligatures should be off rather than on.

 

[garrettm30]

I don’t think I get the point: as I understand it, if ligatures are available, then I would expect Publisher to use them if the user has enabled ligatures, regardless of whether it is a legacy or OpenType feature in the font. 

[walt.farrell]

1 hour ago, garrettm30 said:

then I would expect Publisher to use them if the user has enabled ligatures

My point was that the ligatures in Positioning and Transform are enabled by default, not necessarily by the user. One could argue that they should be turned off by default, and perhaps the OP and @kenmcd would take that position.

[MikeW]

What Dave has done, by having liga on by default, is according to the spec.

If one is using p.styles and make sure the style has them truly turned off--a check box having 3 states is rather stupid--then that also controls the character tab on/off state button.

However, I would prefer that the character tab setting is off by default. (Well, and check boxes have only two states.) This is how at least two other layout applications handle the situation.

But if Serif really want to follow the spec on this, that multi-state checkbox simply should have the checkmark in it.

[garrettm30]

4 hours ago, walt.farrell said:

My point was that the ligatures in Positioning and Transform are enabled by default, not necessarily by the user. One could argue that they should be turned off by default, and perhaps the OP and @kenmcd would take that position.

That’s fair. I am indifferent on whether the default state of default styles have ligatures turned on or off. I always use my own styles with settings that I have deliberately chosen.

My comment only relates to what should happen if the ligatures are currently turned on for the given text. In such a case, I would expect it to produce ligatures if they are available in the font, regardless of whether it is an OpenType or legacy feature that is being used.

2 hours ago, MikeW said:

--a check box having 3 states is rather stupid--

If you are talking about paragraph & text styles, the three options are indeed helpful. The third option, neither off nor on, is needed for the benefit of child styles. The unchecked means to turn off given feature, no matter what the parent does, while the checked state means to enable the given feature, no matter what the parent does. Both of those overrides the inherited value. The “–” indifferent setting means to inherit the setting of the parent. Inheritance really simplifies a set of styles.

[MikeW]

Unless I am missing use cases, inherited styles as you describe them work just fine without the "middle state."

In other applications, the term often is "based on." When one either creates a new style based on another, all relevant settings are used from the parent. If one modifies an existing style that was not made originally based on another, the settings are then applied to the modified style.

How is that really any different? What does the in-between state in APub really superior?

[garrettm30]

5 minutes ago, MikeW said:

How is that really any different? What does the in-between state in APub really superior?

Checking on or off in a child style is a deliberate decision to be different from the parent, and it will not be affected by subsequent changes to the parent for a given setting.

 

8 minutes ago, MikeW said:

In other applications, the term often is "based on."

I keep one foot in the web development world. My terminology is probably influence by that, notably, CSS in this case. We all understand what we mean: the intermediate setting means “follow whatever parent settings.”

[MikeW]

2 hours ago, garrettm30 said:

Checking on or off in a child style is a deliberate decision to be different from the parent, and it will not be affected by subsequent changes to the parent for a given setting.

The same applies to other applications that use checkboxes for simply on/off.

The so-called inherited state is redundant. It either is or isn't as indicated by the absence or presence of a check mark.

I guess we'll need to agree to disagree about its usefulness. 

[walt.farrell]

3 minutes ago, MikeW said:

The same applies to other applications that use checkboxes for simply on/off.

The so-called inherited state is redundant. It either is or isn't as indicated by the absence or presence of a check mark.

I guess we'll need to agree to disagree about its usefulness. 

Are you considering the case of multi-level inheritance? Parent -> child -> grandchild. With the on/off approach, how would you allow the Parent's choice to flow through to the grandchild? With the on/off/abstain approach you don't need the child to make a choice, allowing a change made in Parent to affect both child and grandchild automatically.

[MikeW]

1 hour ago, walt.farrell said:

Are you considering the case of multi-level inheritance? Parent -> child -> grandchild. With the on/off approach, how would you allow the Parent's choice to flow through to the grandchild? With the on/off/abstain approach you don't need the child to make a choice, allowing a change made in Parent to affect both child and grandchild automatically.

Would you be so kind as to illustrate what parent->child->grandchild means?

If what you mean is like the below, then I guess I know...

In the screen shot below, I created H1, then based H2 on it, then based body as well. The differences are font size/attributes.

I then copied the text frame and duplicated the 3 p.styles.

In the Copy of H1 style, I changed the font, which flowed to the other two p.styles. All other types of attributes contained/alterable in a p.style would do the same.

That said, I cannot remember if I have ever gone 3 deep in an actual job before.

[walt.farrell]

Yes, that's what I meant, @MikeW. 

But please note that the settings in question are yes/no kind of settings. Font, font size, and others don't seem relevant to this discussion.

[MikeW]

Please upload a v.1 file to illustrate what you are getting on about then. Bonus points if the example has some real world relevance. 

How could I illustrate dependance without making a change?

[Old Bruce]

18 hours ago, MikeW said:

Please upload a v.1 file to illustrate what you are getting on about then.

I doubt this will get bonus points as it is about as far from the real world as we can get (I have no descendants).

Inherited or On or Off version 1.afpub

In the real world I find the Inherited state for the Checkboxes quite useful.

[MikeW]

I find nothing in the example that operates differently than any other application using simple based-on...

The only difference are all those indeterminate state checkboxes that could be shown empty and if using the same properties as the based-on, checked. I get that checked in another application does not indicate whether a particular property has been modified after set up. At setup, the p.styles would be identical, though. And, as per your example, the shear naming of the styles should alert the layout person of their use/context.

In other places in the UI, say dropdowns, the terminology is [No change]. I get that Serif may be trying to harmonize the [No change] in dropdowns with the indeterminate state checkboxes due to simplifying the UI space that would have otherwise been required, but I personally find the two-state checkboxes more clear.

And, personally, even in some application setup routines that use indeterminate states, or web forms using some flavor of JavaScript to set indeterminate states (html has no such native capability), less than helpful.

Just a difference between us, I think.

[Old Bruce]

21 minutes ago, MikeW said:

Just a difference between us, I think.

I will bet you are using the Inherited states and you just haven't twigged to it yet. 

As an experiment on some new project use just the On or Off values, no Inherited values.