[CLOSED] Not All Subtables Being Used by Applications
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
[CLOSED] Not All Subtables Being Used by Applications
I temporarily reverted my download to Pali version 3.0 because that is the latest version I could find where the kerning works in PagePlus, Affinity Publisher (presumably), and LibreOffice.
The pairs are definitely being exported and are present when I reopen the *.otf.
Maybe just too many pairs or too many subtables (9). I will try to diagnose the bug and fix it.
It is related to Subtables. If move Subtable Caps to the top, those work, and so does Subtable Hyphen, but not Subtable lc.
The pairs are definitely being exported and are present when I reopen the *.otf.
Maybe just too many pairs or too many subtables (9). I will try to diagnose the bug and fix it.
It is related to Subtables. If move Subtable Caps to the top, those work, and so does Subtable Hyphen, but not Subtable lc.
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Not All Subtables Being Used by Applications
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
I've opened version 3.44 but kerning didn't even work in FontCreator, so maybe it is broken?
Can you send me the project file, so I can look into this?
Can you send me the project file, so I can look into this?
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Not All Subtables Being Used by Applications
Thanks. I have sent the project file for Pali Regular.
The original contained a table for lowercase/Uppercase pairs, which had a lot of class overlaps when I merged the subtables, so I deleted that subtable.
Merging the other subtables showed up some duplicate pairs, which were stripped on compiling the lookups.
The original contained a table for lowercase/Uppercase pairs, which had a lot of class overlaps when I merged the subtables, so I deleted that subtable.
Merging the other subtables showed up some duplicate pairs, which were stripped on compiling the lookups.
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Not All Subtables Being Used by Applications
This is the best that I have managed thus far. All but smcp, pcap, and subs/sups pairs are working now.
Further merging of subtables or changing the order seems to make no difference.
Further merging of subtables or changing the order seems to make no difference.
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
Do send me this project, and I will look into it.
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Not All Subtables Being Used by Applications
I have sent you the project file, and an older version that mostly works in PagePlus X9.
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
Maybe it is just something we have never fully understood, but I think I now understand the problem.
Class based kerning is stored as a two-dimensional array as sequences of two class values. This array also includes class0, which represents all glyphs that are not assigned to any of the used classes. This class0 is then matched, so subsequent sub tables will never be processed. We might need to change some things and update the manual if this is indeed what is happening...
Class based kerning is stored as a two-dimensional array as sequences of two class values. This array also includes class0, which represents all glyphs that are not assigned to any of the used classes. This class0 is then matched, so subsequent sub tables will never be processed. We might need to change some things and update the manual if this is indeed what is happening...
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Not All Subtables Being Used by Applications
Your efforts are much appreciated. When I started using FontCreator 4.0 I never imagined there was so much to the process of creating a robust font with comprehensive glyph coverage.
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
It is slightly different. With a class based positioning subtable, a match is found it either the first or second glyph is found (or both of course). If they both do not exist in the subtable, then it will proceed in the next subtable(s).Erwin Denissen wrote: ↑Mon Jun 08, 2020 7:19 pm Maybe it is just something we have never fully understood, but I think I now understand the problem.
Class based kerning is stored as a two-dimensional array as sequences of two class values. This array also includes class0, which represents all glyphs that are not assigned to any of the used classes. This class0 is then matched, so subsequent sub tables will never be processed. We might need to change some things and update the manual if this is indeed what is happening...
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
Some more testing revealed that my last statement is incorrect.
These are my findings:
With a class based positioning subtable, a match is found if the first glyph is found. The second one seems to be irrelevant.
So this will work:
And here the rule in Subtable2 is never applied, as class KernClass_Y is among the first class definitions of Subtable1:
These are my findings:
With a class based positioning subtable, a match is found if the first glyph is found. The second one seems to be irrelevant.
So this will work:
Code: Select all
lookup PairAdjustment1 {
subtable Subtable1 {
pos @KernClass_V @KernClass_A <100> <0>;
pos @KernClass_W @KernClass_U <200> <0>;
pos @KernClass_X @KernClass_o.subs <300> <0>;
}
subtable Subtable2 {
pos @KernClass_Y @KernClass_o.subs <-250> <0>;
}
}
Code: Select all
lookup PairAdjustment1 {
subtable Subtable1 {
pos @KernClass_Y @KernClass_parenright <75> <0>;
pos @KernClass_Z @KernClass_S <400> <0>;
}
subtable Subtable2 {
pos @KernClass_Y @KernClass_o.subs <-250> <0>;
}
}
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
The user manual already mentions it, but somehow it is easily overlooked:
How can we improve the user manual?It is important to realize class based kerning is stored in a two dimensional array; which is made out of first glyph classes and second glyph classes. If a glyph exists in a first glyph class, it should never be included in another first glyph class, as such overlapping classes are not allowed for class based kerning. Same goes for second glyph classes. Due to the nature of a two dimensional array, if a specific pair is not included in the pair list, it will still be stored in the pair positioning lookup. All glyphs that are available in the first glyph classes will cause the text processing engine to stop looking for pairs in subsequent sub lookups.
-
- Top Typographer
- Posts: 9878
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Not All Subtables Being Used by Applications
I don't think there is any problem with the manual. I already understood that class overlaps should be avoided, but I still do not understand why the Petite Capitals and Super/subscript subtables are not being processed.
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
Does this make things more clear?
With text "BAYOZY" only pair OZ will be processed in subsequent subtables. Even though BA, YO, and ZY are not defined as pair positioning rules, they are still matched with the matrix.
With text "BAYOZY" only pair OZ will be processed in subsequent subtables. Even though BA, YO, and ZY are not defined as pair positioning rules, they are still matched with the matrix.
-
- Moderator
- Posts: 11160
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Not All Subtables Being Used by Applications
This update provides better validation when compiling feature code. The proofing tool also shows when a class based pair positioning match is found. That can be hidden with the "Compact" option.
FontCreator 13.0.0.2651 (64-bit)
Let us know your results.
FontCreator 13.0.0.2651 (64-bit)
Let us know your results.