Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The default glyph forms with vo=Tr in vertical texts #4661

Closed
cheonhyeongsim opened this issue Apr 14, 2024 · 5 comments
Closed

The default glyph forms with vo=Tr in vertical texts #4661

cheonhyeongsim opened this issue Apr 14, 2024 · 5 comments

Comments

@cheonhyeongsim
Copy link

I am now using Google Chrome 109.0.5414.168 and discovered this issue. I know that Google Chrome uses Harfbuzz as its shaping engine. If this issue has already been fixed in the newer version of Harfbuzz, please ignore my words here.

From http://www.unicode.org/reports/tr50/, we could know that, in vertical texts, the characters with a value Vertical_Orientation=Tr should be rotated 90 degrees clockwise as a fallback. That is, if we do not write anything in the OpenType vert feature, then a rotated glyph should be given, just the same as the characters with a value vo=R. But actually, Google Chrome show me an upright glyph for this kind of characters in default, which should be the behavior for the characters with a value vo=U or vo=Tu in principle.

Note that, when I proposed to add VS3 for Sibe form quotation marks, I also suggested to change their vo from R to Tr, and was agreed by the Script Encoding Working Group. If the issue I mentioned above still exists, then the quotation marks could not be shown as the expected glyphs in vertical texts, not only in Sibe texts, but also in English texts (if needed, for example a text mixing English and Chinese) and Chinese texts.

I used U+2329 and U+232A to test this issue. With vo=Tr and without any OpenType Layout, their default glyph form in vertical texts should be like ︿ and but not and . Please check and fix this issue if possible.

@behdad
Copy link
Member

behdad commented Apr 14, 2024

HarfBuzz itself doesn't decide the orientation. The client (in this case Chrome) does. cc @drott @kojiishi

@cheonhyeongsim
Copy link
Author

HarfBuzz itself doesn't decide the orientation. The client (in this case Chrome) does.

Thank you for your quick reply. Could I ask where I should propose this issue to?

@behdad
Copy link
Member

behdad commented Apr 14, 2024

HarfBuzz itself doesn't decide the orientation. The client (in this case Chrome) does.

Thank you for your quick reply. Could I ask where I should propose this issue to?

https://issues.chromium.org/issues

@behdad
Copy link
Member

behdad commented Apr 14, 2024

Please paste the issue URL here when you file.

@behdad behdad closed this as not planned Won't fix, can't repro, duplicate, stale Apr 14, 2024
@cheonhyeongsim
Copy link
Author

Please paste the issue URL here when you file.

https://issues.chromium.org/issues/334110491

Thank you very much, I have already posted this issue to Chrome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants