Skip to content
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

FontFamily009.ttml has a spurious space #7

Closed
palemieux opened this issue May 17, 2017 · 21 comments

Comments

Projects
None yet
4 participants
@palemieux
Copy link
Contributor

commented May 17, 2017

There's a space following the comma before the platform font name Times New Roman. The space is not permitted by TTML1 Section 8.3.5 since the non-terminal <familyName> | <genericFamilyName> are explicitly separated by a comma.

@palemieux palemieux added the bug label May 17, 2017

@palemieux palemieux self-assigned this May 17, 2017

@skynavga

This comment has been minimized.

Copy link

commented May 17, 2017

@skynavga

This comment has been minimized.

Copy link

commented May 17, 2017

By the way, to figure out that CSS2 (1998) actually sanctions this behavior is not so straightforward: it requires one to carefully examine the Grammar of CSS2 found in Section D.1. The following rules are relevant:

expr
  : term [ operator term ]*
  ;
operator
  : '/' S* | ',' S* | /* empty */
  ;

and combining this with the knowledge that a YACC grammar (which this is said to be an extension) allows <lwsp> between non-terminals, in which case you the sequence of non-terminals: term operator and operator term, and, given "," matches operator, <lwsp> is permitted before and after ",".

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2017

The TTML1 specification has very clear syntax rules, which do not permit the presence of spaces. I fail to see why TTML1 can or should be revised.

@skynavga

This comment has been minimized.

Copy link

commented May 17, 2017

No, in this case, it is obviously not sufficiently clear, since you have interpreted it in a manner that is inconsistent with both XSL-FO and CSS usage, which clearly do permit <lwsp> around all terms in a comma separated list. That TTV does not flag what you thought was an error is adequate proof that others (for example, the original TTML1 spec writer) interpreted the TTML1 spec in a manner consistent with XSL-FO and CSS.

Clearly, TTML1 needs an errata that corresponds what we are just today clarified in TTML2:

linear whitespace (LWSP) may appear before and after the sub-expressions of a comma separated list expression;

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2017

No, in this case, it is obviously not sufficiently clear,

It is absolutely clear that "unless explicitly stated otherwise, linear white-space (LWSP) must appear between adjacent non-terminal components of a value of a TT Style or TT Style Extension Property value unless some other delimiter is permitted and used."

@skynavga

This comment has been minimized.

Copy link

commented May 17, 2017

If you parse that sentence you just quoted carefully, it makes a statement about where LWSP must appear; however, it does not make a statement about where LWSP may appear. That is, it does not prohibit the appearance of LWSP around a COMMA. The value expression found under the definition of tts:fontFamily is as follows:

(<familyName> | <genericFamilyName>) (","  (<familyName> | <genericFamilyName>))*

If we interpret the "," as an "other delimiter" in the statement you cite, then that merely indicates that it is not required that LWSP must appear between adjacent terms (since the COMMA serves as an adequate delimiter), but this says nothing at all about whether LWSP may or may not appear between "," and a term. I'm telling you it may. And we now have made this explicit in TTML2, and need to revise TTML1 to make it clear as well.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented May 19, 2017

As mentioned in the call yesterday it would be helpful to have data points of either implementations that do not support white space around delimiters or of documents that include white space between delimiters.

Here is one fairly weak data point, which supports my own expectation that white space is permitted around delimiters: the second document requirement in http://bbc.github.io/subtitle-guidelines/#tts-fontFamily includes the example snippet tts:fontFamily="Roboto, Helvetica, Tiresias".

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2017

@nigelmegitt Thanks for the example.

TTML1 explicitly states in 8.3 that in the syntax representations defined in this section, no linear whitespace (LWSP) is implied or permitted between tokens unless explicitly specified. In other words, rgba( 233, 1,0 ) is never expected in TTML1.

So it looks like tts:fontFamily is the only style attribute value where a COMMA is used as a delimiter, and the potential LWSP ambiguity, if any, exists.

@skynavga

This comment has been minimized.

Copy link

commented May 19, 2017

@palemieux I agree that as stated, TTML1 appears to have excluded whitespace around comma separated terms in argument lists, which only appear in rgb() and rgba() expressions in TTML1; however, this might have been done in error, or without recognizing that both XSL-FO and CSS2 actually did permit whitespace in rgb() expressions [we invented the rgba() expression].

On this point, I think we need to address:

  1. whether to clarify the TTML1 spec (in 3rd edition) to permit whitespace in this context?
  2. whether to allow whitespace in TTML2 in this context?

My current answers to these questions are (1) probably and (2) definitely.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2017

My position below given the evidence provided so far.

whether to clarify the TTML1 spec (in 3rd edition) to permit whitespace in this context?

TTML1 should continue to prohibit LWSP in that context as clearly stipulated today.

whether to allow whitespace in TTML2 in this context?

I have not seen any evidence that such expansion to the TTML syntax, and added complexity to implementations, will bring any benefit.

Whereas CSS includes an extensive grammar and syntax definitions , TTML has never done so.

@skynavga

This comment has been minimized.

Copy link

commented May 19, 2017

I have not seen any evidence that such expansion to the TTML syntax, and added complexity to implementations, will bring any benefit.

Then you clearly assume that all content is machine generated, and not generated by hand, where it is extremely common to insert whitespace in these contexts. Your assumption is clearly false.

Whereas CSS includes an extensive grammar and syntax definitions , TTML has never done so.

Nonsense.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2017

Then you clearly assume that all content is machine generated, and not generated by hand, where it is extremely common to insert whitespace in these contexts.
Your assumption is clearly false.

None of the TTML1 test cases, but for FontFamily009.ttml, include such LWSP.

The only other evidence so far is the one provided by @nigelmegitt , and it concerns only tts:fontFamily.

Two examples out of, presumably millions of documents, is not sufficient in my mind.

Whereas CSS includes an extensive grammar and syntax definitions , TTML has never done so.
Nonsense.

I think the TTWG and the industry deserve a more complete answer for it to be considered.

@skynavga

This comment has been minimized.

Copy link

commented May 19, 2017

I am open to leaving the restriction on rgb() and rgba() in TTML1; however, I am strongly inclined to allow whitespace around all comma separated lists in TTML2, which, if someone insists, we could always featurize.

@skynavga

This comment has been minimized.

Copy link

commented May 19, 2017

@palemieux I should also add that a non-existence proof (that whitespace isn't used in rgb(), etc., in TTML1 files), requires you to examine every file in existence, something nobody can do; however, having said that, I just checked TTV and it rejects whitespace inside rgb() and rgba().

@dronca

This comment has been minimized.

Copy link

commented May 21, 2017

if someone insists, we could always featurize.
It's late to be talking about adding TTML2 features.

@skynavga

This comment has been minimized.

Copy link

commented May 21, 2017

Adding feature designators is not adding features. What we are discussing here is a possible ambiguity that goes back to the beginning of TTML1 (and DFXP), that has permitted some readers to conclude that whitespace is not permitted around the terms of a comma separated list; while other readers (including the original author of TTML1 and DFXP) concludes that it was always permitted (via XSL-FO and CSS2 syntax inclusion). I think we cannot add new feature designators to TTML1, but we can in TTML2.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 21, 2017

What we are discussing here is a possible ambiguity that goes back to the beginning of TTML1 (and DFXP), that
has permitted some readers to conclude that whitespace is not permitted around the terms of a comma separated list;

This is not an accurate characterization: the only potential ambiguity in TTML1 is specifically on whether spaces are permitted around commas in tts:fontFamily. The ambiguity does not extend to other styling attribute and parameter values since only tts:fontFamily uses comma-separated components. Furthermore, in the syntax representations of 'Style Value Expressions', no linear whitespace (LWSP) is implied or permitted between tokens unless explicitly specified.

while other readers (including the original author of TTML1 and DFXP) concludes that it was always permitted (via XSL-FO and CSS2 syntax inclusion).

I have not seen so far participants other than the editor take such a broad view in light of the current evidence, which includes the TTML1 specification text itself, the TTML1 test suite and implementations.

I would be happy to be proven wrong. albeit by concrete evidence. This seems only fair when asking folks to do work.

@skynavga

This comment has been minimized.

Copy link

commented May 21, 2017

You are wrong on a number of points. First of all, I am only talking about tts:fontFamily in my comment. See the title of this issue. Secondly, I wrote the text in TTML1 and DFXP, so I know what was discussed and what wasn't discussed going back to 2003 (and you don't). If you don't want to consider me an authority on the subject, then so be it. Thirdly, if you want to discuss tts:color, then rgb() and rgba() do indeed use comma separated components. It can be clearly shown that both XSL-FO 1.0 and CSS2 1998 permit lwsp in both font-family and rgb() color value expressions. So there is clearly an ambiguity and inconsistency in TTML1 in this regard.

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented May 22, 2017

Secondly, I wrote the text in TTML1 and DFXP, so I know what was discussed and what wasn't discussed going back to 2003 (and you don't).

TTML1 has grown larger than any one of us, and well beyond TTWG. What was said in 2003 is relevant, but much less so that what is written in the specification as it is published.

Thirdly, if you want to discuss tts:color, then rgb() and rgba() do indeed use comma separated components.
[...]
So there is clearly an ambiguity and inconsistency in TTML1 in this regard.

I do not see inconsistency between the clause in the syntax representations defined in this section, no linear whitespace (LWSP) is implied or permitted between tokens unless explicitly specified, which incidentally it looks like you added, and other clauses in TTML.

Anyway, assuming we are focusing on whether LWSP in tts:fontFamily should be explicitly permitted, it would be good to hear from other implementers.

@skynavga

This comment has been minimized.

Copy link

commented May 22, 2017

Yes, I agree that TTML1 says the following, which I wrote:

no linear whitespace (LWSP) is implied or permitted between tokens unless explicitly specified

But this applies only to <color> value syntax in TTML1, and not the outer value expression defined for tts:fontFamily.

Further, in retrospect, I believe the TTWG did not discuss this matter during the development and writing of DFXP/TTML1. At least I don't recall any discussion, and I'm not finding anything in the member-tt or public-tt archives. The closest I've found is [1], which is discussing color space, and not whitespace syntax; however, [1] does affirm the statements I have made about following XSL-FO and CSS2.

[1] https://lists.w3.org/Archives/Member/member-tt/2005Jul/0005.html

If this issue had been raised previously during DFXP/TTML1 development, then I expect we would have allowed LWSP around terms in rgb() and rgba() in order to be consistent with XSL-FO and CSS2 parsing. However, we did not do so, so I agree that we have a legacy situation that appears to exclude LWSP in tts:color. This is why I suggested in a previous message that I would be willing to accept this as a status quo, at least for TTML1. But I do not hold this opinion for TTML2, and believe we should allow LWSP in all comma and semicolon separated lists in TTML2, while at the same time recognizing that we need to keep the restriction in place for TTML1 based content.

@palemieux palemieux removed the bug label Jun 8, 2017

@palemieux

This comment has been minimized.

Copy link
Contributor Author

commented Jun 15, 2017

In light of w3c/ttml1#248 , it looks like TTML1 will be clarified to state that LWSP is permitted around "," in tts:fontFamily.

Closing this issue. Please comment on w3c/ttml1#248 instead.

@palemieux palemieux closed this Jun 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.