Prioritise loaded fonts when selecting font.

[nigelmegitt]

ttml2/#368 introduces via ttml2/#650 some of the semantics from CSS Fonts Level 3, but not the part that describes behaviour in case a remote font resource is lazily loaded but not yet available when it is needed. Describe this behaviour - as a first pass, it should be the same as CSS Fonts Level 3.

[skynavga]

@nigelmegitt I disagree that it is necessary to say anything about loading behavior. Whether a font is loaded lazily is strictly an implementation optimization and has no bearing on presentation semantics as defined. At most, we could add a note that says "For the purpose of presentation processing, it is assumed that all referenced fonts are available to the presentation processor, and, if some font is not available, then the resulting presentation is implementation dependent."

If we want to go overboard even more, then we could say that implementations have various options, such as (1) wait until a font is available before proceeding, (2) perform presentation using the remaining fonts in the font family list or fallback fonts, then, if the font becomes available, then repeat presentation processing, (3) declaring and error and presenting no subsequent content, etc.

[nigelmegitt]

CSS Fonts 3 does something quite like that in the Font loading guidelines:

In cases where textual content is loaded before downloadable fonts are available, user agents may render text as it would be rendered if downloadable font resources are not available or they may render text transparently with fallback fonts to avoid a flash of text using a fallback font. In cases where the font download fails user agents must display text, simply leaving transparent text is considered non-conformant behavior. Authors are advised to use fallback fonts in their font lists that closely match the metrics of the downloadable fonts to avoid large page reflows where possible.

I don't think there's anything in there that disagrees with what you said in https://github.com/w3c/ttml2/issues/675#issuecomment-367587391 @skynavga except the point that transparent text is considered non-conformant is important. Perhaps we could simply add an informative note that points to that section of CSS Fonts 3 and says the same guidelines apply?

[skynavga]

@nigelmegitt we say nothing about "render[ing] transparent text", and I don't even know what that means, so why should we call it out as non-conformant? there is no action to be taken on this issue AFAIK, so let's close it

[nigelmegitt]

@skynavga read the extract again re transparent text - it is clearly a reference to an implementation tactic of rendering text transparently before the correct font has been loaded, so that when it is available and the text can be rendered correctly, there is no "flash of text" - in the case that the correct font is never loaded, leaving the transparent text visible is not conformant.

[skynavga]

@nigelmegitt exactly, an implementation strategy for browsers, which is entirely irrelevant to TTML; we will not be saying this in TTML, as it is extremely broken to discuss browser implementation strategies;

at most, we can say that a font resource, if used, must be fully available before it is used, and, if not available at that time, then that font isn't used; which seems pretty dumb, given its obviousness

[skynavga]

@nigelmegitt just to be clear about what I am objecting to, you said:

Perhaps we could simply add an informative note that points to that section of CSS Fonts 3 and says the same guidelines apply?

I am saying they don't apply because they are not relevant, and because, even if they were relevant, they are implementation dependent, and, therefore, we should say nothing.

[nigelmegitt]

an implementation strategy for browsers, which is entirely irrelevant to TTML

@skynavga CSS doesn't say the implementation has to be a browser. The statement is useful for any implementation that might be obtaining a separate font resource for the purpose of rendering text, but where the availability of that resource is asynchronous.

at most, we can say that a font resource, if used, must be fully available before it is used, and, if not available at that time, then that font isn't used; which seems pretty dumb, given its obviousness

That is not at all obvious, and therefore not dumb to state. I would prefer the CSS wording though.

...
even if they were relevant, they are implementation dependent, and, therefore, we should say nothing.

The non-conformance part is not implementation dependent. I don't see the harm here, and it's clearly in CSS due to (bad) experiences, so I'd prefer to take those lessons on board. Since we are talking about an informative note, and seem to agree on the essence, I don't see why we're arguing this.

[skynavga]

@nigelmegitt I cannot accept the CSS language or any language which the intent is to suggest implementation strategies. This is not an implementation guide. What I can do is add language that says: "If a downloaded font resource is not available (in its entirety) at presentation time, then it must be treated as if the resource does not exist." I am even somewhat reluctant to add this, however, since nowhere else do we raise the issue of font availability. Frankly, I think we should say nothing whatsoever.

[css-meeting-bot]

The Working Group just discussed Prioritise loaded fonts when selecting font. ttml2#675, and agreed to the following resolutions:

• SUMMARY: Take no action for now, mark as ttml.next and close.

The full IRC log of that discussion

<nigel> Topic: Prioritise loaded fonts when selecting font. ttml2#675
<nigel> github: https://github.com/w3c/ttml2/issues/675
<nigel> Glenn: I would be happy to add normative language that documents the semantics that I
<nigel> .. think we want to enforce, which is that the entirety of a font resource, downloaded or not,
<nigel> .. must be available at presentation time to be used or hold that it exists for the purpose of use,
<nigel> .. in terms of evaluating a list of font families that are specified by the author in the fontFamily
<nigel> .. property. Right now XSL and TTML say nothing about what should be done by an
<nigel> .. implementation in terms of loading either locally or remotely available fonts and use
<nigel> .. during the presentation but there is a presentation I think by the authors and implementers
<nigel> .. that if you are going to use a font then it had better be available, or you should move on
<nigel> .. down the list. Right now that behaviour is implementation defined because it is not defined
<nigel> .. in XSL and not really in CSS either.
<nigel> .. The CSS language may have some relevance to incremental redisplay or relayout in browsers.
<nigel> Nigel: I think that's bypassing the issue though, what happens if the font becomes available
<nigel> .. part way through the presentation?
<nigel> Glenn: That's implementation dependent.
<nigel> .. Right now there's no backup from the spec. If eventually every implementation uses
<nigel> .. lazy loading, then maybe we could say something in the future about it, but I still think
<nigel> .. it is in the domain of implementation choices and goes down into the details we should
<nigel> .. not be talking about in my opinion. There are a lot of other ways to optimise implementation
<nigel> .. without spec support, for example rendering text to pixels prior to its use.
<nigel> Nigel: Okay, any other views about this? I think it could impact CSS based renderers like imsc.js.
<nigel> Pierre: I haven't looked at this at all. Today imsc.js just copied tts:fontFamily to the CSS
<nigel> .. style and lets the CSS implementation do whatever it does. I don't see that changing.
<nigel> .. I've not run into this issue and noone has complained about it so far. My inclination would
<nigel> .. be to leave it as an implementation detail until somebody runs into a problem.
<nigel> .. One option would be to do nothing now but if it comes up then come back to this issue.
<nigel> Glenn: We can always close it and mark as ttml.next for posterity.
<nigel> SUMMARY: Take no action for now, mark as ttml.next and close.