Re: Questions about <space> compound type


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 end-space 
>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 = discard. 
>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 .minimum 
>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 "inline-progression-dimension", 
>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 Conditionality].'
>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.


Received on Thursday, 4 October 2001 10:19:01 UTC