Drop Caps disables ligatures

[qarkeed]

It seems like enabling Drop Caps breaks down ligatures, regardless of whether I set the drop caps to affect only the first character, the whole three involved in the ligature, or even in auto mode.

Is this a bug or must I enable some option somewhere for them to work together?

I'm using Affinity Publisher v2.0.4 for macOS 12.6.3.

Thanks!

[walt.farrell]

Sorry, but I don't understand your question. Where, in your screenshots, is there anything that would use ligatures?

[joe_l]

8 minutes ago, walt.farrell said:

Sorry, but I don't understand your question. Where, in your screenshots, is there anything that would use ligatures?

Like this ...

[John Rostron]

@Joe_1, but your dropped characters are lower case, not dropped caps. 

Why should you want to apply ligatures to dropped capitals? I doubt that most fonts would  supply the glyphs!

John

[kenmcd]

Fonts will often use ligatures like that for various alpha-numeric characters (such as round circles with a number inside, etc., etc.).

@qarkeedUse the Glyph Browser to enter the character directly.

What font are you using?

[Alfred]

32 minutes ago, John Rostron said:

@Joe_1, but your dropped characters are lower case, not dropped caps. 

That was my immediate reaction, too!

32 minutes ago, John Rostron said:

Why should you want to apply ligatures to dropped capitals? I doubt that most fonts would  supply the glyphs!

What about Œ, as in Œdipus Rex? 

[John Rostron]

1 hour ago, Alfred said:

That was my immediate reaction, too!

What about Œ, as in Œdipus Rex? 

Or people who use non-standard glyphs in their Member Title.

John

[Alfred]

19 minutes ago, John Rostron said:

Or people who use non-staandard glyphs in their Member Title.

John

Never mind the Member Title! You may recall that I went through a phase of calling myself ‘αℓƒяє∂’ on here.

[thomaso]

4 hours ago, qarkeed said:

It seems like enabling Drop Caps breaks down ligatures,

I can confirm this for V1.

[Old Bruce]

Using the automatic replacement of "fi" with the ligature does not erase the "fi". Copy and paste the ligature or use the Glyph browser and there is no longer an "fi", just the ligature glyph permanently in there instead. So for those times you need the ligature, use the actual ligature. Be aware that not all fonts have all ligatures. Some may have none.

A thought experiment. Type the word fire with automatic ligatures on. Select the f and increase its point size and colour (for purely artistic reasons). Should the i also be changed? 

[thomaso]

5 hours ago, Old Bruce said:

use the Glyph browser

Good point. It seems the auto-ligature doesn't work for drop caps but manually via Glyph browser does … and then requires for drop caps only 1 character instead of 2.

[qarkeed]

On 2/20/2023 at 3:35 PM, walt.farrell said:

Sorry, but I don't understand your question. Where, in your screenshots, is there anything that would use ligatures?

Sorry for not being clear. The rounded black square in the very first line of the picture is produced from a ligature of the '[', '0' and ']' you see in the following lines. Therefore you can see that as soon as drop caps is enabled in any form, the ligature fails to be made.

On 2/20/2023 at 4:11 PM, John Rostron said:

@Joe_1, but your dropped characters are lower case, not dropped caps. 

Why should you want to apply ligatures to dropped capitals? I doubt that most fonts would  supply the glyphs!

John

But that's a choice for the user. Straight up not allowing the ligature it's quite unexpected, if you ask me.

On 2/20/2023 at 4:17 PM, kenmcd said:

Fonts will often use ligatures like that for various alpha-numeric characters (such as round circles with a number inside, etc., etc.).

@qarkeedUse the Glyph Browser to enter the character directly.

What font are you using?

It's a custom font with dice symbols and so on for roleplaying games purposes. Using the glyph browser certainly works around the issue, but I'd love confirmation that this is indeed unexpected behaviour that could be eventually fixed in the future.

On 2/20/2023 at 7:36 PM, Old Bruce said:

Using the automatic replacement of "fi" with the ligature does not erase the "fi". Copy and paste the ligature or use the Glyph browser and there is no longer an "fi", just the ligature glyph permanently in there instead. So for those times you need the ligature, use the actual ligature. Be aware that not all fonts have all ligatures. Some may have none.

A thought experiment. Type the word fire with automatic ligatures on. Select the f and increase its point size and colour (for purely artistic reasons). Should the i also be changed? 

Honestly what I'd expect is that if I type fire with automatic ligatures both the f and i were replaced by the joined ligature. Sort of like autocorrect. But I'm no expert with regards to the consequences that could have.

