From: fantasai (firstname.lastname@example.org)
Date: Tue Feb 20 2007 - 17:36:28 CST
Asmus Freytag wrote:
> On 2/20/2007 5:10 AM, fantasai wrote:
>> Paul Nelson (ATC) wrote:
>>> CSS is a higher level protocol. There is room for a higher level
>>> protocol to override things, for example, by specifying the PRE.
>> CSS is indeed a higher-level protocol. However, UAX14 sets explicit
>> limits on what a higher-level protocol can do:
> My position is that a higher level protocol is able to also offer
> non-compliant modes, such as the unrestricted mode, or the emergency
> mode. Either one of these modes are by design outside the limitations
> since the protocol would not "/purport to implement the Unicode Line
> Breaking Algorithm"/ for those modes.
I can accept that the unrestricted mode does not "purport to implement
the Unicode Line Breaking Algorithm" and therefore is exempt from its
>>>> 1. Spaces are a non-tailorable line breaking class. The description
>>>> of its behavior also includes prescriptions on presentation that are
>>>> not compatible with what CSS prescribes.
>>> The only place where I see problems with the SP definition are in the
>>> PRE situation where we are keeping the widths of all spaces explicitly.
>>> In this case are we really tailoring the line breaking class of the character?
>> AFAICT, there's only two ways of tailoring a class: changing its
>> membership (which is forbidden for SP), or changing the rules in 6.2.
>> The statements governing the presentation of spaces are in 5.1...
> I need to know specifically which behavior you think would need to change.
I see a problem with every sentence in that section *except* the first clause.
Prescribing the presentation of spaces is, imho, not the job of UAX14.
It can provide background information on what implementations typically do,
and even suggest that this might be a good idea, but it should not make any
normative requirements about whether spaces are measured for fit, or kept
together invisibly, or things like that.
Furthermore, the statement that "the space characters are explicit break
opportunities" conflicts with the model in the rest of the draft that they
don't provide a break opportunity when between certain character classes.
> The reason that I have always resisted to put a formal description of
> the emergency mode behavior into UAX#14 is that it's not clear to me
> whether a single preferred method exists, or whether it would have to
> be tailorable itself.
> I think emergency modes don't arise from the nature of the characters, so
> the role of the UTC as owner of the character properties in standardizing
> character behavior in this case is not so clear.
UAX14 already mentions emergency line breaking, and seems to allow it,
and that's fine. If you wanted to further define it, I would suggest
only requiring that combining marks be kept with their base characters.
This archive was generated by hypermail 2.1.5 : Tue Feb 20 2007 - 17:40:14 CST