On Thu, 23 Jul 2015 11:45:14 +0200 (CEST) Marcel Schneider <[email protected]> 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 use. > > > 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. Richard.
