Enhance font selection semantics.

[skynavga]

Define tts:fontSelectionStrategy style property based on
the XSL 1.1 font-selection-strategy property and TTWG ML thread.

Specify font selection semantics, including how multiple author defined font resources combine
with (local) platform defined font resources to obtain an ordered list of font resources for performing character to glyph mapping.

Editorial note from 2014-11-21.

[nigelmegitt]

In line with #406 and the general feedback to use CSS as the basis of semantics where possible I propose using CSS Fonts Level 3 https://www.w3.org/TR/css-fonts-3/ as the basis for this semantic if at all possible. For example see §5.3 Cluster Matching in that document.

CSS Fonts Level 3 is part of the CSS 2017 Snapshot.

[skynavga]

Changing this to editorial, as we had already included tts:fontSelectionStrategy for some time now, including a feature #fontSelectionStrategy.

[nigelmegitt]

@skynavga the current ED and the published WD each have an empty placeholder sections for the tts:fontSelectionStrategy style attribute, empty except for an issue note, so this issue by definition cannot be resolved without the creation of normative text. I cannot see how that is editorial and not substantive. Certainly by Process rules it must be substantive.

[skynavga]

@nigelmegitt I don't have such a black and white view as you express here. For me it depends on the context and nature of the change. There is plenty of gray area to consider. However, as it turns out, the PR makes schema changes, which is a sufficient criteria in my mind to warrant a substantive label. If it hadn't, I would have argued for editorial, but that is neither here nor there at this juncture.

[nigelmegitt]

I will propose in our call later today that we defer this issue to ttml.next on the grounds that the feature is complex, so a full review cycle is needed, and that we have scant input suggesting that the feature is needed. Leaving the behaviour as implementation defined seems adequate at the moment, given our strongly expressed desire to move ahead to CR.

The practical implication of deferring would be that we will need a pull request to remove tts:fontSelectionStrategy from TTML2.

[css-meeting-bot]

The Working Group just discussed Fill in definition of tts:fontSelectionStrategy, add to schema, fix typo ttml2#632 (pull requests).

The full IRC log of that discussion

<nigel> Topic: Fill in definition of tts:fontSelectionStrategy, add to schema, fix typo ttml2#632 (pull requests)
<nigel> github: https://github.com//issues/371
<nigel> Nigel: I'm proposing to defer this as I noted earlier.
<nigel> Glenn: I object to deferring it for the following reasons:
<nigel> .. 1. It is not complex. The "auto" value is already implied by our processing model, silently.
<nigel> .. It's been a long standing open area to flush out. As it turns out the way that "auto" is
<nigel> .. technically defined is implementation dependent, but it does at least give some guidelines
<nigel> .. as to what information constitutes the selection criteria, which we had not listed before
<nigel> .. As for filling in the placeholder, we already had enumerated the style property as a token
<nigel> .. in the list of vocabulary, and defined a feature for it. Not much was required to fill in the
<nigel> .. gap to establish the two values. Nigel had even put in the derivation previously.
<nigel> .. Really the only issue is whether or not we will have enough implementations to satisfy
<nigel> .. exit criteria. We certainly have them for parsing the property (TTT already does it). The
<nigel> .. semantics of auto are already supported in at least one implementation. I think it will
<nigel> .. meet the CR exit criteria without any real issues. I don't see any issue with including it
<nigel> .. and pulling it out now would prevent us from putting it in CR and offering it to industry to
<nigel> .. implement. We could mark it as at risk - it is already marked as at risk.
<nigel> s/k./k in this pull request.
<nigel> Andreas: I tend to agree with Nigel. People have to review deeply. There's some reference
<nigel> .. to XSL-FO so if there is no strong demand for it then I would defer it. I think there has
<nigel> .. not been enough review.
<nigel> Nigel: For me this is not simple at all - reviewing in terms of XSL-FO and CSS is certainly
<nigel> .. complex.
<nigel> Glenn: The text in this pull request is not complex - if you try to understand XSL-FO and CSS then that is more complex.
<nigel> .. I'm aware of XSL-FO implementations of character-by-character and it's extremely simple.
<nigel> .. All the character value does is to turn off contextual characters and treat each character
<nigel> .. individually. CSS adopts the same thing there. There's no danger in putting it in now.
<atai2> q+
<nigel> Nigel: What is the use case for it?
<nigel> Glenn: If you're using complex scripts and you have a list of fonts, e.g. "Monaco, UnicodeMS"
<nigel> .. then Monaco as a font may not support all non-spacing marks and UnicodeMS is much
<nigel> .. fuller and does support them. The "auto" semantic would fall back to the UnicodeMS font,
<nigel> .. and might render it all in that font, but if the user wanted the base character in Monaco
<nigel> .. and the generic glyphs for the combining characters from the UnicodeMS font. The auto
<nigel> .. behaviour would not do that.
<nigel> Nigel: Have any users ever asked for this?
<nigel> Glenn: I'm aware of it in XSL-FO. We really need it for the auto semantics. If we did not
<nigel> .. specify this feature then we have a gap in that we have not defined the implied automatic
<nigel> .. semantics anywhere. If we did not do that then we would have to have a special semantics
<nigel> .. subsection for font selection.
<nigel> Nigel: This wasn't a problem in TTML1, and nobody has asked for it.
<nigel> Glenn: Saying nothing doesn't address this.
<nigel> .. It's been recognised for a long time that this is a missing piece of specification material,
<nigel> .. going back to the change proposals.
<nigel> ack atai2
<nigel> Nigel: I think we have not enough time to add this detail now.
<nigel> Glenn: If we cannot merge the pull request then let's see.
<nigel> Andreas: What is the process if we cannot agree the pull request?
<nigel> Nigel: I think if we cannot merge it we cannot publish a CR with an empty section in it, so
<nigel> .. we have to defer by default.
<pal> q+
<nigel> ack atai2
<nigel> ack atai
<nigel> Glenn: There's no risk to the group since if a problem is found then the feature can be
<nigel> .. removed post-CR, since it is marked as at risk.
<nigel> ack pal
<nigel> Pierre: There's risk to the group because this takes our time away from dealing with features
<nigel> .. that users have asked for.
<atai2> q+
<nigel> ack atai2
<nigel> Andreas: Not sure if I'm being naive here but I assume that at risk features in a CR have
<nigel> .. been reviewed carefully by the WG, and it is only at risk because there may not be enough
<nigel> .. implementations for it. In this case it is not reviewed sufficiently, and there are concerns
<nigel> .. so there are two options: Wait until we can resolve it, or defer it. We did not want to wait,
<nigel> .. so I don't see where we have a lot of options other than to defer it.
<nigel> Pierre: If the question is between deferring and missing the deadline then defer it.
<nigel> Glenn: The group can say include it right now.
<nigel> Pierre: I think this is a request to merge this without review.
<nigel> Glenn: No, I'm not suggesting to thwart the 14 day cycle.
<nigel> Pierre: In order to go to CR today we have to do that.
<nigel> Nigel: We said in one week's time.
<nigel> Pierre: That's fine.
<nigel> .. I don't have a large stake in this, but if someone is going to object to going to CR
<nigel> .. because of this then that's a problem for me.
<nigel> Nigel: My problem with this PR is that it is too late.
<nigel> Glenn: I don't accept that. We're done when we're done.
<nigel> Pierre: We have to be done in one more week.
<nigel> .. If we merge this today then I will object.
<nigel> Glenn: I will object to going to CR without this being included.
<nigel> Nigel: At the moment I have an objection to merging as is, per my pull request review.
<nigel> Glenn: You can record in the minutes that I'm objecting to removing this.
<nigel> .. We either need to merge this or merge an alternative pull request to remove it.