Problem with languagesystem DFLT and latn

The first time I export the font, it show “languagesystem DFLT dflt;” in the feature.
When in Glyphs, all my .liga/ .end/ .init/ dlig work fine.
When I try to test my font in illustrator, those ligatures just won’t show up. (my open type setting is ON).
I can see my ligatures in illustrator’s glyphs panel, but when I click on them, nothing happen.
example:


Tested in Photoshop, not working either.
Tried copy the ligature from Font book to Pages, not working.

I go back to my Glyphs file, change the “languagesystem DFLT dflt;” to “languagesystem latn dflt;”
export my font, test in illustrator and the ligatures/ end form works!!
but then I found some problems and need to edit my font. So I go back to the glyphs file (with languagesystem latn) to edit. Now I can’t access the ligatures even I have turn on the standard ligature in the preview.

So I changed the "languagesystem " back to “languagesystem DFLT dflt;” and the ligatures show back again in Glyphs again.
Is this normal? I should export my font with “languagesystem latn dflt;” but when I edit it, I should change it back to languagesystem DFLT dflt;?

Glyphs version: Glyhps 2.4.4
Mac OS Mojave: 10.14.1

What happens if you simply automate the languagesystems?

In which feature did you put the ligature code? The AI screenshot says salt, which would be a bad idea.

And are you using the Adobe Fonts folder?
http://www.glyphsapp.com/tutorials/testing-your-fonts-in-adobe-apps

Do you have any script/language tags in the feature code?

I’m resurrecting this old thread because I’ve encountered an issue with this as well.

I have a CP1252 font with a handwritten calt feature but everything else is generated automatically. In testing, the calt feature works fine in Word 2019, but when exporting a PDF or printing, none of the OT rules are applied.

After some extensive testing, I discovered that the lack of languagesystem latn dflt; was responsible for the OT feature failure.

Disabling the automatic generation feature and adding that languagesystem manually enabled everything to work correctly. Obviously this is some limitation with the older PDF / print feature in Word 2019.

I think that, therefore, if a font contains Latin glyphs, that the languagesystem latn dflt; needs to be added as in addition as DFLT is not sufficient.

Thanks.
So you mean that even if there are no latin specific substitutions, that line needs ot be added?

Yes, that appears to be the case.

@georg I remember reporting this way way back … why is this still not implemented?
In older version of Office, no features work, not even kerning, if the languagesystem latn dflt; is not set.

1 Like

If you hit the “Update” button in the Font Info > Features, you get exactly that.

Works for me on a new empty file even:

Which exact version of Glyphs are you running?

Are we talking about languagesystem DFLT dflt; or languagesystem latn dflt;?

Rainer: Glyphs only adds the former, not the latter, which seems to be the important one.

I just checked again in Word on the Mac and on Windows. For making OT features work in Word, it only needs language systems declared, so it needs DFLT dflt. Glyphs will add latn once you add a latn-specific substitution feature anywhere (same for any other script).

But you do not need to make the substitutions script-specific for them to work in Word.

1 Like

I was debugging a font for a client this summer, and only when I added the languagesystem latn dflt;, the features started working.
It is not with all fonts, but usually, adding languagesystem latn dflt; fixes the bug. As @aaronbell mentioned above, in other circumstances.
I will reconstruct and document the bug on Thursday.

I’m running 3.2 (3260) and 3.3 Beta (3330)

@SCarewe I usually deactive automatic generation and add the line.

languagesystem DFLT dflt;
languagesystem latn dflt;
1 Like

Do you have any features that have script latn?

1 Like

Hi @Georg,
Sorry that I was not able to do the testing before.

But I have reconstructed the issue desribed above.
I made a font with only the languagesystem DFLT dflt; line Arosa Test
and one with the extra line languagesystem latn dflt; called Arosa Dflt.

As you can see, even when activating them in Office, the features and kerning do not work.

I reported that years ago.

The screenshot is from Word 2013 but I will also test a more recent version.



Interesting. Could you add this issue to FontTechKnowledge/Office at main · schriftgestalt/FontTechKnowledge · GitHub ? (Maybe not necessarily the part about AVATAR fingering Arosa, whoever they are)

Hi @Georg,

Here you can see Word 365 on Windows 11 still having the same issue:

Ok, sorry AVATAR and finger are just my go-to test sting words.
I did not realise the context in a string. :grimacing:

Hi Sebastina,
I don’t want to mess up the Git structure. It tells me to fork it, if I want ot add a new file for Word.
Why don’t you add it there.
I made a new screenshot with other wording:

Could it be this was a Word bug that was fixed a while ago?

It worked for me without specifying latn in the latest Word 365.

Hi Rainer,

As I stated earlier and so did Aaron, it is not with every font. It might need a certain combination of features to be in the font. I debugged a whole library a few years ago.
Some fonts worked fine without it, some started working once the late dflt line was in.

I deactivated and activated the kerning and feature again in Word 365 and the kerning works now, but the ligatures still don’t work.

What is holding you back to include that line as standard?
It does not break anything. It is not a hack, is it?