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

[aphillips]

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?

[nigelmegitt]

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]

@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]

@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]

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

@aphillips Ok. Any additional ones beyond those?

[aphillips]

@palemieux No, that would cover CJK.

[himorin]

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]

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.