Jump to content
You must now use your email address to sign in [click for more info] ×

Specific Drop Cap Letter combo not working "Th..."


Recommended Posts

Here is a very specific killer bug, Drop Cap won't work with a particular letter combonation with certain fonts. The "T" in "The" stays normal but the "H" in "Here" will have the drop cap applied.
I made a style based on 'no style' I changed the font-face, weight, height, leading, first line indented to 10 mm and justification (full with last line left). I called it "Bulk Text" then I made a second font and called it "Drop Cap" based on "Bulk Text". I changed the first line indented to zero mm and set the drop cap to three lines. Worked fine unless I used an Open Type Font from Adobe. Most of them were okay. The "T" would not become a drop cap if it was before an "h" as in The, This, That, There Thursday etc. All other letter combonations worked a treat with any and all fonts. Okay I didn't check ALL possible combos I'd still be working on checking if I tried that.
Adobe Caslon Pro, Adobe Garamond Pro and Adobe Jenson Pro are the ones I noticed it most with.

Courier.jpeg.ddc71c908a4993e076e2bb4330c854f3.jpeg

 

Caslon.jpeg.a211996b7de6d8d5c17354ec6d7e1d06.jpeg

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

In the example you show that didn't work, the Th is a ligature. Perhaps you need to disable ligatures, which would give you individual letters, in order to get the drop cap to work?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

By the way, it does no only happen with standard ligatures, but also with discretionary ligatures. I would probably suggest that Publisher should automatically disable ligatures for the initial word of a paragraph when drop caps are used.

The example below is Hypatia Sans Pro that has, among others, the WY discretionary ligature.

WY.png.34184364f5d50484bc86fee83b9a57e1.png

Link to comment
Share on other sites

29 minutes ago, A_B_C said:

...I would probably suggest that Publisher should automatically disable ligatures for the initial word of a paragraph when drop caps are used...

It is important that ligatures are decomposed, not disabled. Decomposed simply means to use the base glyphs for the DC. The Unicode for this is exposed behind the scenes. If Ligs were disabled, but desired in subsequent paragraphs then certain letter combinations would be different from the DC paragraph to those that follow it.

Dave knows how to do this in the code.

****Edit to add****

Until such time as it works as expected, you could highlight those two characters (e.g., F h) and turn ligs off for them when at a paragraph start in a DC paragraph.

Link to comment
Share on other sites

Turning off "Standard Ligatures" in the first style  did it. Thanks all. Not a bug after all.

Also just use the "option right arrow" key combo to loosen the letters while the ligatures are on. That would be better for the edge cases.

Edited by Old Bruce
had another thought.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

21 hours ago, MikeW said:

It is important that ligatures are decomposed, not disabled. Decomposed simply means to use the base glyphs for the DC. The Unicode for this is exposed behind the scenes. If Ligs were disabled, but desired in subsequent paragraphs then certain letter combinations would be different from the DC paragraph to those that follow it.

Dave knows how to do this in the code.

****Edit to add****

Until such time as it works as expected, you could highlight those two characters (e.g., F h) and turn ligs off for them when at a paragraph start in a DC paragraph.

Drop Caps can apply a character style to the affected characters, and you can use that character style to turn ligatures off. If you turn the drop cap format into a paragraph style, it will then disable ligatures automatically.

Link to comment
Share on other sites

1 hour ago, Dave Harris said:

Drop Caps can apply a character style to the affected characters, and you can use that character style to turn ligatures off. If you turn the drop cap format into a paragraph style, it will then disable ligatures automatically.

OK. I think Ligatures, and by extension, decomp of them, is broken.

Try this, Dave. Using my font you have, make a text frame, fill with (editable) placeholder text. Make the first word This.

You should see that there is displayed a Th ligature, correct? But here's the deal. I don't have a Th lig in that font. APub (nothing, really) ought to be making one if not present.

Now do a drop cap on that first paragraph using a p.style. It then "decomposes," right? But again, it's not even in my font. I just added a Th ligature in my font and now it does not work.

Try Adobe Caslon Pro, change it in your style. It does have the Th lig. And it works (even in XDP...). You will not any longer have a drop cap. Not in the current beta anyway.

Mike

Link to comment
Share on other sites

Ok. I do think ligs + drop caps are broken.

But half my issues above were due to APub not updating the display when I was altering my font back and forth--despite the notice the font cache was being updated.

Here's the lig & DC in Q:

capture-002219.png.9960d25373cd587c51894e09b6da9730.png

 

And here it is in APub:

capture-002220.png.06f6bc160224469c15d2d2c47ce91402.png

I'm not smart enough to figure out why APub is behaving this way. I'm only smart enough to make sure a font has a certain feature and to see it working in literally everything I have to use with the exception of APub. My lowercase ligs all work in APub.

Link to comment
Share on other sites

This.jpg.3b121497d4ec6f9b61369f133801cb6d.jpg

I set up a Paragraph Style setting only the Font (Adobe Caslon Pro) and a three line Drop Cap. Three different results.
All of them are the same style, the top is with nothing done, the second is with an option-space between the "T" and the "h" and the third is done with option-right-arrow between the "T" and the "h". Note the second "Th" ligature in all three.

I too am not smart enough to know how to fix the problem, you seem to be streets ahead of me though. [smiley-face emoticon] 

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

On 9/16/2018 at 1:20 AM, Old Bruce said:

This.jpg.3b121497d4ec6f9b61369f133801cb6d.jpg

I set up a Paragraph Style setting only the Font (Adobe Caslon Pro) and a three line Drop Cap. Three different results.
All of them are the same style, the top is with nothing done, the second is with an option-space between the "T" and the "h" and the third is done with option-right-arrow between the "T" and the "h". Note the second "Th" ligature in all three.

I too am not smart enough to know how to fix the problem, you seem to be streets ahead of me though. [smiley-face emoticon] 

Right-option-arrow applies kerning, which is supposed to disable ligatures. That seems to be working in your third example. However, I have found it to be a bit inconsistent, and it can depend on whether the drop cap is present, which shouldn't make a difference. This will be fixed in a future beta.

Option-space inserts a non-breaking space, and for me that prevents the ligature forming as I'd expect. I'm really surprised you aren't seeing that. Is it possible you got the examples the wrong way around?

Link to comment
Share on other sites

On 9/15/2018 at 11:46 PM, MikeW said:

Ok. I do think ligs + drop caps are broken.

Yes. This will be fixed in a future beta. I'm just turning ligatures off so you get the characters you typed. If you typed U+FB01 the "fi" ligature manually, you might wish it to decompose into "f" and "i", but applying a general decomposition rule would also decompose accents and the like, which would be wrong.

 

On 9/15/2018 at 11:46 PM, MikeW said:

But half my issues above were due to APub not updating the display when I was altering my font back and forth--despite the notice the font cache was being updated.

I'll log that as a separate bug. Normally fonts are added or removed; replacing an old one with a newer version is much rarer although it is supposed to work.

Link to comment
Share on other sites

1 hour ago, Dave Harris said:

Yes. This will be fixed in a future beta. I'm just turning ligatures off so you get the characters you typed. If you typed U+FB01 the "fi" ligature manually, you might wish it to decompose into "f" and "i", but applying a general decomposition rule would also decompose accents and the like, which would be wrong.

I'll log that as a separate bug. Normally fonts are added or removed; replacing an old one with a newer version is much rarer although it is supposed to work.

Thanks, Dave.

I never type or insert ligs manually. If the font has them, I'll use the feature to do them.

I am only suggesting decomp for any ligs involved in a dropcap. Nothing following. I was just supposing that is what is done in Q/ID etc.

Link to comment
Share on other sites

On 9/15/2018 at 10:50 PM, MikeW said:

You should see that there is displayed a Th ligature, correct? But here's the deal. I don't have a Th lig in that font. APub (nothing, really) ought to be making one if not present.

Incidentally, Publisher does add some ligatures itself, if the font doesn't have the 'liga' OpenType feature but does define the Unicode code points. For example, it will use U+FB01 for the "fi" ligature. If this isn't desired you can switch off Standard Ligatures.

We can't make "Th" like that because the corresponding ligature doesn't have a Unicode code point, but we would if we could.

Link to comment
Share on other sites

20 minutes ago, Dave Harris said:

Incidentally, Publisher does add some ligatures itself, if the font doesn't have the 'liga' OpenType feature but does define the Unicode code points. For example, it will use U+FB01 for the "fi" ligature. If this isn't desired you can switch off Standard Ligatures.

We can't make "Th" like that because the corresponding ligature doesn't have a Unicode code point, but we would if we could.

I would rather not have ligatures created like say fake small caps in fonts that don't have small caps.

Switching off ligs either completely or highlighting a faked pair to turn them off locally shouldn't be necessary. It defeats the font author's design. There are sometimes perfectly valid reasons to not have ligs in a given font.

Link to comment
Share on other sites

43 minutes ago, Dave Harris said:

Incidentally, Publisher does add some ligatures itself, if the font doesn't have the 'liga' OpenType feature but does define the Unicode code points. For example, it will use U+FB01 for the "fi" ligature. If this isn't desired you can switch off Standard Ligatures...

Here's a not too uncommon example, Dave.

In the screen shot below both lines of text uses the word, fido. The font itself has U+FB01 (fi lig) but has no drawn characters in the slot. The font also does not contain the OT lig feature. The result by this default action is that there is the two missing "regular" glyphs. (I shut off the phantom feature for the top example.)

capture-002221.png.9a74669b0bfe65bdd1d884cf94466456.png

Now, this scenario is not uncommon. Some font authors intend to add ligs, never do get around to it before releasing the first version. Some simply use a default template to begin the font and don't removing empty glyphs before release. This is often true of display fonts.

I don't think Serif should be faking the feature.

Link to comment
Share on other sites

5 hours ago, Dave Harris said:

Right-option-arrow applies kerning, which is supposed to disable ligatures. That seems to be working in your third example. However, I have found it to be a bit inconsistent, and it can depend on whether the drop cap is present, which shouldn't make a difference. This will be fixed in a future beta.

Option-space inserts a non-breaking space, and for me that prevents the ligature forming as I'd expect. I'm really surprised you aren't seeing that. Is it possible you got the examples the wrong way around?

Hi, I just redid the example and labeled it. The 3 lines are all done with ligatures on and the changes to the middle example (Option-Right-Arrow) breaks the kerning for the second "This" but for some reason the Option-Space (that is the little blue square to the right of the drop-cap "T") in the third example does not break the kerning in the second "This".

1160984000_BetterExplaination.jpeg.0df6038f0c20f13243e8cb6dbc8e8214.jpeg

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

19 hours ago, MikeW said:

Here's a not too uncommon example, Dave.

In the screen shot below both lines of text uses the word, fido. The font itself has U+FB01 (fi lig) but has no drawn characters in the slot. The font also does not contain the OT lig feature. The result by this default action is that there is the two missing "regular" glyphs. (I shut off the phantom feature for the top example.)

Now, this scenario is not uncommon. Some font authors intend to add ligs, never do get around to it before releasing the first version. Some simply use a default template to begin the font and don't removing empty glyphs before release. This is often true of display fonts.

I don't think Serif should be faking the feature.

 

If the font defines U+FB01 but doesn't draw it correctly, the font is broken. I don't want to compromise our handling of correct fonts for the sake of broken ones. This feature has been part of Affinity apps for several years now, and to change it would affect the appearance of existing documents. I am loath to do that without better reason.

Link to comment
Share on other sites

18 hours ago, Old Bruce said:

Hi, I just redid the example and labeled it. The 3 lines are all done with ligatures on and the changes to the middle example (Option-Right-Arrow) breaks the kerning for the second "This" but for some reason the Option-Space (that is the little blue square to the right of the drop-cap "T") in the third example does not break the kerning in the second "This".

1160984000_BetterExplaination.jpeg.0df6038f0c20f13243e8cb6dbc8e8214.jpeg

It looks like the non-breaking space is between the Drop Cap T and its h, so it wouldn't affect the later T and h. Maybe come back to this after the next beta.

Link to comment
Share on other sites

1 hour ago, Dave Harris said:

 

If the font defines U+FB01 but doesn't draw it correctly, the font is broken. I don't want to compromise our handling of correct fonts for the sake of broken ones. This feature has been part of Affinity apps for several years now, and to change it would affect the appearance of existing documents. I am loath to do that without better reason.

Well, I would say if a font defines a Unicode slot but has no glyphs in it, the font is incomplete, not broken...

I think I understand the argument.

However, I would think if someone noticed this issue (who wouldn't) ligs would already be shut off on such text and therefore not change the appearance of the text if this was changed to not "turning on" a feature that doesn't exist. So no issue.

Or, the person noticed, like I did above, and has locally turned off ligs on affected text but has ligs turned on for the remainder of the block would actually get the ligs they originally intended but had to turn them off on such a pair whenever that missing lig was found in the text so that they could keep ligs in general. The net result would also not change the appearance. So no issue.

I just think it is poor practice to activate features in a font the font author did not write.

If the font is even moderately a modern font from a main foundry (like perhaps dating back to at least the mid-2000s) the feature is in the font. Personally, I have only found say the fi lig not being called in a font using feature code in A) pre-unicode fonts or, B) display fonts from the middle 2000s or so that the font author actually chose not to include such a lig feature but still drew it in the proper Unicode slot. Other fonts may include non-professionally made fonts the font author maybe didn't include the feature due to whatever reason.

But in all the above cases, I don't believe an application ought to try to overcome a missing feature by making it up on the fly.

Mike

P.S., By the way, perhaps, you could just choose to not use the slot when empty. Like for instance, InDesign.

P.P.S., No need to respond. I'll leave this issue alone now.

 

Link to comment
Share on other sites

19 hours ago, MikeW said:

However, I would think if someone noticed this issue (who wouldn't) ligs would already be shut off on such text and therefore not change the appearance of the text if this was changed to not "turning on" a feature that doesn't exist. So no issue.

Or, the person noticed, like I did above, and has locally turned off ligs on affected text but has ligs turned on for the remainder of the block would actually get the ligs they originally intended but had to turn them off on such a pair whenever that missing lig was found in the text so that they could keep ligs in general. The net result would also not change the appearance. So no issue.

You seem to be saying that Affinity shouldn't fake ligatures for any font, not just broken/incomplete ones. That would change the appearance for fonts which define the "fi" ligature correctly so it can be inserted manually, but don't define the OpenType rule to use it automatically. I am much less concerned about the appearance of documents using broken or incomplete fonts, for the reasons you mention and because their appearance is already wrong.

20 hours ago, MikeW said:

If the font is even moderately a modern font from a main foundry (like perhaps dating back to at least the mid-2000s) the feature is in the font. Personally, I have only found say the fi lig not being called in a font using feature code in A) pre-unicode fonts or, B) display fonts from the middle 2000s or so that the font author actually chose not to include such a lig feature but still drew it in the proper Unicode slot. Other fonts may include non-professionally made fonts the font author maybe didn't include the feature due to whatever reason.

I find it to be quite common. Arial is one example, which happens to be our default font. Others include Georgia, GillSans, Helvetica, LucidaGrande, Tahoma, Times-Roman, Verdana, TrebuchetMS. Even if backwards compatibility wasn't an issue, I think it is a good thing to make standard ligatures available for these fonts.

21 hours ago, MikeW said:

P.S., By the way, perhaps, you could just choose to not use the slot when empty. Like for instance, InDesign.

That sounds reasonable. We''ll do that in a future beta.

Link to comment
Share on other sites

A personal view of the Th ligature: I am a great believer in most ligatures but the Th one is truly an unpleasant mistake. I believe Robert Slimbach of Adobe is the main person responsible for its increasing ubiquitousness. I think it is an ugly and impractical ligature. When I read a book set in a typeface that has it, I find it draws attenton to itself, exactly what a text font should not do.

Link to comment
Share on other sites

×
×
  • 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.