Asmus,
On 2/9/2016 2:19 PM, Asmus Freytag (t) wrote:
On 2/9/2016 1:36 PM, Ken Whistler wrote:
On 2/9/2016 1:23 PM, David Faulks wrote:
Perhaps Unicode could create a ‘default position’ property for
combining characters, and encourage OpenType and other font engines
to adopt it for automatic use when no other font information is
provided. Adoption would take a while, but I cannot help but think
that otherwise, this issue will never go away.
It does. General_Category=Mn and ccc=230 indicates that a character is
a non-spacing mark positioned *above* its base.
Attempting to get more precise that that with a *character* property
would
be a mistake. Such interaction in detail between a mark and its base is
an attribute of glyphs and their design, and properly belongs to the
realm
of rendering and fonts.
What about GC=Mn and ccc=0?
The *overwhelming* majority of those are for Indic scripts.
For those, an actual positional property would make sense.
And, ta da!, we have one:
http://www.unicode.org/Public/8.0.0/ucd/IndicPositionalCategory.txt
That also encompasses the positional classes for gc=Mc, as well as gc=Mn.
It wouldn't need to be overly specific.
It isn't -- it is designed (and being used) for Indic rendering engines.
The outliers which are gc=Mn and ccc=0 but which are not covered
by IndicPositionalCategory.txt include:
CGJ and variation selectors and one shorthand control: irrelevant, because
these aren't displayable marks.
Thaana vowels
Miao tone marks: irrelevant, because Miao has a very idiosyncratic encoding.
Signwriting marks: Irrelevant, because Signwriting has a very idiosyncratic
encoding.
And I don't think adding a new positional property just to keep track of
the fact that two Thaana vowels display below their consonant instead of
on top makes sense. If it came to that, Thaana could just be added to
IndicPositionalCategory.txt, instead.
For example, for Unibook, I allow a convention to supply this
information to place a glyph in relation to the dotted circle; it's
described in the help file. There are some special wrinkles there,
because the values are tweaks that get applied to known fonts (that
just happen to not do the right thing when combined with an the
standard dotted circle in the charts).
Just adapt IndicPositionalCategory.txt for Unibook, and you've got what
you need.
--Ken
However, this approach would seem to indicate that such a scheme is
possible and with just a few values sufficiently differentiated to be
of practical use (= immensely improve on the fallback).
A./
