- From: Glenn A. Adams <gadams@xfsi.com>
- Date: Thu, 27 Oct 2005 18:21:54 -0400
- To: "Bert Bos" <bert@w3.org>
- Cc: "W3C Public TTWG" <public-tt@w3.org>
Dear Bert, Thank you for your responses [1] to our initial response [2] to your comments [3] to DFXP WD LC [4]. The TT WG has carefully considered your further comments and follow-on responses, and has agreed to the following follow-on responses, which are labeled with "[TTWG Response 2005-10-27]". To reduce clutter, we have removed from below the comments for which you had no further response or comment. At this time, we do not expect any further responses; however, you are free to comment or respond further if desired. Regards, Glenn ------------------ Glenn Adams, XFSI; Cambridge, MA; (e) glenn at xfsi dot com Chair Timed Text Working Group (TT WG) ------------------ Citations [1] http://lists.w3.org/Archives/Public/public-tt/2005Oct/0001.html [2] http://lists.w3.org/Archives/Public/public-tt/2005Aug/0014.html [3] http://lists.w3.org/Archives/Public/public-tt/2005Apr/0039.html [4] http://www.w3.org/TR/2005/WD-ttaf1-dfxp-20050321/ > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 6.2.2) Are GPS time coordinates really needed? Their semantics are > the same as UTC, aren't they? What is the use case? > > Response: > > The semantics of GPS are distinct from UTC. The primary difference is > that UTC is adjusted for leap seconds, and may have seconds labeled > 23:59:60 and may have minutes that are missing the second labeled > 23:59:59. As of January 1, 1999, GPS - UTC = 13s. The use case for > GPS involves the fact that GPS is widely used in television broadcast > in the US for synchronization purposes. For example, the ATSC A/65 > Program and System Information Protocol (PSIP) standard is used to > transmit television program schedule information via terrestrial > digital transmission in the US, and PSIP makes use of GPS time > coordinates to express begin and end times for programming. OK, that explains it. But maybe something like this could be added as a note. Not many people know what you just wrote. The grammar in 10.3 also doesn't say that 23:59:60 is illegal for GPS. Without some explanation, you risk that programmers will just do "#define GPS UTC" and save themselves some coding. [TTWG Response 2005-10-27] Normative references to GPS and UTC definitions have been added. In addition the following note has been added: "Note: The primary difference between GPS time and UTC time is that GPS time is not adjusted for leap seconds, while UTC time is adjusted as follows: UTC = TAI (<emph>Temp Atomique International</emph>) + <emph>leap seconds accumulated since 1972</emph>. TAI is maintained by the <emph>Bureau International des Poids et Mesures</emph> (BIPM) in Sevres, France. The GPS system time is steered to a Master Clock (MC) at the US Naval Observatory which is kept within a close but unspecified tolerance of TAI." > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 7.1.1) Is xml:space necessary? You'll have to have style attributes > for space handling anyway, so why complicate matters by doing a half > job in XML? > > Response: > > We are not sure what is meant by "doing ... [the] job in XML". Our > understanding is that a compliant XML processor must always "pass all > characters in a document that are not markup through to the > application". Our understanding of xml:space is it permits the author > to express whether the application should use its "default > white-space processing mode" or should "preserve all white-space". > Since we have not introduced the full range of whitespace processing > style properties into DFXP, such as XSL's linefeed-treatment, > white-space-collapse, white-space-treatment, and > suppress-at-line-break properties, we instead rely upon use of > xml:space as an alternative mechanism for specifying authorial > intention regarding whitespace preservation. Nevertheless, we believe > it may be useful to re-express the algorithm specifying the meaning > of xml:space="default" to instead normatively reference the semantics > of the above mentioned XSL properties. Having just two keywords (default and preserve) probably doesn't allow the author to express everything he wants (such as preserve spaces and still allow line breaks, or vice versa). CSS at first also had just those two values (called 'normal' and 'pre', resp.). So we expect that there will be demand for more values... xml:space itself is not extensible, because its syntax is defined by XML. If white space handling is made more flexible, DFXP will need a new attribute. It might be better to drop xml:space and use a white-space attribute right away. But defining xml:space in terms of the features of XSL (or the newer ones of CSS[1] currently under development), will at least make xml:space=default do something useful in all languages & scripts. The meaning of xml:space=preserve is currently not defined and should also be defined, maybe in a similar way. In particular, does wrapOption override xml:space=preserve or the other way round? In conclusion: using the 'white-space' property from CSS/XSL would be better, especially in view of future extensions; if you define xml:space as you say you will, the response is acceptable. Don't forget to define xml:space=preserve as well! [1] http://www.w3.org/Style/Group/css3-src/css3-text [TTWG Response 2005-10-27] The previous definition of the semantics of xml:space as found in section 7.2.3 has been changed to the following in order to rely upon the semantics of XSL-FO which is normatively used by DFXP to define formatting and layout: <quote> The semantics of the value "default" are fixed to mean that when performing presentation processing of a document instance as described by 9.3.2 Synchronic Flow Processing, processing must occur as if the following properties were specified on the affected elements of the intermediate XSL-FO document: * suppress-at-line-break="auto" * linefeed-treatment="treat-as-space" * white-space-collapse="true" * white-space-treatment="ignore-if-surrounding-linefeed" Similarly, the semantics of the value "preserve" are fixed to mean that when performing presentation processing, processing must occur as if the following properties were specified on the affected elements of the intermediate XSL-FO document: * suppress-at-line-break="retain" * linefeed-treatment="preserve" * white-space-collapse="false" * white-space-treatment="preserve" When performing other types of processing intended to eventually result in a visual presentation by means other than those described in this specification, the semantics of space collapsing and preservation as described above should be respected. For other types of processing, the treatment of the xml:space attribute is processor dependent, but should respect the semantics described above if possible. </quote> > > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 7.1.3) Attributes begin, dur and end are on <tt> and on <body>. Are > they needed on both? > > Response: > > Distinct timing context is required on <tt> as opposed to <body> in > order to provide a timing container for <head> and thence to <layout> > and <region>, the latter of which can be animated. Regions that may or may not exist at the time some content is available for it... sounds like a headache for authors. All the timing info on the content, as in SMIL, seems much more manegable. But we'll take your word for it... [TTWG Response 2005-10-27] The timing attributes on <tt> have now been removed, with those on <body> being used instead. > > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 7.1.7) Is the <br> needed? You can also use two <p> elements if you > need two lines. > > Response: > > In XSL, <fo:block/> does not produce a block area since it has empty ,> content. Since TT AF maps <p/> to <fo:block/> semantics, two empty > <p/> elements from the TT namespace would map to: > > <fo:block/> <fo:block/> > > and thus not produce any visible side effect. > > In contrast, > > <p> <br/> </p> > > is defined to produce the same result as > > <fo:block> <fo:character character="
" > suppress-at-line-break="retain"/> </fo:block> > > We will review if additional clarification is required to express > these intentions. The question was why <p>First line.<br> Second line.</p> instead of <p>First line.</p> <p>Second line.</p> It still seems there is no need for the <br> element, neither to start a new line nor to create empty space (the latter can be done with padding, e.g.). But it doesn't matter. [TTWG Response 2005-10-27] We believe it is useful to allow an author to express paragraph blocks independently from forced line breaks within a paragraph block. > > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 7.1.7) What happens if you put two <br> elements in a row, do you get > an empty line or not? > > Response: > > Given > > <p> <br/> <br/> </p> > > a compliant presentation processor produces the same results as: > > <fo:block> <fo:character character="
" > suppress-at-line-break="retain"/> <fo:character character="
" > suppress-at-line-break="retain"/> </fo:block> So the intention is that <br> is a hard line break. Fine. But are you sure that U+2028 produces a line break? It doesn't in CSS. (It wasn't explicit before, but in CSS 2.1 it is.) [TTWG Response 2005-10-27] It is certainly our intention that <br/> produce a hard line break. We will investigate XSL FO semantics and make any necessary modifications to ensure that our intention can be consistently realized according to XSL FO usage. > > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 8.1.1) What happens if a DFXP document has a style PI? I assume a > DFXP application will ignore it (just like a generic XML viewer will > ignore the <styling> elements). > > Response: > > No normative semantic has been defined for any processing > instruction; therefore, a compliant presentation processor may > ignore. Might be useful to say somewhere that DFXP doesn't use the style PI, but it's up to you. [TTWG Response 2005-10-27] The following language has been added to the prologue of section 8: "No normative use of a stylesheet processing instruction is defined by this specification." > > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 8.2.10) The note says that a horizontal font-size is useful in > systems that have two fonts: normal and double-width. But do you > expect a horizontal font-size to work on any other system? or with > any other value than "1c" or "2c"? > > Response: > > We believe that specifying both horizontal and vertical sizes may > produce a continuously varying anamorphoic transformation on devices > capable of rasterizing fonts in a rectangular EM square. We do intend > to mandate that a given compliant presentation processor must support > either continuous anamorphic scaling of EM square or support some > discrete set of anamorphically-transformed font sizes. > > We also recongize that this feature constitutes an extension not > presently supported in XSL, and isn't adequately addressed by section > 9.3.2 sub-items 6 and 7 (pertaining to populating XSL style > properties). Therefore, we will add additional normative language to > 8.2.10 that expresses the intended semantics. We hope that that additional language is easier to understand than this response, though :-) [TTWG Response 2005-10-27] We will re-review the language of the referenced note and make additional improvements if warranted. In addition, the following has been added to the definition of ttp:cellResolution in 6.2.1: "Note: The use of a uniform grid is employed only for the purpose of measuring lengths and expressing coordinates. In particular, it is not assumed that the presentation of text or the alignment of individual glyph areas is coordinated with this grid. Such alignment is possible, but requires the use of a monospaced font and a font size whose EM square exactly matches the cell size." Also related, the following has been added to the definition of the <length> syntactic construct in 8.3.11: "When specified relative to a font whose size is expressed as a single length measure or as two length measures of equal length, the unit of measure em is considered to be identical to that defined by [XSL 1.0], § 5.9.13; however, when specified relative to a font whose size is expressed as two length measures of non-equal lengths, then one em is equal to the inline progression dimension of the anisomorphically scaled font when used to specify lengths in the inline progression direction and equal to the block progression dimension of the scaled font when used to specify lengths in the block progression direction." > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 8.2.17) "padding" allows one, two or four values. Why not three, as > in XSL/CSS? > > Response: > > We did not find the use of three values to be a particularly useful > feature, and did not need to support the limited subset of TT AF > expressed by DFXP. It is possible that AFXP will support the larger > subset. It's certainly less often used than the others, but if the feature is meant to be the same it is good if the syntax is the same, too. It makes sharing code and experience easier. Please consider adding the missing syntax and especially don't make the syntax different between DFXP and AFXP. [TTWG Response 2005-10-27] We will add the three value form in order to improve interoperability as suggested. > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 8.2.19) "textAlign" doesn't allow values "left" and "right" as in > XSL/CSS, although it is much easier for an author to write "left" > than "start" (or "end") when he means "left." Also, when converting > from/to other formats, it is easier if the value for textAlign in > DFXP is a direct translation of the corresponding value in the other > format, rather than a function of that other value and the > "direction" property. > > Response: > > We think that when at author writes "left" in a LRTB writing mode, > that they actually mean "start". We want to encourage the author to > express their logical intention. We are not certain if there is a > strong use-case for specifiying non-relative (absolute) text > alignment. It's doubtful there is a use-case, even a weak one, for context-dependent keywords. Imagine somebody asks you: "How do I right-align my text?" You answer: "Simple. textAlign=end." Unfortunately, some or all of his text was in Arabic... The claim that relative keywords are better is based on the assumption that style sheets for one script can be re-used for another. It's doubtful that that assumption holds, even for trivial style sheets. And in the case of DFXP, there isn't even a style sheet; the alignment and the text are specified together. Why would you make it difficult for somebody who just wants his text on the right? 99.9% of the DFXP documents will be in only one script. And, in fact, people who write documents with both a ltr and a rtl scripts will have an even more difficult time. Not only do they have to translate in their mind right/left to start/end, but they will have to change that mapping when they change scripts. To right-align an English paragraph, they will have to use textAlign=end, but to right-align a Hebrew paragraph, they will have to use textAlign=start. Also, DFXP is meant to be transformed to other formats, depending on the software or hardware that actually displays the text. There are dozens of timed text formats, but none that support script-relative text alignment. So all converters will have to implement a translation from start/end to left/right, which is an extra risk of bugs. You can simulate left and right with start and end, but it is an extra hurdle for users. We strongly advice you to add left and right. [TTWG Response 2005-10-27] We will add "left" and "right" absolute values to improve interoperability as suggested. > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 8.3.6) The generic font family names suggest specific kinds of fonts, > but the spec effectively says to expect nothing. In that case, why > aren't they called "font1" to "font5"? Some help for implementers > seems useful. If an implementation has different fonts available, I > think users would like it if the fonts are mapped somewhat > intelligently. > > Response: > > Well it is either implementation dependent or not. We really want the > former. We prefer to let the market decide whether an implementation > does something sensible or not. To do something formal would require > introducing PANOSE concepts or equivalent which doesn't seem > particularly worthwhile. There is a middle ground between not specifying anything and specifying every last bit. The names clearly suggest that the font families are neither arbitrary nor fully specified, but the definition fails to follow up on that. Whether the "market" will solve it depends on how open that market is. If there is a dominant implementation that fails to do something reasonable, then the result is effectively that the feature disappears, independent of whether users want it or not. But we won't insist. Let's just hope that by the time the spec is updated the "market" will not have made it impossible to fix this. [TTWG Response 2005-10-27] The relevant material in 8.3.6 has been modified to read as follows: "The mapping between a generic (font) family name and an actual font is not determined by this specification; however, the distinction of monospace versus proportional and serif versus sans-serif should be maintained if possible when performing presentation." where the clause starting "however, ..." has been added. > > ********************************************************************* >** > > Comment: Issue #10 [1]; 22 Apr 2005 20:44:52 +0200 > > 8.3.6) The generic font families are different from those in XSL/CSS. > Maybe DFXP doesn't need "fantasy" and "cursive," but it could have > kept > > "sans-serif" and "serif" without renaming them. Also, is the > difference "monospace-sans-serif" vs "monospace-serif" really needed? > Just one monospace font has been enough for all my uses (which > weren't subtitles, I admit). > > Response: > > The TT WG believes there are a number of examples of all combinations > of {monotype,proportional} x {sans-serif,serif} in use in > international subtitling applications that justify labeling all > combinations. That sounds like a contradiction with the previous issue: it is important to distinguish serif monospace from sans-serif monospace, but it is not important to define that 'monospace-sans-serif' and 'monospace-serif' are different (where possible)? It is a bad idea to use a feature that exists in CSS/XSL (apart from the CamelCase) but change the values. If you are keen on re-use (as your answer to the first issue, on namespaces, indicates), then you should not throw away people's knowledge so easily. There is no reason to rename sans-serif to proportional-sans-serif and serif to proportional-serif. What to do? Clearly, it is possible to define those keywords, but the fact that CSS and DFXP are different for no apparent reason will look bad... [TTWG Response 2005-10-27] We will retain the following values, now camelCased: serif sansSerif monospace and introduce only the following extensions: default monospaceSerif monospaceSansSerif We will further define "monospace" to be arbitrary serifness (as in CSS), while the new qualified forms are specific. We will use the existing "serif" and "sansSerif" instead of the proposed replacements: proportionalSerif and proportionalSansSerif. *********************************************************************** END
Received on Thursday, 27 October 2005 22:22:05 UTC