Paul Grosso wrote:

> Peter,
> Again, thanks for your input.  Comments embedded.
> At 00:53 2001 09 27 -0400, Peter B. West wrote:
>>The following sections contain references to start-space and end-space.  
>>I assume that these references should be to space-start and space-end.
>>5.5.1 Word spacing and Letter spacing Properties
>>These properties may set values for the start-space and end-space traits, 
>>as described in the property definitions."
>>7.16.2 "letter-spacing"
>>'For an fo:character that in the Unicode database is classified as "Alphabetic", 
>>unless the treat-as-word-space trait has the value "true", the start-space and 
>>traits are each set to a value as follows:'
>>7.16.8 "word-spacing"
>>'For fo:character whose treat-as-word-space trait has the value "true", 
>>the start-space and end-space traits are each set to a value as follows:'
> Yes, all these should be corrected.
>>The quote from 7.16.2 continues:
>>'For "normal": .optimum = "the normal spacing for the current font" / 2, 
>>.maximum = auto, .minimum = auto, .precedence = force, and .conditionality = 
>>A value of auto for a component implies that the limits are User Agent specific.'
>>That is, it allows the .maximum and .minimum sub-properties of a <space> to take on 
>>values of "auto".  "Auto" is not mentioned as a valid assignment to these properties 
>>in wither the general discussion of <space> in 5.11, where .maximum, .optimum and 
>>are defined as <length>s, nor in the discussions of space-start and space-end in 
>7.11.1 & 7.11.2.  
>>Further, in 7.14.1 "block-progression-dimension" and 7.14.5 
>>a value of "auto" is defined to set the three <length> sub-properties to "auto".
> In general, our "data-typing" relates to the refined values, and
> "inherit" and percentages are refined away.
> We plan to make this clearer in section 5.11.
>>Am I right in assuming that, where a compound property is one of the possible 
>>assignments to a property, any specified value imples some computed setting 
>>of each of the compound components?  That is, that there are no circumstances 
>>in which a property which may take a compound "datatype" will have undefined 
>>computed values for the components?
>>In that case, what are the default values of .precedence and .conditionality 
>>for 7.16.2 "letter-spacing" and 7.16.8 "word-spacing"? 7.16.2 and 7.16.8 do not 
>>discuss conditionality at all, and only indirectly mention precedence.  7.16.2 has:
>>'If it is desired that the letter space combine with other spaces that have 
>>less than forcing precedence, then the value of the "letter-space" should be 
>>specified as a <space> with precedence less than force which implies that space 
>>combines according to the space resolution rules described in [4.3 Spaces and 
>>However, in the absence of any specific default setting, the other indications from 
>>the discussion in 5.11 and in sections where the default values of precedence are 
>>spelled out would indicate a default value of 0.  Likewise, the default value for 
>>conditionality would seem to be "discard".
> We have defined how this works in 5.11:
>   A short form of compound value specification may be used, in
>   cases where the datatype has some <length> components and for
>   the <keep> datatype. In the first case the specification consists
>   of giving a <length> value to an attribute with a name matching a
>   property name. Such a specification gives that value to each of the
>   <length> components and the initial value to all the non-<length> components.
> paul


I'm working off this definition, but the problem with 7.16.2 and 7.16.8 
is that the set of initial values is not discussed in terms of the 
property itself, but, as mentioned at the top of this message, in these 
terms (for 7.16.2):

For an fo:character that in the Unicode database is classified as 
"Alphabetic", unless the treat-as-word-space trait has the value "true", 
the start-space and end-space traits are each set to a value as follows:

I.e., the property initial values are discussed in respect of 
space-start and space-end properties.  Is some translation into these 
properties implied in this discussion, or explicitly noted in the spec?

"Lord, to whom shall we go?"

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to