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
Comments
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? |
@aphillips The |
@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. |
@aphillips Ok. Any additional ones beyond those? |
@palemieux No, that would cover CJK. |
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? |
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. |
Paint Text
(https://w3c.github.io/imsc-hrm/spec/imsc-hrm.html#paint-text)
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?
The text was updated successfully, but these errors were encountered: