Re: CSS3 Text and UAX14

On 2/20/2007 3:36 PM, fantasai wrote:
> 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:
>>>
>>>   http://unicode.org/reports/tr14/#ConfProtocols
>>
>> 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
> requirements.
OK.
>
>>>>> 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.
>
> http://www.unicode.org/unicode/reports/tr14/#SP
>
> 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.
I appreciate your feedback. Since that is precisely the purpose of the 
text in section 5, the language of the introduction, and in a few cases, 
the language in each description, needs to be improved to make it clear 
that the text is descriptive (and doesn't add requirements beyond what's 
in the rules).
>
> 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.
This needs better wording. "Explicit" here was meant to say that in 
conjunction with most other characters they provided the linebreaks - 
and that they are used explicitly by users for that purpose (for 
example, noone adds an ideograph to a line to get some linebreak, even 
though lines can be broken after ideographs in many cases.
>
>> 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.
That would make a fine recommendation. Do you mean "combining marks" or 
"non-spacing
marks"? Combining marks is more conservative, so that's probably what we 
should add.

A./
>
> ~fantasai
>
>

Received on Wednesday, 21 February 2007 02:03:38 UTC