Not sure which scripts count as ‘Indic’ — technically all all the Indian and Southeast Asian scripts derived from Brahmi are Indic, but I’m not sure what sense we’re talking about here.
If DIST is built automatically, would the values be compiled somehow from kern pairs? Or where? I would not put these kind of adjustments in KERN as some environments do not apply kerning; DIST is the correct feature.
See also some discussion about this on GitHub.
For some scripts, Glyphs generates the dist feature instead of kern.
I am afraid after adding these lines at the end of DIST there isn’t any effect on the font’s representation on all the web browsers — the result is the same as the screens above.
script lao;
language LAO;
lookup laoKerns2;
lookup kern1_lao;
Concerning the exceptions — I’d better return to coding them after the DIST browser representation’s issue is solved 
Yes, the question is which scripts? As mentioned in that linked discussion, DIST is not part of the spec for Thai and Lao. Therefore there shouldn’t be any automatic DISTing and Nikolay’s lookups in that feature should work, no?
The lookups will work regardless of Glyphs generating the dist feature automatically. But he is miss-understanding the ignore part.
Well, I might have set the ignore statements wrong, but why does the DIST feature get’s interpreted only by Safari’s browser and InDesign? At my last attempt I haven’t set there any ingnore lines, so they are not the reason for missrendering the whole DIST command. An ignore statement functions in general as an addition on top of the main feature, right?
No. The ignore only influences whatever comes after it. Whatever is in an other lookup or feature is totally unaffected.
Exactly! Therefore the DIST feature should work flawless in all web browsers and InDesign regardless of the ignore statement. I tried with the script and language tags at the end of DIST, that Ben showed me, but the result is the same. Any ideas, what could I do so that all the browsers could support it? At this moment I don’t speak about ignore statements.
Some rendering engines might decide to not apply the dist feature at all. Try putting you code in a kern feature. Put this in the first line: # Automatic Code End.
I’ve run a bunch of tests about this and got into trouble.
First I tested with Thai and it seems Georg is right, Chrome and Firefox are ignoring DIST lookups completely for Thai, but Safari is applying them. To get it working, I had to put the lookups in the KERN feature as follows:
# Automatic Code End
lookup kernTallVowels {
lookupflag UseMarkFilteringSet @thaiMarksAboveFirstLevel;
pos maiTho-thai saraO-thai' <200 0 200 0>;
} kernTallVowels;
I’m not sure why it needed the lookupflag, when there’s only a single adjustment here, but it wouldn’t work any other way even when no other marks are on the base.
When I tried the same thing in another font (one that also includes Burmese, Khmer and Lao), everything fell apart and I can’t figure out what’s different. Nothing in the kern or dist feature is working for Thai or Lao.
I then wanted to try using the latest cutting edge beta but I’ve got this damn message again and can’t be bothered to reinstall it right now because when I’ve tried that before it’s deleted all my scripts, plugins and shortcuts.
Georg, could I send you a font with Thai and Lao glyphs to run tests of your own?
@GeorgSeifert, I tried to do it by copying the DIST lookups lines in KERN and added the # Automatic Code End as you said, but it still renders the same way on Firefox and Chrome. So I will try to follow the way Ben did.
@Bendy, I am still on version 2.4.2 (1060) in Glyphs, I’ll update to the cutting edge version later, cause now it’s a bit risky for me. If you like I can test it for you on my version.
Something else must have happened back then. Because the app and the Application Support folder (where scripts and plug-ins are stored) are two different things. You can backup your App Support folder to be on the safe side, but replacing the app in the Applications folder cannot affect the App Support folder.
Ok, I will try again. But why do I keep getting ‘invalid or damaged’? This is the third time I’ve had the error and I’ve reinstalled it twice already. (Works fine to start with, but after working on v.1043 for a week or two, opening the beta gives this message.)
This occasionally happens, and AFAIK we have not been able to track it down. (Unless Georg has a lead in the meantime?) I believe it has something to do with the way macOS manages app signatures. Where do you keep your app versions, both with different names in the system-wide Applications folder?
Georg is absolutely right, only KERN feature gets interpreted by all main three web browsers (Safari, Firefox, Chrome).
I could even define an ignore statement for one glyph (strangely all the other glyphs in the lookup don’t), but again — it gives a working result only in InDesign.
InDesign:
Firefox:
The code I used:
# Automatic Code End
## Kerning issues with base consonants, marks-above-the-bases and following tall vowels:
lookup laoKerns3 {
lookupflag UseMarkFilteringSet @maiTi-lao;
pos @laoConsonantsNoAscend maiTi-lao oVowel-lao' <80 0 80 0>;
pos @laoConsonantsNoAscend maiTi-lao ayMaiMuanVowel-lao' <85 0 85 0>;
pos @laoConsonantsNoAscend maiTi-lao aiMaiMayVowel-lao' <20 0 20 0>;
pos @laoConsonantsNoAscend maiTi-lao @laoBelowMarks oVowel-lao' <80 0 80 0>;
pos @laoConsonantsNoAscend maiTi-lao @laoBelowMarks ayMaiMuanVowel-lao' <85 0 85 0>;
pos @laoConsonantsNoAscend maiTi-lao @laoBelowMarks aiMaiMayVowel-lao' <20 0 20 0>;
pos @laoConsonantsNoAscend @laoBelowMarks maiTi-lao oVowel-lao' <80 0 80 0>;
pos @laoConsonantsNoAscend @laoBelowMarks maiTi-lao ayMaiMuanVowel-lao' <85 0 85 0>;
pos @laoConsonantsNoAscend @laoBelowMarks maiTi-lao aiMaiMayVowel-lao' <20 0 20 0>;
} laoKerns3;
lookup laoKernsExcept3 {
lookupflag 0;
lookupflag UseMarkFilteringSet @maiTi-lao;
pos ngoNgu-lao maiTi-lao oVowel-lao' <120 0 120 0>;
pos soSeua-lao maiTi-lao oVowel-lao' <70 0 70 0>;
pos hoHaan-lao maiTi-lao oVowel-lao' <60 0 60 0>;
pos hoNo-lao maiTi-lao oVowel-lao' <0 0 0 0>;
pos hoMo-lao maiTi-lao oVowel-lao' <0 0 0 0>;
ignore pos @laoBaseKernSiteSpecif maiTi-lao oVowel-lao';
} laoKernsExcept3;
script lao;
language LAO;
lookup laoKerns3;
lookup laoKernsExcept3
@laoBaseKernSiteSpecif = [ngoNgu-lao, soSeua-lao, hoHaan-lao, hoNo-lao, hoMo-lao] ;
Only ngoNgu-lao gives a working ignore and reposition. Plus, it gives this result only when the pos lines precede the ignore statement.
You still don’t understand what the ignore is doing. It has to do with how lookups are processed.
Lets go through this with the lookup like
sub f f by f_f;
sub f f l by f_f_l;
The string is uffle.
Each lookup is applied to the whole text. It starts at cursor position 0, and checks if it finds any match (it checks every rule, one by one). When it finds a match, it moves the cursor behind the matched glyphs, if not, it just moves the cursor to the next glyph. So after finding f+f and replacing it with f_f, the cursor is behind the f_f. So the f_f_l will never show up, because it will always find the f_f first.
Let’s add an ignore:
ignore sub u f';
sub f' f' by f_f;
sub f' f' l' by f_f_l;
(EDIT: added glyph marks ' to substituted glyphs, see the spec: ‘Note that the marked glyphs in the exception sequences indicate where a substitution would have occurred; this is necessary for the OpenType layout engine to correctly handle skipping this sequence.’)
When it finds the “u+f” it does nothing to it (because there is no by XX). It just moves the cursor behind the first f. So this will prevent both ligatures.
As Georg says, you’ve misunderstood the ignore completely. The reason the kerns are working here is the ignore statement is being ignored! Ignore basically means ‘do the following lookups except in the situation defined by the ignore’. And in your example there are no lookups following the ignore statement. So what you want to do is ignore the ngoNgu and other consonants in the lookups that are positioning the tall vowels next to maiTi on all consonants (so that it will operate on all consonants except the ngoNgu). The other possible way would be not to try and use ignore statements, but to let the lookup operate on all consonants and then make a further (negative) kern adjustment in the context of the consonant bases that need it.
Note also, if you’re using a MarkFilteringSet, you might not need to explicitly include the @belowmarks classes in your positioning lookups.
I’ve reinstalled the latest beta again, and things are working as expected. My positioning lookups are working now for Thai and Lao when in the kern feature, across Firefox, Safari and Chrome, and the ignores are working:
# Automatic Code End
lookup kernTallLaoVowels {
# lookupflag UseMarkFilteringSet @laoAboveMarks; # this seemed not to be necessary after all
ignore pos ngoNgu-lao maiTho-lao oVowel-lao'; # Nikolay, if you want to exclude other bases, put them in square brackets where the ngoNgu-lao is
pos maiTho-lao oVowel-lao' <800 0 800 0>;
} kernTallLaoVowels;
lookup kernTallThaiVowels {
# lookupflag UseMarkFilteringSet @thaiAboveMarks; # this seemed not to be necessary after all
pos maiTho-thai saraO-thai' <800 0 800 0>;
} kernTallThaiVowels;
The positioning adjustment of 800 looks like a few wordspaces, but you’ll see it’s not being applied in the situation where ngoNgu is the base.
Side note: in the latest beta, auto-aligned components are treated differently from in version 1043…I thought this had been solved ages ago? These two Burmese glyphs are made from flipped components, but the flipped parts have bounced up in the air and I can’t now move them as they’re meant to be auto-aligned?
