Re: Plain text custom fraction input

From: Marcel Schneider <charupdate_at_orange.fr>
Date: Wed, 22 Jul 2015 12:21:32 +0200 (CEST)

On 22 Jul 2015, at 09:52, Richard Wordingham wrote:

> Implementing FRACTION SLASH is fiddly, and formally it is impossible in
> OpenType - the lookup tables can only cope with a finite range
> of numerator and denominator lengths. The next problem is what feature
> to put it under. Microsoft Word is notorious for preventing users from
> using ligatures in Latin script text, though that restriction has been
> relaxed.
>
> One of the touted capabilities of Microsoft's Universal
> Script Engine is the rendering of cartouches for Egyptian hieroglyphs.
> However, the interface specification makes no mention of special
> handling for them - I can only assume that the capability arises
> through the enabling of certain features. Egyptian hieroglyphs are
> currently a simple script - it lacks essential support for writing the
> script seen on Egyptian monuments. (I'm not entirely sure of the
> correct bidi classification of the original hieroglyphs - they should
> probably be weakly right-to-left, not strongly left-to-right. Strong
> left-to-right may, however, be appropriate for most printed hieroglyphs
> - I've even seen plain text hieroglyphs running left to right on a page
> whose primary script is Arabic.)

We never thought of common hieroglyphs otherwise as running LTR, while on monuments the great liberty of the script allows to run in amost all directions. IMO monumental transcription is always difficult to deal with, whenever exact rendering is expected. However, since Unicode's purpose is plain text encoding, we must stick with what I consider as a convention in egyptology...

...which brings us back to plain text fractions, which by an apparent but tacit convention we can input as an *unlimited* string of superscript digits, followed by U+2044, followed by an *unlimited* string of subscript digits. What are you referring to when talking about implementing the fraction slash? The fonts I've tested successfully are OpenType at least as for Arial Unicode MS. The way the fraction slash is actually implemented, was purely a font design issue, which has been brilliantly resolved:
1 - Superscript digits match numerators like they appear in precomposed fractions.
2 - Subscript digits match denominators.
3 - The fraction slash kerns consequently.

If this input method is not encouraged, what's the use of U+215F FRACTION NUMERATOR ONE?

About ligatures: Replacing ff, fl, ffl with ligatures is typically a rendering engine task, but for backwards compatibility the precomposed ligatures of the Alphabetic Presentation Forms FB00 - FB4F have been encoded in Unicode. What is the relation with plain text fractions, and why do you look out for a feature? The fraction formatting feature I mentioned, becomes right completely useless when users start typing custom fractions in plain text. That is what I suspect to be at the origin of the taboo that seems to be observed about this hint.

If you would ask me if I know hieroglyphs, well I'd just started a little bit learning. But I launched this thread only for the purpose of Latin plain text, no feature, no bidi-mirroring, just plain text fractions. The skill, if there is any, is only about how to get supers, subs, and fraction slash at reach on the keyboard. A good solution is to put them in AltGr on the NumPad. So you press Left Ctrl and Left Alt together to get superscripts right on the numpad. Adding Shift, you get the subscripts. Ah, the fraction slash: just press the numpad Divide after the last numerator digit.

That works because we can program for the numpad exactly the same shift states as on the alphanumerical block. Don't trust the comment in the C source which prevents us from integrating the numpad into the general allocation table, urging us to "put this last" (quotation). I've got no bug by not following this. Well its still "last", but at the bottom of the big table!

Thank you for your feedback.

Have a nice afternoon,

Marcel
Received on Wed Jul 22 2015 - 05:22:42 CDT

This archive was generated by hypermail 2.2.0 : Wed Jul 22 2015 - 05:22:42 CDT