Summary: Lack of consistency in notation of values and dimensions. Justification: There is no coherent dimension notation throughout the specification, for instance the relative dimension "87,5" is sometimes represented by "pct87", sometimes by "87500" or even by "4375". This will cause confusion and could lead to non-interoperable implementations.

Put in place a coherent value system.

[Part 4] 2.18.85, etc.

ed

Proposed Disposition of DIS 29500 Comment NO-0012 (Modified: 2008-01-11) As noted by the comment, there are several features in the specification that leverage percentage values to specify measurement. The vast majority of these specify the value in whole or partial percentage units. At other times, they are part of an enumeration of specific values, which represent a specific pattern mask (therefore, although they appear percentage-based, each is a discrete value in a finite list). Although various units of measurement are used throughout the specification, we believe this was the correct design given the goals of the standard. An examination of the granularity allowed in the legacy binary documents was taken into account, which formed the basis for each unit of measurement specified. As well, the decision to choose a specific unit of measure took into consideration the specific context in which it is used. In some cases a very granular unit of measurement is needed to properly preserve user data, while in other cases that level of granularity may not be necessary. We believe it may be valuable in future versions though to consider providing more control over the units of measurement. As an example of how further control over the unit of measure could be implemented, consider the following possible extension to the font-size element (Part 4, §2.3.2.6): <w:p> <w:r> <w:rPr> <w:sz w:unit="points" w:val="32" /> </w:rPr> <w:t>Sample text.</w:t> </w:r> </w:p> As another example, consider the following possible extension to the page-size element (Part 4, §2.6.13): <w:sectPr> <w:pgSz w:unit="inches" w:w="8.5" w:h="11" /> … </w:sectPr> These could also be accomplished as follows: <w:p> <w:r> <w:rPr> <w:sz w:val="32pt" /> </w:rPr> <w:t>Sample text.</w:t> </w:r> </w:p> <w:sectPr> <w:pgSz w:w="8.5in" w:h="11in" /> … </w:sectPr> Each of these approaches has merits and disadvantages. For this reason, we do not believe that any change should occur in the current version of the standard. A proper study of this would be undertaken as a maintenance activity, where the proper amount of time and discussion could be devoted to this subject, when the issues regarding defaults, supported units, and other details can be appropriately researched and decided. Note that in regards to Part 4, §2.18.85 (Shading Patterns), the enumeration was designed to cover an adequate range of values from an end user perspective without making the list overly large. The idea of allowing any integer value was also entertained, but given the discrete nature of the list, and the desire to provide a clear mapping from the legacy document format, the decision to was made to explicitly declare the possible enumeration values to ensure predictability. Similar Comments: DK-0143 , IN-0012 , UY-0008