On 23 Jul 2015, at 22;35, 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.
I fully agree, even without knowing much about how a font works, precisely. > > > > > 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. Indeed Unicode was forced to encode a number of characters for the unique reason that these characters are a part of preceding standards with which backwards compatibility is to be ensured. That's the case for example of U+0149. This character looks a bit different when input as recommended and specified in the compatibility mapping, with letter apostrophe. This is more distant from the letter than the apostrophe as a part of the all-in-one apostrophe-en glyph. But that's a font issue, not a Unicode concern. As for the fraction numerator one, I'm still unsure about how it was used in this old standard. Perhaps subscripts were used to complete, so the plain text custom fraction input we're discussing would be compliant to this legacy standard. That's very interesting. > > > 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. I don't deny the usefulness of automatized fraction formatting following the detection of the presence of U+2044. Encoding any *new* precomposed characters or *new* characters that can be obtained by formatting some existing ones, is useless and resource-wasting. This is why it is refused. By contrast, plain text custom fractions input wholly relies on existing and largely implemented characters, by combining them in a "new" way. This time the quotes are scare quotes, because as I learned *after* my last reply yesterday, this is already a more or less well established practice. Please read the information with my apologies in the next e-mail. Best regards, Marcel > Message du 23/07/15 22:35 > De : "Richard Wordingham" > A : "Unicode Mailing List" > Copie à : > Objet : Re: Plain text custom fraction input > > On Thu, 23 Jul 2015 11:45:14 +0200 (CEST) > Marcel Schneider 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. >
