The justification presented by Mr Pentzlin was in my mind too restrictive. I need to use the superscript letter q not only in abbreviation but also in mathematical formulas, including in xslt transformation of MathML to xhtml.

Also I would have preferred a place in the 2070–209F interval for this letter.Does anyone agree to help me in suggesting this addition?

There is no consensus that abbreviations like this must be representable in plain text. For example, 1st, 2nd, 3rd etc. are conventionally typeset with superscripts, but the proper way to do that with Unicode is NOT by using modifier letters. Instead, the recommended way to represent these as superscript is by using markup.

For mathematics, "superscript" can be applied to a whole expression of formula, and it can be nested (indefinitely, in principle). Hence, in mathematics, this is not properly a character property, and modifier letters (or "superscript" numbers) should not be used. Instead, the proper way to do this, is by using markup.

Thank you. Let me answer.As a French and as a type designer, I cannot accept your first assertion: the typographical result of your "recommendation" is disastrous. Superscripts are too thin, too high, too stuck and have a design inappropriate. (Reference: http://en.wikipedia.org/wiki/Subscript_and_superscript)Hand write pᵖ. You see that you do not draw in the same way the letter and its superscript. The drawing of the superscript is simpler but keep the same thickness.I am working on a style sheet that transforms MathMl to SVG. I use systematically superscript for a quality rendering and I cannot support the exception of letter q.

[The] typographical result of your "recommendation" is disastrous. Superscripts are too thin, too high, too stuck and have a design inappropriate. (Reference: http://en.wikipedia.org/wiki/Subscript_and_superscript)Hand write pᵖ. You see that you do not draw in the same way the letter and its superscript. The drawing of the superscript is simpler but keep the same thickness..

I think all of us agree that type does not scale in a linear manner, and that smaller glyphs (such as superscript) need to be drawn differently than just being mere scale copies. That is not the question, the question is how to get there.

How the characters are encoded is one matter. How they are rendered is another. It is incorrect to assume that the use of a modifier letter should indicate a different rendering than the use of superscript markup. Both should render the same way, with the layout engine using superscript glyphs from the font (if available) in both cases.

Note, please, that the article that you quote uses superscript markup for all examples of generic Latin letters and digits.

pecita wrote:

I am working on a style sheet that transforms MathMl to SVG. I use systematically superscript for a quality rendering and I cannot support the exception of letter q.

Using modifier letters should not result in a different layout from using superscript markup for "q". If it does, then that means the font does not have superscript glyphs or the layout engine is poor in that it does not access the proper glyphs.

Modifier letters should be used for modifier letter semantics, not for general superscript appearance. The latter should be encoded using markup.

I think all of us agree that type does not scale in a linear manner, and that smaller glyphs (such as superscript) need to be drawn differently than just being mere scale copies.

For the rest, your logic is perfect but I am doubtful about its practical application.Consider a concrete example. I build an OpenType typeface. Is there a feature to handle the superscripting intent?When I write in html <sup>q</sup>, how can select a glyph different from the basis other than relying on the normalization of Unicode?Instead the Unicode standardization directly solves my problem in 99% of cases: all except the letter q!

Members of the UTC sometimes let a-priori prejudices get in the way of wisdom. We saw this before the disunification of Coptic from Greek, and Ecclesiastical Georgian from standard Georgian. We still see it in a number of areas: it's a battle to encode any punctuation, any symbol (unless backed by a Japanese telco), borrowings between Latin, Cyrillic, and Greek.

If we have nearly all of the basic Latin alphabet available as superscript letters it is perverse not just to complete the set. What's more perverse is that sometimes it's agreed to add characters in order to complete sets, but other times barriers are put up against doing so. Unfortunately, the UTC has never been consistent. I know this, because I've had both kinds of answer from them so often it makes my head spin. It's no wonder this causes frustration, which causes push-back, which causes bad feelings, which causes bad relations.

I do not think that Maths is a good argument for adding this letter. We all know that Maths requires special markup and that plain-text Maths without markup is not possible.

The good argument is for completion of the set, so further effort, energy, and committee time need not be wasted on it.

I think all of us agree that type does not scale in a linear manner, and that smaller glyphs (such as superscript) need to be drawn differently than just being mere scale copies.

For the rest, your logic is perfect but I am doubtful about its practical application.Consider a concrete example. I build an OpenType typeface. Is there a feature to handle the superscripting intent?

Yes, in OpenType it's calle a variant, and software that supports it, will use this feature. See the example of Minion Pro superscripts in the Wikipedia article you cited.

pecita wrote:

When I write in html <sup>q</sup>, how can select a glyph different from the basis other than relying on the normalization of Unicode?

You need a layout engine that can access those features of an OpenType font. With that, you can make the proper glyph selection. "Dumb" layout engines and APIs are useful only for a subset of scripts and languages anyway, and will never provide correct typography. The answer is not to mis-use Unicode to work around their limitations but to switch to better performing ones.

If we have nearly all of the basic Latin alphabet available as superscript letters it is perverse not just to complete the set. What's more perverse is that sometimes it's agreed to add characters in order to complete sets, but other times barriers are put up against doing so. Unfortunately, the UTC has never been consistent. I know this, because I've had both kinds of answer from them so often it makes my head spin. It's no wonder this causes frustration, which causes push-back, which causes bad feelings, which causes bad relations.

I do not think that Maths is a good argument for adding this letter. We all know that Maths requires special markup and that plain-text Maths without markup is not possible.

The good argument is for completion of the set, so further effort, energy, and committee time need not be wasted on it.

Math use is different in many aspects. For example, positioning - see the Wikipedia article examples. So, we agree, it's not an argument.

But there's a difference between superscripted text runs and isolated characters (modifier letters) where the raised, small form is inextricably bound up with the meaning. In plain text, being limited to Mlle, is fine. If you want a typographically correct rendering, requiring the use of markup is appropriate. Using runs of modifier letters is a mis-use of Unicode. That principle is worth defending.

Now, I'm the first to admit, that it may seem churlish to require independent evidence for every last member of a very obvious set, especially after most members have been attested. I also don't think Unicode is in any way "cleaner" by having all modifier letters encoded in a scrambled order, instead of alphabetical, nor do I think the savings of a few code positions from not (yet) encoding the missing members matter very much.

However, if the missing "q" is an effective obstacle that prevents people from misusing modifier letters for runs of superscripted text, I would count that as an accidental benefit. In my view that would mitigate the downside of the messiness introduced by "dribbly" encoding processes.

(To prevent misrepresentation: where sets have many "speculative" members, you'll find me opposed to their on-spec encoding - however, I don't want to hijack this topic with details for the general case. Open a new topic if you want to discuss that).

... the proper way to do that with Unicode is NOT by using modifier letters. Instead, the recommended way to represent these as superscript is by using markup.

Would you accept that, although this is something you are advocating for years, this is... not a good idea? (at least for French!)

The short answer, no I would not, at least not without more detailed and concrete evidence that a change in positions is warranted.

There is a long answer as well, I just finished typing it in, but the forum kicked me out while I was composing it, and I lost the post. I do not have the time to re-create it at this time, sorry, but it concerned the kind of evidence you'd need to provide why this is a problem with Unicode, and not simply a problem with existing implementations.

In particular, I don't at all understand your issues with SVG, so you might explain yourself better. (I do understand the desired typographically correct rendering, but I fail to see why only character codes can give you that).

... the proper way to do that with Unicode is NOT by using modifier letters. Instead, the recommended way to represent these as superscript is by using markup.

Would you accept that, although this is something you are advocating for years, this is... not a good idea? (at least for french!)

It is not a good idea to clone all Unicode characters in superscript/subscript form. It is simply infeasible to do so. Markup + glyph-selection in fonts is the appropriate path to deal with such issues.

It probably wouldn't hurt to add the single letter 'q', but some people take any single such addition as license to push tons of other garbage into the standard. Look at emoji, where the compatibility requirements to add a single playing card — as a compatibility character — led to people promoting the addition of every single other playing card, then variants, ...

Thus providing for one instance, even if itself not particularly harmful, can lead to spurious demands for all possible items of that type.

Mark,There are 26 letters in the French alphabet: not 25, not 27, not tons, 26. All of them are used superscripted in abbreviations.Markup + glyph-selection in fonts is actualy not operative in standards.

It is perhaps worth pointing out that it will take years for a character addition to help anyone. Arranging for some rendering tool to understand some markup and produce a pleasing result is, at least potentially, far faster, and solves many more problems. Almost by definition, if a problem is 'urgent', encoding a character can't be the solution. Using PUA and a font is probably the fastest, and looking to (particularly open source) software to do provide assistance via markup is still faster than the standardization process.

... In particular, I don't at all understand your issues with SVG, so you might explain yourself better. ...

I am not able to answer concisely to my project of MathML to SVG via XSLT and ecmascript.I quickly build a small html page: http://pecita.eu/mathUni1.xhtml , in order to give an idea of what I want. I want the result of the first line, not the outcome of the second line. Whatever the browser, whatever the font, the result does not fit to my idea.Excuse me for the handwriting: the concept applies both to "real" fonts.

Here is a list of the forms we have. Note that it does not list all or even most Latin characters, because we only add superscript and subscript characters where they represent different semantics (such as modifier letters).

Who is online

Users browsing this forum: No registered users and 1 guest

Quick-mod tools:

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum