Latin character should be sideways in CJK text

[hatchzo]

This is easy to review CJK Variable Fonts. However one thing I have a complaint, latin character on vertical orientation become uplight posture. It should be sideways if it uses with CJK text in default.

[justvanrossum]

If you activate the vrt2 feature, do the rotated latin characters appear?

It seems HarfBuzz does not turn on vrt2 by default for vertical layout.

[justvanrossum]

FontGoggles only supports the vrt2 way of rotating latin characters, and currently does not support the vert model, where the layout engine rotates the latin.

Maybe this is interesting regarding vrt2 and HarfBuzz, a post from the HarfBuzz mailing list that made HarfBuzz change the default for vrt2: https://lists.freedesktop.org/archives/harfbuzz/2013-August/003490.html

[justvanrossum]

[hatchzo]

Thanks for your prompt response and I understand. Some CJK fonts (such as NotoCJK/Source Han Sans) don't support pre-rotated glyph outlines. This kind of fonts will not be exact latin posture on vertical regardless of vrt2 activation. I expect that fontgoggles supports vert mode glyph orientation.

[khaledhosny]

There would need to be an option to segment text based on Unicode Vertical Orientation property, and the sideways segments would be shaped horizontally then rotated.

[justvanrossum]

I see that TextEdit.app also only supports vrt2 rotation, and for now this is what FontGoggles will do, too.

Supporting vert-style rotation is going to be a big change, one that I cannot implement in the short term. I'll leave this issue open as an enhancement request.

[hatchzo]

I feel that it is definitely import that fonts and apps should support UTR#50. This will more easier way to get the correct posture on vertical.

[be5invis]

Windows application use vert and not vrt2 🤷‍♀. They itemize the text, break the text into “sideways” runs (being upright in vertical mode) and “non-sideways” runs (being rotated in vertical mode), and apply vert to the “sideways” runs. In DWrite, the function is IDWriteTextAnalyzer1::AnalyzeVerticalGlyphOrientation.

This is somehow like how UAX50 should work, but the orientation rule may be different.

[justvanrossum]

I'm not saying it's not important, I'm saying that right now I don't have the capacity to implement this, as it's a non-trivial change.

[justvanrossum]

Also, since the solution involves segmentation, it's related to #35, which also requires a non-trivial solution. We'll get there, just not right now.

[justvanrossum]

Before this can be implemented, we need to be able to get at the Unicode "vertical orientation property".

Unless I'm missing something, I don't see this property being available in the builtin unicodedata module, nor in the 3rd party unicodedata2 module, nor in fontTools.unicode or fontTools.unicodedata.

Probably best to make a PR for fonttools that adds this, similar to the "script" property and others.

Here's the relevant Unicode data file:

• http://www.unicode.org/Public/UCD/latest/ucd/VerticalOrientation.txt

[justvanrossum]

Another relevant reference:

• http://www.unicode.org/reports/tr50/tr50-19.html

We should do grapheme clustering. Possibly with:

• https://pypi.org/project/uniseg/

...although that package had its latest release in 2015.

[anthrotype]

make a PR for fonttools that adds this, similar to the "script" property

👍

grapheme clustering

PyICU should have that https://github.com/ovalhub/pyicu

[anthrotype]

or we would wrap this unicode-segmentation rust library from python

https://github.com/unicode-rs/unicode-segmentation

[anthrotype]

@justvanrossum I just made this https://github.com/anthrotype/unicode-segmentation-py

(i just wanted an excuse to play with rust, really)

[justvanrossum]

Cool!

I just found there's another option on PyPI, that seems to be more actively maintained than uniseg:

• https://pypi.org/project/grapheme/
• https://github.com/alvinlindstam/grapheme

[justvanrossum]

Btw. does anyone in this thread know where the rotated baseline should be for the rotated characters, relative to the vertical center line?

Perhaps the middle between ascender and descender, but that's just a rather uneducated guess.

[hatchzo]

VertAxis.romn tag in BASE table?

[be5invis]

If you are really lazy you can simply align +0.38em to the vertical center line, or make it user configurable.

[be5invis]

Another way is to find some of the characters in Enclosed CJK Letters and Months like ㊣, and its vertical center is a good reference.

[justvanrossum]

VertAxis.romn tag in BASE table?

Time for me to learn about the BASE table, thanks!

[justvanrossum]

More todo:

• expose hb_ot_layout_get_baseline in uharfbuzz (https://harfbuzz.github.io/harfbuzz-hb-ot-layout.html#hb-ot-layout-get-baseline).
• or instantiate BASE on the fly with fonttools.

I hope people understand this really isn't a trivial feature request...

[khaledhosny]

Sure it isn’t. It is the equivalent of BiDi for vertical text.

[hatchzo]

If the viewer supports BASE version 1.1 Variation Store table, that will be great.

[lianghai]

Btw. does anyone in this thread know where the rotated baseline should be for the rotated characters, relative to the vertical center line?

It’s a whole pile of hot mess, inconsistent heuristics across platforms. The BASE table is not reliable. FontGoggles will need to provide an offset slider for users, then a default value doesn’t need to be sophisticated.