Does this frac implementation actually work?

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.


Tagged:

Comments

  • Kent LewKent Lew Posts: 560
    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.
  • 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.
  • Kent LewKent Lew Posts: 560
    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.
  • 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?
     
Sign In or Register to comment.