Re: I18N review comments on UAAG 1.0 RESEND

Martin Duerst wrote:
> Hello Ian,
> 
> Some more discussion.

Hi Martin,

Thanks for comments.

>> > #i18n-2:
>> > Checkpoint 2.10, checkpoint provision 1
>> > Is it clear enough how one would know that text is in an 
>> 'unsupported script' or language?  Whether or not something can be 
>> rendered would presumably depend
>> >on the capabilities of the application in a given modality, eg.
>> > font availability in a visual modality (without necessarily a
>> > requirement to understand the underlying semantics if this is a
>> >visual illustration); recognisability
>>  >of text (words) in a text-to-speech modality (without necessarily > 
>> a requirement to be able to display the text).
>>
>> Do you consider the information in the Techniques Document
>> sufficient? What text would you add there?
> 
> 
> Some of the proposals in the techniques doc go beyond what I would
> suggest (see below). Also, the techniques doc says:
> 
> "a character has a value that may not be expressed in the user
> agent's internal character encoding"
> 
> This sounds somewhat outdated. Although HTML 4.0 did not explicitly
> require a User Agent to use Unicode, more and more browsers use it,
> and for XHTML, there is no way around it.
> 
> Another point:
> "HTTP headers provide information about content encoding 
> ("Content-Encoding")"
> 
> Content-Encoding is about compressions such as gzip, and looks
> inappropriate at this place.

Ok, I'll fix that.


[snip]


>> > #i18n-3:
>> > Checkpoint 2.10, checkpoint provision 2
>> > It may be helpful for the user to append "because it is not in a
>> > supported  language or script (i.e. writing system)" to the end of
>> > this sentence (ie.  the UA should indicate the reason that the
>> > text was lost) if one can assume  that the user agent knows that
>> > it is because the text is in an unmanageable language or script.
>>
>> Yes, I agree that would be clearer.
> 
> 
> I think having some way to indicate why the text was lost
> is a good idea. But are there other ways the text can be
> lost? Also, we should be careful that this does not imply
> that the actual explanation has to be given. For example,
> it would be a bad idea if a text-to-speech converter
> would speak 'missing text here because it is not in a
> supported  language'; what we would want to aim at is
> that a special beep (or bell, or whatever other sound)
> would indicate that there is such missing text, and that
> another sound would be used for other cases.
> (please note that I removed 'script' because it's
> largely irrelevant (except for some very special cases,
> i.e. a Mongolian text-to-speech renderer that can deal
> with Mongolian in the Cyrillic script, but not in the
> Mongolian script).


I wouldn't want to require explanations, just an indication
that some author-supplied content has not been rendered because
it could not be handled properly.


>> > #i18n-4:
>> > Checkpoint 4.1, Sufficient technique
>> > Suggest: "render text at 36 points" -> "render Latin text at 36
>> > points".  Reason: rendering Chinese or Arabic fonts at 36 points
>> > may not produce the same degree of clarity as rendering Latin text
>> >  at that size, and different settings may be more appropriate.
>>
>> Ok.
> 
> 
> The text currently says "to configure a reference size for rendered
> text (e.g., render text at 36 points unless otherwise specified)".
> 
> I think this is appropriate in most cases. It is definitely
> true that different scripts can require different font sizes
> for the same 'clarity'. But this can also be said of different
> fonts for the same script.
> The average user is probably more confused by having 'Latin'
> turn up in a setting unless s/he is working already at a script-
> specific level.

I will leave as is then.

> 
> 
>> > #i18n-5:
>> > Checkpoint 4.2
>> > Since global imposition of a Latin-only font could break text in
>> > other scripts, perhaps this should be finessed to say that it
>> > should be possible for the user to specify different user
>> > preferred fonts by script group (much like eg. the common browsers
>> >  allow you to set default fonts for Unicode ranges).
>>
>> I'm not sure that we need it as an additional UAAG requirement;
>> this seems primarily to be an internationalization requirement.
>> Rather than add this as a requirement, I suggest we make your
>> point in the Techniques document.
> 
> 
> To some extent, this is already covered in "1. For text that cannot be
> rendered properly using the user's preferred font family, the user agent
> may substitute an alternative font family."
> The 'may' should probably be changed to a 'should'.

Ok.

> However, it is also not clear at what level the combination of
> different glyphs for different scripts is going to be done
> in the long run. It could be that browsers have to deal with
> this for ages. It could also be that font composition/fallback
> becomes part of font formats, font configuration tools, and the
> OS in general. In that case, the user would only specify
> "MyHelvetica" or some such in the browser, and would have
> configured "MyHelvetica" with a font configuration tool
> provided by the OS.

Yes, that seems like it would be simpler for the user.

Thanks again for comments, Martin.

  - Ian

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

Received on Monday, 30 September 2002 12:16:32 UTC