Does this frac implementation actually work?
Severin Meyer
Posts: 10
I realize that I'm late to the party on this subject. Tal Leming's Fraction Fever 2 implementation of the frac feature has opened my eyes about the capabilities of OpenType. As a fun challenge, I have subsequently experimented with an alternative approach to this feature, and here is what I came up with:
Repository
Feature file
It offers the same functionality as Fraction Fever 2, but has a few potential advantages. For one, it can process fractions of arbitrary length. As a result, incomplete or incorrect replacements are avoided more reliably. At the same time, it adds only about a third as many bytes to a font.
Based on initial tests, it appears to work as intended. But of course, I value the opinion of any interested expert, who might be able to point out a fatal flaw in my approach.
Repository
Feature file
It offers the same functionality as Fraction Fever 2, but has a few potential advantages. For one, it can process fractions of arbitrary length. As a result, incomplete or incorrect replacements are avoided more reliably. At the same time, it adds only about a third as many bytes to a font.
Based on initial tests, it appears to work as intended. But of course, I value the opinion of any interested expert, who might be able to point out a fatal flaw in my approach.
0
Comments
-
Interesting use of GSUB Type 8. But in my limited testing, this was not supported in InDesign. So probably not a robust approach for fonts destined for print use.
1 -
Thank you for taking the time to have a look at it.
If you tested the implementation with the provided font files, did you also test the Fraction Fever version? If neither works, there is a good chance that the problem lies with the minimalistic font files, not the feature itself.
In any case, GSUB type 8 is part of the OpenType specification since 2002, I would have hoped it is reasonably supported.0 -
Actually, I incorporated your {frac} feature code (with one modification for different glyph naming) into a test font of my own.
There are, unfortunately, plenty of aspects of the OpenType specification which have been in place for a while but have not been implemented in desktop layout apps. Because of the reverse order of application of GSUB Type 8 to the input string, I’m actually not too surprised that Adobe has not implemented it in InDesign. I even checked both the Standard and World-Ready Composers, just in case.
Too bad.
2 -
Ah, the joys of partially implemented standards.
But there is no point in complaining, so I have added an alternative, more conservative implementation:
Timid Trail Marker
It uses the same strategy, but emulates GSUB Type 8 lookups with a sequence of GSUB Type 6 lookups. Hence it is limited to 10 digits, like Fraction Fever 2, but in return should be equally stable.
Meanwhile, it still adds only about half as many bytes to a font. It also should be slightly more "correct" than Fraction Fever 2, because it ignores potential fractions if the numerator is longer than 10 digits, instead of partially replacing them.
I tried to repeatedly call the same lookup (i.e. 8 times fracNumr1), but that seems to be ignored by applications. Maybe I have overlooked something in the specification that allows repeating lookups to be consolidated?
1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 800 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports