Glyphs 1271 builds locl feature incorrectly

1

I just noticed in InDesign that with Turkish text, the s-cedilla is replaced with the s-commaaccent, which is obviously wrong. The local feature is auto-generated, the font was generated with Glyphs 1271.

Using Glyphs 1257 and the same source file, this problem does not occur. So, my conclusion is that there is a bug in Glyphs that was recently introduced.

2

Another observation: Glyphs 1271, in contrast to 1257 wraps the code for the locl feature in a lookup.

If I manually remove that lookup wrapper and export the font with Glyphs 1271, it works as expected. It seems that the additional lookup wrap (what is the reason for it?) causes the wrong behaviour.

3

That is right.

I filed a bugreport/feature request that asks for language agnostic, separated lookups which then can be called after a language statement, like this:

language ROM;
lookup loclROMMOL {
  sub Scedilla by Scommaaccent;
  sub scedilla by scommaaccent;
} loclROMMOL;

language MOL;
lookup loclROMMOL;

In my tests, this structure works, and languages do not get confused. Not sure if it is the most byte-efficient one after compilation.

4

There was a request to be able to call the lookups later. I’ll fix this.

1 Like
5

Hi,
Auto-generated local feature is buggy when I export from version 2.6.4 (1280).
In InDesign when setting language to Turkish s-cedilla is replaced s-commaaccent.
Also when I open the exported .otf the locl feature looks quite messy (see below)
Do you know how to fix this issue?

script latn;

language AZE ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

language CAT ;

sub l’ lookup lookup_2 periodcentered’ lookup lookup_2 l ;

sub L’ lookup lookup_2 periodcentered’ lookup lookup_2 L ;

language CRT ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

language KAZ ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

language MOL ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

language ROM ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

language TAT ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

language TRK ;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub Scedilla by uni0218;

sub uni0162 by uni021A;

sub scedilla by uni0219;

sub uni0163 by uni021B;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

sub i by i.loclTRK;

6

Can you try (in the original .glyphs file) to delete the locl feature and re-generate it?

This is to be expected because you are reverse engineering a compiled binary table. For more details see this tutorial:

7

I think there is a bug in locl feature generation, but I can’t reproduce the mix-up of Turkish and Scedilla.

lookup locl_latn_0 {
script latn;
language AZE;
language CRT;
language KAZ;
language TAT;
language TRK;
sub i by idotaccent;
} locl_latn_0;

I think the substitutions must be listed for each language to work:

lookup locl_latn_0 {
script latn;
language AZE;
    sub i by idotaccent;
language CRT;
    sub i by idotaccent;
language KAZ;
    sub i by idotaccent;
language TAT;
    sub i by idotaccent;
language TRK;
    sub i by idotaccent;
} locl_latn_0;
1 Like
8

I am here in this topic, because I was looking for a solution for my problem (see below). Problem solved, thanks to @jkutilek:

I don’t know if this is really a bug or not a best practice but, I can confirm that the above mentioned suggestion work like a charm. Well, my problem was idotaccent localization is working fine for TRK and TAT but, somehow, not for AZE, CRT, and KAZ languages with the automatic generated feature code [macOS 10.15.6, Glyphs 2.6.6 (1346). I have i (dotless), idotless, idotaccent in my all-caps font’s LC set]. By the suggested way, I can also manage an extra feature for TRK only without separating it from the idotaccentric languages (i/o declare in an additional lookup):

lookup locl_latn_0 {
script latn;
language AZE;
	sub i by idotaccent;
	sub fi by f_idotaccent;
language CRT;
	sub i by idotaccent;
	sub fi by f_idotaccent;
language KAZ;
	sub i by idotaccent;
	sub fi by f_idotaccent;
language TAT;
	sub i by idotaccent;
	sub fi by f_idotaccent;
language TRK;
	sub i by idotaccent;
	sub fi by f_idotaccent;
	sub ampersand by ampersand.loclTRK;
} locl_latn_0;

Again, I don’t know and not qualified to say if this is the right thing to do but it works just fine in my case.

(There is no such thing as an ampersand.loclTRK character, by the way. This is a “v_e” ligature actually which is not common but can be seen at some local inscriptions and introduced in some of the Turkish designers’ character set lately.)

9

Or a slightly more efficient notation:

script latn;

language AZE;
lookup locl_latn_TURK {
	sub i by idotaccent;
	sub fi by f_idotaccent;
} locl_latn_TURK;

language CRT;
lookup locl_latn_TURK;

language KAZ;
lookup locl_latn_TURK;

language TAT;
lookup locl_latn_TURK;

language TRK;
lookup locl_latn_TURK;
sub ampersand by ampersand.loclTRK;

(Then I would put the ampersand into a stylistic set rather than make it a Turkish language variant.)

1 Like