Section 5 - Implementation Requirements Specifications

5.1 Generator implementation requirements specifications (GIRS)

This section defines "conforming PIP metafile generator", and defines criteria for measuring conformance.

5.1.1 Generator conformance definition

A conforming PIP generator is defined to be one that:

1. produces only conforming PIP metafiles, or can be reliably commanded to function in that mode;

2. conforms to any additional generator implementation requirements as defined in the following subsections and elsewhere in this specification.

3. generates metafiles which fully and correctly define the intended application picture in the format of CGM:1992.

5.1.2 Use of RESTRICTED TEXT

It is recommended, for predictability of metafile interchange, that the RESTRICTED TEXT element be used by metafile generators instead of the plain TEXT element.

Some of the fonts allowed by this profile have standard kerning tables associated with their font metrics, and text presentation systems associated with these fonts often have kerning (both via the standard metrics and via user-defined procedures) as an option. This version of CGM*PIP does not address the kerning option explicitly. Generators shall use the RESTRICTED TEXT element (see section 4.3.6) to transmit graphical text strings in which kerning is in effect.

5.1.3 Degeneracy specifications

This profile does not restrict the generation of primitives which are degenerate in the senses defined in CGM:1992 annex D sections: D.2.2, D.2.3, D.4.5.4 through D.4.5.8, D.4.5.11, and D.4.5.12. Such degenerate primitives have the meanings defined in these sections.

5.2 Interpreter implementation requirements specifications (IIRS)

This section defines "conforming PIP metafile interpreter", and defines criteria for measuring conformance.

5.2.1 Interpreter conformance definition

A conforming PIP interpreter is defined to be one that:

1. correctly reads any conforming PIP metafile of the same conformance category;

2. correctly implements all of the specifications of this profile. In particular: all of the specifications of CGM:1992 shall be accurately implemented except as modified by this profile.

3. successfully parses and skip any elements which are not allowed in conforming PIP metafiles, and ignores any parameter values which are not included in the basic value set of conforming PIP metafiles;

4. renders conforming PIP metafiles to produce pictures which accurately and correctly represent the metafile being interpreted, as defined in section 5.2.3.

5. conforms to any additional interpreter implementation requirements as defined in the subsections below.

As defined above, a conforming PIP interpreter can conform to any of the three colour sub-categories monochrome, grayscale, or colour, and to any of the two extension sub-categories basic or extended/seismic, and to PIP level I or PIP level II.

The results of interpreting a conforming PIP metafile with a conforming PIP interpreter are completely predictable across conforming implementations.

5.2.2 Handling of empty pictures

A picture which has graphical primitives in the picture body, but which has no visible graphical primitives as a consequence of clipping, shall result in the production of one blank copy of medium in the defined background colour (or colour index 0, if that has superseded the background colour).

It is recommended that interpreters provide or log an informational message to alert the user that such a situation has occurred (i.e., to explain why the medium is blank).

5.2.3 Fidelity - specific requirements

5.2.3.1 Interpreter geometric accuracy and latitude

Interpreters shall render graphical primitive elements accurately to at least within 0.1% of the specification in the metafile, including placement of primitives and geometric size aspects of primitives. The tolerance is defined and measured relative to the extent of the picture. This requirement shall apply to all graphical primitive elements and aspects, unless superseded by specific element requirements elsewhere in this (IIR) clause.

5.2.3.2 Colour rendering

For the purposes of the discussion of this clause, the presentation of metafile colour information by interpreters is modelled as a 2-step process. In the first step, the interpreter maps the metafile colour information, whether indexed or direct, to an intermediate abstract discrete colour space, designated as "the Required Interpreter Support Set". This will be called the colour mapping step (CMS). Example: PIP permits an unlimited number of distinct colours in the metafile in 'direct' colour selection mode. In the CMS of conforming full colour PIP/I interpreters, the CMS shall map each colour in the metafile to a colour that is no further away in the RGB space than the nearest point on a uniform 16x16x16 grid of the RGB unit cube.

In the second step of the colour presentation model, the interpreter chooses a representation for each colour in the Required Interpreter Support Set, and renders the colour. This will be called the colour rendering step (CRS). Examples: a CMYK printer uses colour dither algorithm to approximate the 4096 colours in a 16x16x16 gridding of the RGB cube; a black-and-white raster laser printer interpreter maps all foreground colour information to black.

The CMS and CRS minimal requirements for each colour classification of conforming PIP interpreters shall be:

It should be noted that these definitions allow hardware which is inherently limited to qualify for a higher conformance category. For example, raster hardware which has only black and white can qualify as grayscale with the proper construction of dithers to simulate grays. And hardware which inherently can only produce the 4 colours cyan, magenta, yellow, and black can qualify as full colour conforming by use of common colour dither techniques.

Additional colour specifications:

1. In the absence of explicit COLOUR CALIBRATION (not permitted in PIP/II/3), there is no implicit colour calibration specified by this profile. Calibration is interpreter dependent.

2. Interpreters that compute conversions between different Colour Models shall use the ISO/IEC standard conversions presented in annex G of CGM:1992.

5.2.4 Text rendering

5.2.4.1 Treatment of text precision

Conforming PIP interpreters shall render all text at 'stroke' precision (as defined by the CGM element TEXT PRECISION), regardless of the value of the metafile TEXT PRECISION element.

5.2.4.2 Accuracy of text rendering

Interpreter-rendered text shall match the text specification of the metafile to within 1% for the placement and overall extent of each text string.

5.2.4.3 Font substitution

A conforming PIP interpreter may substitute other fonts for valid PIP fonts when rendering a conforming PIP metafile. Substituted fonts shall have similar visual characteristics (e.g., posture, weight, serif vs. non-serif, proportionate width, etc.) and metrics to the font requested in the metafile. This allows a good quality filled font to be substituted for a stroked Hershey font, for example.

