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

'block' property may not be complete or the correct choice #38

Closed
aphillips opened this issue Feb 5, 2022 · 7 comments · Fixed by #44
Closed

'block' property may not be complete or the correct choice #38

aphillips opened this issue Feb 5, 2022 · 7 comments · Fixed by #44
Assignees
Labels
for review i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.

Comments

@aphillips
Copy link

Paint Text
(https://w3c.github.io/imsc-hrm/spec/imsc-hrm.html#paint-text)

Block property (see [UNICODE]) for the character of gi

CJK Unified Ideograph

The table assigns a different "text rendering performance factor" to characters (code points) in the "CJK Unified Ideograph" block. But this block is hardly the only one that contains CJK ideographs. I suspect that the block property is not what is wanted and instead the script or some other property should be used instead. It's not clear from the text why a different (lower!) value is assigned to CJK ideographs. If it is the regular spacing and similar size of each glyph, it should be noted that other scripts share this property, such as the Japanese kana or the Korean Hangul characters.

What is it about this block that you're trying to capture in the algorithm?

@aphillips aphillips added the i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. label Feb 5, 2022
@nigelmegitt
Copy link
Contributor

I can not recall how we got to these values and sets, nor why "CJK" might be considered quicker to render - @palemieux perhaps you can?

@palemieux
Copy link
Contributor

palemieux commented Feb 20, 2022

@aphillips The Ren(Gi) parameter is intended to capture the relative speed of rendering glyphs -- the larger the value the faster it is to render a glyph. When the HRM was defined in 2013, device manufacturers, which included home theatre devices such as TVs, indicated that glyphs associated with CJK ideographs were more complex to render than glyphs associated with other code points.

@aphillips
Copy link
Author

@palemieux Thanks.

The challenges with CJK is that the fonts are large and the glyphs tend to be more complex individually. The observed behavior is not surprising, but if you were to continue to use blocks to define this, you'd need to add many more blocks containing the various Han ideograph supplements, plus the blocks associated with Japanese and Korean. You'd be better off defining this by script, e.g. Han, Katakana, Hiragana, Bopomofo, and Hangul. Otherwise your algorithm will be missing a lot of characters (including the most complex i.e. slowest Han characters).

@palemieux
Copy link
Contributor

You'd be better off defining this by script, e.g. Han, Katakana, Hiragana, Bopomofo, and Hangul.

@aphillips Ok. Any additional ones beyond those?

@palemieux palemieux self-assigned this Feb 21, 2022
@aphillips
Copy link
Author

@palemieux No, that would cover CJK.

@himorin
Copy link
Contributor

himorin commented Feb 22, 2022

When the HRM was defined in 2013, device manufacturers, which included home theatre devices such as TVs, indicated that glyphs associated with CJK ideographs were more complex to render than glyphs associated with other code points.

Sorry to cut in, and might not be directly connected to intentions of the original review comment, but this recalls me whether the issue is originated from large size of CJK fonts or complexity (as like number of outline paths/control points) of glyph?
PR adds Hiragana, Katakana, Bopomofo explicitly, but might not be the case for latter... (number of control points could be similar or just a bit larger than US-ASCII)

@nigelmegitt
Copy link
Contributor

whether the issue is originated from large size of CJK fonts or complexity (as like number of outline paths/control points) of glyph?

I don't think the HRM considers resource size at all - happy to be corrected, but I have the impression that this is about the typical or average rendering complexity of each glyph.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for review i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants