On 22 Jul 2015, at 15:08, Khaled Hosny wrote: > Some layout engines, like HarfBuzz, automatically turn on the required > OpenType features for proper fraction rendering when fraction flag is > used. If the font has “numr” and “dnom” features, HarfBuzz will turn > them on for the sequence. IMHO, that is > the most Unicode-compliant approach and other engines should do the > same.
I fully agree that every good rendering engine must implement the Unicode fraction scheme. I'm glad to learn that Firefox and LibreOffice use HarfBuzz. Even more, as Richard Wordingham wrote yesterday, this scheme should be transposable on Arabic digits where as he writes, no super- nor subscripts are available. Moreover, uncomplete fonts—for example, ornamental fonts, which sometimes lack super- and subscripts because the user is expected to use the formatting tool (consistently with the ornamental purpose of the font), can be used for fractions thanks to the formatting feature. Using the fraction slash as a formatting flag, considerably lightens the work. Seen from this point of view, the fractions handling as specified by Unicode is the most universal and most reliable way. On the other hand, the harmonization inside the fonts, between super- and subscripts and the numerators and denominators of the precomposed fractions they contain, could be purely esthetical without any idea of using superscripts as numerators, subscripts as denominators. The remaining question would then be: What was the idea when at font design, the fraction slash was given left and right kerning, so that a preceding superscript digit will take exactly the place it has as a part of a precomposed fraction, and a following subscript takes place like if it were a denominator in one of the precomposed fractions? If Unicode really never targeted such a usage and always thought of the fraction slash as a mere formatting flag with some glyph to make the user aware of its presence, this kerning idea was, as I outlined yesterday, the merit of a caring and innovative font designer. (We should get some testimony, surely a Latin font designer on this List would be glad to share his experience, given that because of the lack of Arabic super- and subscripts in the UCS, IMHO you were not given this peculiar opportunity.) Then it would be ungrateful not to make use of his invention whenever the font complies with this alternate scheme, additionally to its support of the standard scheme. Perhaps should we consider plain text rendering too, because many situations require that all the needed information be given in plain text. Especially in these cases, it could be interesting to be able to enter fractions that look like if they were formatted. However, keyboard layout considerations can lead to not officially recommend this input method, in order not to bug people who will complain not to have super- and subscripts along with the accompanying fraction slash right on their keyboard. Yesterday I explained that this is very easy to enter, at least on Windows (but on Linux too we have AltGr layers on the Numpad, except that these are used for the simple and double arrows like they are engraved following the legacy implementation of the caret commands). With an appropriate Windows keyboard driver, it's enough to hold down the left Ctrl and Alt while typing the numerator on the numpad followed by the numpad slash (a key that in AltGr will produce 0x2044), and adding Shift while ending with the denominator. As I outlined yesterday at this occasion, the default Windows keyboard driver templates contain a warning to prevent developers from adding more characters on the numpad. More precisely, the allocation tables are split according to the number of shift states, and the numpad allocation table contains the least number of shift states among all these split alloc tables. Moreover, a comment says to "put this last", adding some explanation based on internal processes. But experience, at least as it is actually provided on Windows 7, proved that the numpad as well as all other keys can be unified in *one* table containing all shift states (including the Kana shift states, up to Shift + Ctrl + Alt + Kana). This is how I've got the arrows, too. I simply press *all* keys to the left of the spacebar, and I get simple or double arrows (the latter with Shift). So I must hold down Shift with the left little finger, and Ctrl, Fn, Alt, Kana with the four other fingers, while typing on the Numpad. For fractions, it's roughly the same, except that Kana is not to be pressed. This may be somewhat complicated, but I do believe that using character tables for super- and subscripts is a less performative input method. As already outlined yesterday, I fear that much is done to prevent users from getting plainly started with the worktool, in order to keep us prisoners of some high-end software. I do not deny that this software is sometimes or often indispensible at work. But I do wish that everybody come into the benefit of *all* performative input methods, including those which do not require more than a complete keyboard layout. Thank you for your feedback. Best regards, Marcel
