Clarified the requirement for processors to implement reference fonts #245
Conversation
imsc1/spec/ttml-ww-profiles.html
Outdated
| <p class="note">This clause only applies to codepoints supported by the processor. See <a href="#recommended-char-sets"></a> | ||
| for codepoints that a processor is likely to encounter for various languages.</p> | ||
|
|
||
| <p class="note">Since the flow of text within a region depends the dimensions and spacing (kerning) between individual |
There was a problem hiding this comment.
I think we may need to hold off on this until we've talked to @r12a. I think the wording is probably too specific still. We may need something more like:
The flow of text within a region depends on the font(s) used to present it, and in general different fonts result in different dimensions of any given glyph sequence. By using the computed font family and codepoints listed in reference fonts the author can predict more accurately the inline progression size of any given block of text, which helps when positioning and sizing text and regions, for example to avoid unexpected line breaks or overflow.
| <p>When rendering codepoints matching one of the combinations of computed font family and codepoints listed in <a href= | ||
| "#reference-fonts"></a>, a processor SHALL use a font that generates a glyph sequence whose dimension is substantially | ||
| identical to the glyph sequence that would have been generated by one of the specified reference fonts.</p> | ||
|
|
||
| <p class="note">This clause only applies to codepoints supported by the processor. See <a href="#recommended-char-sets"></a> | ||
| for codepoints that a processor is likely to encounter for various languages.</p> |
imsc1/spec/ttml-ww-profiles.html
Outdated
|
|
||
| <p class="note">Since the appearance (overall size, position of line breaks, line spacing, etc.) of a subtitle depends on | ||
| glyph metrics, an author gains additional control on such appearance when using combinations of computed font family and | ||
| codepoints for which metrics are specified.</p> |
There was a problem hiding this comment.
I think this is probably still not right. Is "glyph metrics" a defined thing? What about variant glyphs - they must be important too. Also, "for which metrics are specified" isn't quite saying the right thing - the point here is that the result of rendering the text using an acceptable reference font is that a glyph sequence has the same dimensions. In other words, the "metrics" don't just have to be specified, they have to be identical, and the selected glyphs must be the same too.
There was a problem hiding this comment.
What about the following:
Since the appearance (overall size, position of line breaks, line spacing, etc.) of a subtitle depends on font metrics, an author gains additional control on such appearance when using combinations of computed font family and codepoints for which metrics are defined.
There was a problem hiding this comment.
I think i may be starting to understand. Does this text capture what you are concerned about?
When a content author sets a bounding box for a subtitle, they want to maximise the likelihood that the text will fit within it when displayed by the processor. If the processor doesn't use the specific font the content author had in mind, the font actually used may cause the text to grow in size so that it no longer fits in the bounding box. This is further compounded by differences in the way text wraps when a font has bigger glyphs, which may increase the number of lines used, and increased line spacing, which may also push some of the text outside the bounding box.
To help ensure that things such as text size, line breaking, and line height behave as expected relative to the size of the bounding box set by the content author, the author can use one of the reference fonts defined by this specification. This specification requires processors to support one or more fonts with similar font metrics as reference fonts. It should be noted, however, that the reference fonts as currently defined only cover characters used for a few writing systems – in particular, a subset of those based on Latin, Greek, Cyrillic, Hebrew, and Arabic scripts.
There was a problem hiding this comment.
@r12a Just a few nits:
If the processor doesn't use the specific font the content author had in mind
If the processor doesn't have access to the specific font the content author had in mind..
they want to maximise the likelihood that the text will fit within it when displayed by the processor.
... and control the size of the background area
[ed.: in the case the background area is solid black for instance]
There was a problem hiding this comment.
@palemieux I don't agree with your first nit - it isn't relevant why the processor isn't using the specific font: saying "doesn't have access" presumes a reason why the scenario may arise, but possibly there are other reasons we don't fully understand.
There was a problem hiding this comment.
@nigelmegitt More importantly, are you happy with the rest of @r12a proposal?
There was a problem hiding this comment.
@palemieux Yes, works for me.
There was a problem hiding this comment.
@palemieux i understand your point about the solid background area not growing to overlap important areas of the screen, but i suspect that authors would do better to use the bounding box to control that issue. I think it may be too risky to assume that you can apply such fine control over areas blocked out within the bounding box.
For example, when subtitles are translated that level of granularity will no longer apply, and having been a translator and worked with bounding boxes in UI localization, i think the translators will be hoping that the bounding box is set in such a way that it solves most of their placement problems for them most of the time – they are already under a lot of time pressure due to the fact that english expands in other languages, and they may need to resize/reposition bounding boxes to cope with that.
So i guess i'm suggesting to not add text specific to solid backgrounds.
There was a problem hiding this comment.
I have updated the PR at 512a064 per #245 (comment) , replacing conformance term with non-conformance terms.
There was a problem hiding this comment.
Looks good to me! Thanks (also to @r12a for the contribution).
|
@r12a @nigelmegitt I have updated the note as suggested. |
Closes #241 and closes #237