RE: More WOFF issues

Given that we are close to the end of the last call window, should I just raise these comments as issues and send to the woff folks, and we can modify them later via email?  Or should we ask for an extension?

RI

============
Richard Ishida
Internationalization Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/




> -----Original Message-----
> From: public-i18n-core-request@w3.org [mailto:public-i18n-core-
> request@w3.org] On Behalf Of Richard Ishida
> Sent: 10 December 2010 13:24
> To: 'Internationalization Core Working Group WG'
> Subject: More WOFF issues
> Importance: High
> 
> While our issue number 2 is out there testing the system, here are some
> more issues I think we should raise. I'm raising here for comments from our
> WG, preparatory to sending out as formal comments.  We need to send
> these asap, so please respond by email if you can, so that we can have a
> discussion prior to the next meeting.
> 
> 
> All the following comments relate to 6. Extended Metadata Block
> http://www.w3.org/TR/WOFF/#Metadata
> 
> [a] Language tag references
> 
> " The possible values for the lang attribute can be found in the IANA Subtag
> Registry [Subtag]."
> 
> This implies that you can only use single subtags, since that is what the
> registry contains (with the exception of a few redundant and grandfathered
> tags.)
> 
> I think this should actually say:
> 
> "The possible values for the lang attribute MUST conform to BCP 47."
> 
> And there should be an entry for BCP 47 in the  References section.
> 
> Similarly, the sentence
> 
> " A user agent displaying metadata is expected to choose a preferred
> language/locale to display from among those available, following RFC 4647
> [RFC-4647]."
> 
> Would be better as
> 
> "A user agent displaying metadata is expected to choose a preferred
> language/locale to display from among those available, following matching
> algorithms in BCP 47 (currently RFC 4647)."
> 
> 
> 
> 
> [b] Description of text elements
> 
> Until I looked at the example, it was not readily apparent to me how the text
> element fitted into the schema.  I think you could make that clearer.  In
> particular, I was expecting to find references to it in the list of elements in the
> last half of section 6.
> 
> 
> 
> 
> [c] Use of attributes for human readable text
> 
> In the schema description, various items that contain human readable text are
> stored as attribute values.  We normally recommend that you don't do this
> (see http://www.w3.org/TR/xml-i18n-bp/#DevAttributes) because of potential
> translation and annotation difficulties (eg. markup of bidi text).  In several
> cases these attributes are the only content on empty elements.
> 
> See also the comment about localization of other elements, such as credit.
> Making the name attribute of the credit element into an element would allow
> for localizations of the name text, which are currently not possible.
> 
> We would suggest converting the attributes to element content. In most cases,
> this does not seem to cause any significant increase in the size of the markup.
> 
> 
> 
> 
> [d] Localization mechanism too restricted
> 
> A font vendor such as Morisawa would probably want a Japanese audience
> to see its name in kanji, but present "Morisawa" to non-Japanese viewers.  To
> enable this, the localised version access mechanism (use of the text element)
> should also apply to the content of the vendor element.
> 
> Likewise, a Tamil font designer would probably want their name in the credit
> element to be available in either Tamil or Latin scripts.
> 
> I'm therefore proposing that you extend the localization selection mechanism
> to vendor, credit and licensee elements (which would also reinforce the
> comment that proposes that the content of these elements be element
> content rather than attribute values).
> 
> 
> I am assuming that this would not apply to the uniqueid element, by definition,
> even though markup authors may use non-ASCII text in the id itself.
> 
> 
> 
> [e] Paragraphs and inline content
> 
> Presumably, text in elements such as description and license can contain free
> flowing text organized into paragraphs. No markup is proposed for
> paragraph support; however nor is it clear from the spec that whitespace
> needs to be preserved for such content.
> 
> I would recommend that some minimal markup be provided for paragraphs
> and that this be supplemented with a span element.  The paragraph and
> span markup would allow for the application of directional markup (see the
> comment about dir attribute) in this content.  For example, to achieve correct
> display of a bidirectional title of a work on which a font is based, or to quote
> a paragraph in a language with a different base direction (quite possible in a
> text element with lang=ar inside a description element).
> 
> 
> 
> 
> 
> [f] Direction attributes needed
> 
> It should be possible to use markup to set the base direction of any element
> in order to enable correct display of bidirectional text.  We suggest a dir
> attribute with the values rtl and ltr as a minimum.  (Additional rlo and lro
> values may also be useful if it is felt that such things as lists of characters are
> likely to appear in the text and control is needed to override the Unicode Bidi
> Algorithm).
> 
> The base direction should apply to text in contained elements (so you could
> have dir="rtl" on a text element that is inherited by paragraph elements
> without need for extra markup.
> 
> In longer pieces of text, such as the description element, it is usually also
> useful to have a span element, to which a direction attribute can be attached
> if the base direction needs to be different from the surrounding context.
> 
> 
> 
> 
> [g] OpenType feature preservation
> 
> Perhaps add some text to the note at the bottom of section 5 to say
> something like this:
> 
> "The automatic removal of opentype features such as GPOS and GSUB
> information at any stage in the process of deploying a WOFF file is strongly
> discouraged. Many writing systems around the world rely on these features
> for very basic display of text."
> 
> It is outside the scope of the WOFF spec, but I think having it mentioned here
> will be very useful in helping people avoid this trap.
> 
> 
> 
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
> 
> http://www.w3.org/International/
> http://rishida.net/
> 
> 
> 
> 
>

Received on Friday, 10 December 2010 13:40:48 UTC