Plain text custom fraction input
richard.wordingham at ntlworld.com
Thu Jul 23 15:25:40 CDT 2015
On Thu, 23 Jul 2015 11:45:14 +0200 (CEST)
Marcel Schneider <charupdate at orange.fr> wrote:
> On 23 Jul 2015, at 01:06, Richard Wordingham wrote:
> IMHO it would be hard to input fractions in nut style while using
> plain text or normal formatting, at the extent that we need the
> special Maths applications we know, from LibreOffice as far as I am
> concerned. But that isn't plain text. With the font-supported plain
> text fraction input as suggested, we can never get nut style,
> unfortunately. This is inimaginable *in plain text*.
The Unicode does not distinguish 'nut' style and the 'slash'-based
style. The problem is entirely one of rendering. A renderer could
support the 'nut' style, just as renderers typically support
underlining and strike-out with just a few numeric parameters from the
font. 'Plain text' just means no formatting commands associated with
the text - it doesn't prevent immense quantities of information being
taken from a font, but it does prevent specification of which font to
> > > If this input method is not encouraged, what's the use of U+215F
> > > FRACTION NUMERATOR ONE?
> > It's for temporarily storing a character defined in some other
> > coding standard.
> It would be interesting to know more about this standard, and what
> was the use of this character in that standard, which seems to be
> hard to retrieve. What do you mean by "temporarily", given that
> Unicode code point allocations are stable?
The idea is that data is read in from an old encoding, manipulated, and
written out in the old encoding. For long term use, it would be
better to convert the data, though conversion may have to do more than
just change the character sequence. You are correct in that the
unconverted data may be held as such indefinitely.
> I'm very puzzled. I'd
> rather think that the inverse value as a "vulgar" fraction is so
> important that an input facility is provided, intended to be
> completed with subscript digits.
The standard answer is that in the Unicode scheme, that sort of
capability should belong to the input mechanism. An example is
the general refusal to encode new precomposed characters. Indeed, if
renderers supported U+2044 (rather than just treating it as an ordinary
character), input resources would be better employed supporting the
input of U+2044.
More information about the Unicode