In any case, to give context to where I originally came across this issue: I was given a file drafted in InDesign by another person and all the dropped caps were wrong as the ligatures were not being displayed. That leads me to think InDesign does apply ligatures in dropped caps if they encompass all the characters, and I think that's a more reasonable behaviour.

[Alfred]

34 minutes ago, qarkeed said:

Honestly what I'd expect is that if I type fire with automatic ligatures both the f and i were replaced by the joined ligature. Sort of like autocorrect. But I'm no expert with regards to the consequences that could have.

One consequence is that editing could be marginally more complicated. Suppose, for example, that you had intended to type “fury” but accidentally hit the i key instead of the u key; an automatic fi ligature in the typed text would mean that you’d have to correct “fi” to “fu” instead of simply replacing one letter.

[Callum]

As far as I'm aware Dropcaps are generally only one character and ligatures convert multiple characters into one single one so I'd expect Dropcaps to disable ligatures once enabled.

Thanks
C

[thomaso]

2 hours ago, Callum said:

Dropcaps are generally only one character

Isn't it up to the user?

However, it may be unclear what is actually expected for "2 characters" in detail as soon as ligatures are involved:

But, imho and in V1, it feels wrong that the "Auto" option is accessible but technically ignored / without function if the involved ligature got typed via the glyph panel:

[kenmcd]

2 hours ago, thomaso said:

However, it may be unclear what is actually expected for "2 characters" in detail as soon as ligatures are involved:

When you select the fl from the Glyph Browser it is a single character (usually).
So the fle is actually two characters.
See more info below.

It does appear that no OpenType features are being applied - including kerning.
So lets say we want to apply a drop cap to the word The and include the Th ligature.
We have to select the Th ligature from the Glyph Browser, and since it is an un-mapped glyph this means it has no Unicode code point(s) - so the first problem is the text is no longer searchable, or cut-n-paste-able, or readable in a text-to-speech reader.
The second problem is there is no kerning so the e is floating out there in the wind.

If OpenType was applied the ligature could work, and the text is still full text.

Many OpenType swash characters would make nice drop caps.
But, same issues as above.
Some OpenType case or titl capitals would make nice drop caps.
But, same issues as above.
Some OpenType stylistic sets characters would make nice drop caps.
But, same issues as above.
Some OpenType character variants characters would make nice drop caps.
But, same issues as above.

Affinity should apply OpenType features to the drop cap text.

 

About typical coded ligatures which may appear in the glyph browser:

[thomaso]

21 hours ago, kenmcd said:

23 hours ago, thomaso said:

However, it may be unclear what is actually expected for "2 characters" in detail as soon as ligatures are involved:

When you select the fl from the Glyph Browser it is a single character (usually).
So the fle is actually two characters.

Well, but I had another aspect in mind: While with a drop cap setting for 1 character the resulting 2 for a ligature may be expected / wanted across various chapter starts in an entire book for instance …

… the resulting number of 2 characters with the ligature appears confusing when "Auto" becomes selected:

[kenmcd]

On 3/4/2023 at 8:12 AM, thomaso said:

… the resulting number of 2 characters with the ligature appears confusing when "Auto" becomes selected:

This one looks like a bug.

In your previous post above the character counts looked correct for the different combinations of separate f and l characters and the single fl ligature character, and the e.

But this one above does not make sense. It appears to be the single fl ligature character and the e character - so it should show 2.

[lacerto]

Obsolete.

[thomaso]

12 hours ago, lacerto said:

It might depend on font (or perhaps the version of the app, these tests were run on v2 beta on Windows),

How does the "Auto" option work in your sample? To me (mac, V1) "Auto" seems to ignore the number in the value field, e.g. 3 …

… and uses 1 instead – but 2 for the ligature from the glyph panel:

[lacerto]

Obsolete.

[kenmcd]

On 3/6/2023 at 3:07 AM, lacerto said:

but it seems that the ligatures that are manually entered from within the Glyphs panel, do retain their text properties in an exported PDF and are searchable and copy-pasteable.

Well that is interesting. Seems to be an improvement from v1.
Could you please attach the PDF so I can take a look?
If they are now picking-up the individual ligature component characters Unicode character codes from a ligature entered from the glyph browser, that is impressive.
And the doc too would be helpful (so I do not have to recreate all you have done).
 

Regarding the ligature search issues, I am focused on what ends up in the output PDF that users are going to read or copy. I guess the usual text-flow issues will apply to any drop caps regardless if the ligatures are encoded properly (as individual characters).

[lacerto]

Obsolete.