Re: Plain text custom fraction input

On Thu, Jul 23, 2015 at 9:25 AM, Marcel Schneider <charupdate_at_orange.fr>
 wrote:
>
>
> 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?
>
Many font designers do not differentiate between superscript and numerator,
subscript and denominator because it’s easier to design glyphs once and can
work fine in some cases.
In some fonts, the superscript and subscript figures are completely
different from the numerators and denominators, or are at different
heights, because this is better in some cases.
In the end it's a design issue but you cannot expect either behaviour in
every font.

Using the recommended figures with the fraction slash will not work
everywhere or with every font, but abusing the superscript and subscript
will not either.

-- 
Denis Moyogo Jacquerye
On Thu, Jul 23, 2015 at 9:25 AM, Marcel Schneider <charupdate_at_orange.fr>
wrote:
> On 22 Jul 2015, at 15:08, Khaled Hosny <khaledhosny_at_eglug.org> 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
>
-- 
Denis Moyogo Jacquerye