Automatic frac feature code converts all digits to either numerator or denominator, but I think it shouldn’t, in cases like 1+2/3 (currently, 1 also becomes a numerator). Any opinion on this, mathematically and/or typographically?
Hi @Tosche,
I was doing some test, and I found that there are a limitation in lookahead, what that means is that the shaping engine cannot going back in the text string in order to apply a substitution. So we need to declare explicitly all combinations before slash. In other words, the following feature seems to be workable:
lookup CONTEXTUAL_FRACTION {
sub @numbers slash' @numbers by fraction;
} CONTEXTUAL_FRACTION;
lookup NUMERATORS_LIMITED_LOOKAHEAD {
sub @numbers' @numerators by @numerators;
} NUMERATORS_LIMITED_LOOKAHEAD;
lookup DENOMINATORS_FIRST_APPAREANCE {
sub fraction @numbers' by @denominators;
} DENOMINATORS_FIRST_APPAREANCE;
lookup DENOMINATORS_INFINITY_LOOKBEHIND {
sub @denominators @numbers' by @denominators;
} DENOMINATORS_INFINITY_LOOKBEHIND;
Except that the shaping engine is not going to go back in the text string in order to substitute lookup NUMERATORS_LIMITED_LOOKAHEAD.
So we need to declare explicitly all possible numerators:
lookup NUMERATORS_EXPLICIT_LOOK_AHEAD {
sub @numbers' @numbers @numbers [adding more @numbers progressively] fraction by @numerators;
sub @numbers' @numbers @numbers fraction by @numerators;
sub @numbers' @numbers fraction by @numerators;
sub @numbers' @numbers fraction by @numerators;
sub @numbers' fraction by @numerators;
} NUMERATORS_EXPLICIT_LOOK_AHEAD;
Attached you can find an standalone feature.fea file with franc feature with a limit of 20 denominators, I think that is enough.
Let me know what do you think.
Best,
Nicolás
I use my own variant of Tal Leming’s Fraction Fever. But the problem with contextuality is that the context has its limits. It can only go back x number of characters.
This also seems to be what Microsoft and Adobe had in mind when they introduced the feature, but they do not explain how to reliably replace all figures preceding the slash with numerators. It is also unclear what is the job of the application, and what should be the job of the opentype feature.
Application interface: The application must define the full sequence of GIDs to be replaced, based on user input (i.e. user selection determines the string’s delimitation). When the full sequence is found in the frac coverage table, the application passes the sequence to the frac table and gets a new GID in return. When the frac table does not contain an exact match, the application performs two steps. First, it uses the numr feature (see below) to replace figures (as used in the numr coverage table) preceding the slash with numerators, and to replace the typographic slash character (U+002F) with the fraction slash character (U+2044). Second, it uses the dnom feature (see below) to replace all remaining figures (as listed in the dnom coverage table) with denominators.
From this, I infer that the application implementation has a large part to do in this. The application is supposed to select the right number of figures to the left of the slash, ignore the frac feature and apply numr and dnom all by itself. Only if the user selects the correct number of figures and slashes, then the fraction feature is applied. So, in this scenario, the fraction feature should change all figures because it expects the right selection already in place. In other words, the feature as it is automatically produced is all right, only the implementation in applications such as InDesign is not correct.
Thanks guys! I wasn’t really thinking about how to write a code, but I now realise it’s not as straightforward as I thought.
I have totally forgotten about the fraction fever, but this is very much what I wanted (I did have a next question about multiple slashes, but it already answers that).
I think finite digit is practically okay. As far as mathematical convention goes, I see that you should be using ×10ⁿ notation beyond 16 digits (Fraction Fever 1 supports up to 10, which is probably fine in practice).
As for what the application is supposed to do, I think the font should do its best job where the application fails (so does the user, whom you cannot blame for not reading Microsoft OT spec).
FF1 had a few limitations that Tal fixed in FF2. He explained it in his blogpost, which is not online anymore. And FF2 (now on his OT cookbook) can easily be extended to 16 digits.