5.2.5 Fonts and Character Sets

PIP contains in the Basic Set the character sets ASCII and ANSI X3.134/2 ("Right Hand Part of Latin Alphabet Number 1"). PIP also specifies the Hershey fonts as one of the basic font families. There is finally the requirement that the requested character set be representable in the requested font.

It may not be possible to precisely satisfy all of these specifications at once. For example, "glyph complement" is a property of font definition (in the font model of ISO/IEC 9541:1991, the ISO font standard). X3.134/2 is not fully representable in the digitized databases of the original public domain versions of the Hershey fonts. For the purposes of this specification, those characters of X3.134/2 which are not contained in the original Hershey set should be rendered in a way that is consistent in style and metrics. For example, the style and metrics of a Hershey version of the character "LOWER CASE A ACCENT GRAVE" should have an obvious relationship to those of "LOWER CASE A".

This problem does not arise in the other font families of this specification.

The Hershey "fonts" are really a mixture of fonts and character sets (e.g., Greek is a character set). The requirements of this specification shall be served by providing that the necessary character sets be supported in part, and the necessary typefaces be supported in part, so that the combinations required to render the listed Hershey "fonts" shall be supported in full.

5.2.6 Mapping more colour to less colour

5.2.6.1 Overriding principles

In cases where it is permitted to map metafile colour or gray specifications (e.g., many metafile colours to fewer or different interpreter colours, or colour to monochrome) the following principles shall be applied.

If the metafile colour selection mode is 'direct':

1. the value of the metafile BACKGROUND COLOUR shall map to one of the device colours (the background colour);

2. any colour value of any other metafile element which is exactly equal to the value of the metafile BACKGROUND COLOUR shall also map to the device background colour;

3. all other colour values in the metafile shall map to another device colour, which shall be distinct from the device background colour, and which shall be closest to the specified metafile colour according to some metric applied to colour space.

If the metafile colour selection mode is 'indexed', only the BACKGROUND COLOUR and COLOUR TABLE elements contain RGB values to be mapped. The metafile "effective background colour" is defined to be the value of the BACKGROUND COLOUR element, or the value of the COLOUR TABLE setting of index 0 if the BACKGROUND COLOUR has been thus superseded. The mapping principles shall be:

1. the effective background colour shall map to one of the device colours (the background colour);

2. any COLOUR TABLE values which exactly match the effective background colour shall also map to this value;

3. all other RGB values shall map to another device colour, which shall be distinct from the device background colour, and which shall be closest to the specified metafile colour according to some reasonable metric applied to colour space (for example, Euclidean in CIEXYZ colour space). This version of PIP does not mandate any particular definition of "reasonable metric".

5.2.6.2 Specific Mapping Rules

This version of PIP does not define any specific mapping rules for interpreters.

5.2.7 Number of direct colours supported

The number of distinct colours in conforming PIP direct colour metafiles is not restricted. An interpreter which approximates continuous direct colour with the nearest point in the discrete uniform subset of the RGB colour cube, supporting at least the grid of 16x16x16 (4096 colours), shall be considered PIP (colour) conforming.

5.2.8 Mapping formulae - colour to gray

PIP conforming interpreters shall use the colour to gray formula of clause D.3.2.1 of CGM:1992.

5.2.9 Mapping CGM pattern dimensions to interpreter patterns

This version of PIP does not define any specific rules or algorithms for remapping metafile pattern dimensions to device pattern dimensions in PIP interpreters.

5.2.10 Mapping CELL ARRAY onto raster of different size

This version of PIP does not define any specific rules or algorithms for mapping the cells of metafile CELL ARRAY to device raster pixels in PIP interpreters.

5.2.11 Error processing

If a conforming PIP interpreter encounters an element which is not understood by the interpreter (meaning, it is not a permitted PIP element or its data is outside of the Basic Set), then that element shall be skipped, appropriate error warnings generated or logged, and interpretation continue with the next element following the problem element.

It is possible in binary encoded metafiles that certain syntax errors make the metafile unparsable. On the other hand, there are many classes of metafile syntax error where it is possible to devise strategies for metafile interpreters to recover from the error and continue with the metafile.

This version of the PIP specification does not attempt to quantify the distinction between recoverable and unrecoverable errors.

It is strongly recommended that conforming PIP interpreters contain and execute strategies for recovering from those metafile syntax errors that are in fact recoverable.

5.2.12 Rendering of colour blending

5.2.12.1 CMYK raster plotters

For the class of colour plotter which are raster based, CMYK driven, and do not have continuous tone pixels, PIP conforming interpreters shall render as follows when 'blending method #1' is selected by the Colour Blending ESCAPE of section 4.3.9.3.

Assuming that the rasterizer uses n-by-n "dither cells" for each of the C, M, Y, K colour planes, then source information is combined with destination information by the logical OR operation. That is, when corresponding dither cells in the same colour plane are combined:

• if the bit in the destination is already set, it remains set regardless of the value of the corresponding bit in the source;

• if the bit in the destination is not set, then it will remain not set if the corresponding source bit is not set;

• if the bit in the destination is not set, then it will be set if the corresponding source bit is set.

5.2.13 Treatment of degeneracies

It is recommended that interpreters follow the guidelines of CGM:1992 annex D.2.1 regarding the treatment of syntactic degeneracies, and furthermore that interpreters report the detection of such situations.

Interpreters shall render geometrically degenerate primitives as defined by the CGM:1992 annex D sections: D.2.2, D.2.3, D.4.5.4 through D.4.5.8, D.4.5.11, and D.4.5.12.