Re: Case for letters j and J with acute

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./
>
Received on Tue Feb 09 2016 - 17:02:31 CST