Submitter: Henderson

Addressed to: JTC1/SC 24/WG 6 Rapporteur Group on ISO/IEC 8632, CGM

WG secretariat: NNI

Date Circulated by WG secretariat: 21 July 1998

Deadline on response from editor: : 3 August 1998

Defect Report concerning IS 8632:1992 Computer Graphics: Metafile for the storage and transfer of picture description information (CGM) Part 3, Binary encoding.

Qualifier (e.g. error, omission, clarification required): Clarification.

References in document (e.g. page, clause, figure and/or table numbers):

Page 7, 2^nd paragraph; page 16, item #11, 3^rd and 4^th paragraphs.

Nature of defect (complete, concise explanation of the perceived problem):

On p.7, 2^nd paragraph, "In all cases, the parameter list length is the count of octets actually containing parameter data — it does not include the padding octet if one is present. It is only at the end of a command that padding is performed, with the single exception of the CELL ARRAY element."

On p.16, item #11: "Each row starts on a word boundary. No row length information is stored since all rows are the same length." Following is a formula for the fixed length of rows, which incorporates the possible octet to align the next row to a word boundary.

For rows which require an odd number of octets, all rows but the last will require a padding octet at the end. The last will not require the padding octet, because there is no next row to align. But it would require the element-alignment octet, which is not to be included in the parameter list length. Therefore there is an ambiguity and contradiction.

Both ways of implementation are in practice. It is a trivial and formal point, whether the parameter list length in this case includes the extra octet (as implied in some places on p.16) or does not include it (as implied on p.11). Rather than invalidate existing implementations, the standard should tolerate either case on this element.

On p.16, after the 4^th paragraph add: "In the case that a padding octet is needed in each row to align the next row on a word boundary, this octet is not actually needed on the last row. It is optional, for PACKED mode on the CELL ARRAY element, whether the element list length parameter of the command includes this final octet or not."

Editor's response (any material proposed for processing as a technical corrigendum to, an amendment to, or a commentary on the International Standard or DIS final text is attached separately to this completed report):

On p.16, #11, 4^th paragraph (beginning "The colour data thus…"), prepend to the beginning of the paragraph: "For all rows of the cell array, except possibly the last row, "

To the end of that paragraph add: "Because the last row does not have a subsequent row which must align on a word boundary, which alignment (for all other rows but the last) potentially requires the addition to the end of the row of a padding byte, the colour data of the last row occupies ny*(1+[(p*nx-1)]/8) octets (however, see Clause 9)."

To the end of clause 9 add two new paragraphs:

"The following alternative coding representation shall be allowable in metafiles which conform to this encoding. For the CELL ARRAY element, in the case that a row-alignment byte is required for all rows but the last, in conformance to the first formula in the fourth paragraph of note 11 following Table 1, the last row may be coded with the same data length as the other rows, rather than applying the second formula of note 11 to the last row.

NOTE -- Using this alternative encoding would result, in the case described above, in the parameter list length of the element or partition being greater by one octet, than if the specifications of note 11 were followed precisely. It would not affect the starting location of the next element in the metafile."