Section 4 - PIP/I and PIP/II Metafile Requirements

4.1 Metafile conformance definition

4.1.1 Conforming metafile

A conforming PIP/I metafile shall contain no elements outside of the set defined in this specification and no parameter values outside of the set constrained by this specification.

A conforming PIP/II metafile shall contain no elements outside of the set defined in this specification and no parameter values outside of the set constrained by this specification.

4.2 General metafile requirements

The requirements for conforming PIP metafiles are defined in the following sections. These include a number of general requirements, followed by specific element-by-element requirements.

4.2.1 Encoding format

A conforming PIP metafile shall use only the CGM Binary Encoding, as defined in ISO/IEC 8632-3:1992.

Although the Binary Encoding is the only valid encoding for PIP-conforming metafile interchange, this does not restrict PIP-conforming implementations from supporting and using other encodings. However, every PIP-conforming implementation shall be able to generate and interpret at least the Binary Encoding, whether as a native mode of the implementation or via a "filter" to convert between the Binary Encoding and other CGM encodings.

4.2.2 Identifying information

Conforming PIP metafiles shall at least contain certain specific identifying information. The identifying information shall be included in the string parameter of the METAFILE DESCRIPTION element. Each item shall be a substring within the string parameter. Substrings shall be delimited by matching QUOTE or matching APOSTROPHE characters.

Each required substring shall be identified by a keyword. The keywords are case insensitive. The keyword shall be the first part of each substring, and shall be terminated by a COLON character, with no intervening spaces. Conforming PIP metafiles shall include at least the following information, and the information shall be in the indicated format.

1. The profile identification, level, and version: "ProfileId: PIP/I/3" for PIP/I metafiles and "ProfileId: PIP/II/3" for PIP/II metafiles. (see Note on ProfileId below).

2. The colour classification of the metafile: "ColourClass: xxx", where xxx is Mono, Gray, or Colour.

3. The extension classification of the metafile: "Extension: xxx", where xxx is either 'Basic', 'Extended/Seismic' or 'Extended/CR' (the delimiting apostrophes are not part of these value substrings as they appear in the metafile - they are used for formatting, for the purpose of clarity in this document). In the cases of 'extended', either one or both of the suffixes (seismic or CR) may appear and in any order. CR denotes "Continuous Rendering".

4. The source of the metafile: "Source: xxx", where xxx is a string identifying the product vendor, product, and product version which generated the metafile.

5. The date of metafile generation: "Date: yyyy-mm-dd".

Note: The ProfileId item contains three components. The first identifies the profile to which the metafile conforms, where 'PIP' designates CGM*PIP. The second identifies the level, 'I' or 'II'. The third is the version of the PIP specification - this document defines revision 3 of PIP/I and revision 3 of PIP/II. The version allows for future modifications and improvements to this PIP specification, for example this revision 3 of PIP/I completes the inclusion of one basic drawing capability (the Drawing Mode ESCAPE) which was agreed to by the PIP constituency.

The METAFILE DESCRIPTION string may contain other information, at the option of the implementation. For example, the time of metafile generation may be included (if the time is included, it shall be in the format of the substring "Time: hhmm", where hhmm is the time on the 24-hour clock - time is the only optional item for which the format is standardized by PIP).

If additional information items are included in the METAFILE DESCRIPTION, it is recommended that each item be formatted as a substring, in the style of the required information items listed above. It is recommended that additional information which is very application specific not closely related to the above items be included in an APPLICATION DATA element in the Metafile Descriptor rather than being included in the METAFILE DESCRIPTION element.

Note on ColourClass: Colour subsumes Gray and Mono, and Gray subsumes Mono - a monochrome metafile could be labelled Colour, Gray, or Mono and a grayscale file could be labelled Gray or Mono.

4.2.3 Text string length and contents

The maximum length of an individual string of characters in a graphical text string (e.g., TEXT) shall be: 254. This includes the entire string, including any appended parts.

The maximum length of an individual string of characters in a non-graphical text string (e.g., each string in the FONT LIST) shall be: 1024.

The maximum length of an individual string of characters in a data records, which are coded as strings (e.g., GDP or ESCAPE data record) is: as specified by the individual GDP or ESCAPE definition.

The string parameters of graphical text elements (datatype S), shall not contain any control characters (codes in the ranges 1-31 and 128-159), except as allowed by and necessary to implement the character set switching modes which can be selected by basic values of CHARACTER CODING ANNOUNCER. NUL (code value 0) is allowed and shall have no effect - the string with NULs embedded is equivalent to the string with the NULs removed.

Non-graphical string parameters (datatype SF, e.g., for the FONT LIST element), shall not contain any control characters (codes in the ranges 1-31 and 128-159), except as allowed by and necessary to implement the character set switching of ISO 2022, as defined in CGM:1992 for strings of type SF. NUL (code value 0) is allowed and shall have no effect - the string with NULs embedded is equivalent to the string with the NULs removed.

4.2.4 Indexed colour definition - all or none

If the colour selection mode is 'indexed', then either the background colour and all colour indexes used in the metafile shall have their representations defined, or none shall. A colour index is "used" if it occurs in an element selecting a colour value to be applied to a primitive (LINE COLOUR, CELL ARRAY, etc.). A colour index is also "used" if it is the default for a primitive attribute and the default applies to a displayed primitive. The background colour is automatically "used".

4.2.5 Direct colour definition - all or none

For direct colour selection, either the background colour and the colour of each displayed primitive shall be explicitly defined, or none shall. In other words, either all colours shall be defaulted or none shall.

4.2.6 Number of indexed colours

The number of indexed colours which have explicit definitions at any given point in the metafile shall not exceed: 4096 in 'colour' metafiles; 64 for 'gray' metafiles; and 2 for 'mono' metafiles. In these cases, no colour index value shall exceed, respectively, 4095, 63, and 1.

4.2.7 Number of direct colours

The number of distinct direct colour specifications which may occur within a picture in a conforming PIP metafile is not restricted. See Section 5.2, Interpreter implementation requirements specifications (IIRS), regarding required level of interpreter support.

4.2.8 Number of pictures

A conforming PIP metafile shall contain at least one picture. The maximum number of pictures in a conforming PIP metafile is unconstrained.

4.2.9 Number of metafiles

There shall be exactly one metafile per physical file in conforming PIP interchange media or data streams.

4.2.10 Empty pictures

Pictures which contain no instances of CGM graphical primitive elements are prohibited in conforming PIP metafiles.

It is possible that pictures contain no visible primitives, upon rendering, as a consequence of clipping or transformation. Such pictures are allowed conforming PIP metafiles. See Section 5.2, Interpreter implementation requirements specifications (IIRS).

4.2.11 Partitioning of elements

Any element except METAFILE DEFAULTS REPLACEMENT may be partitioned in PIP conforming metafiles (support of partitioned elements is therefore required of conforming PIP interpreters).

Note: there has been some confusion amongst implementors as to whether or not individual partitions within an element are padded to even-octet boundaries. They are not. Only the beginning of the element, containing the element class and opcode id designators, is aligned on an even-octet boundary.

4.2.12 Physical file structure

This specification does not define media delivery requirements. Such definitions are the responsibility of the application operating environment.

In the absence of such guidance it is recommended that metafiles conforming to this specification be delivered as continuous byte streams (no record structure) where the media and environment permit.

4.2.13 File size

This profile places no limits on the metafile size (according to such measures as bytes, number of elements, etc.).

4.2.14 Required but unused parameters

4.3 Specific metafile element constraints

4.3.1 Notation

The following subsections define, for the parameters of each element, the subset of the range of values permitted by the CGM standard which may appear in PIP conforming metafiles. If a parameter or aspect of an element is not addressed, then it is constrained only by the rules of CGM:1992 itself, or by general specifications elsewhere in the profile. The term none in the "Constraints" column of the tables similarly mean that this profile places no constraints beyond those of CGM:1992 itself, or those specified in associated notes or other specifications of this profile.

A permissible value is a value of a parameter of an element which is legal and permitted by the CGM standard. The term basic value is used in the text of this profile to denote a permissible value which is legal and allowed by this profile. The basic set of a parameter is the set of all basic values.

See Section 8 of this profile for further definitions of terminology.

4.3.2 Delimiter elements

The Delimiter element constraints shall be as specified in Table 1.

Note 1. The general specifications regarding number of Metafiles and number of Pictures apply.

Note 2. Common parameter constraints on the content, length, and allowable character set switching of non-graphical text strings (type SF) apply.

Note 3. Both global segments and local segments are allowed in conforming basic metafiles. When global segments are defined, in the Metafile Descriptor, all global segment definitions shall follow all other Metafile Descriptor elements. There shall be at most 1024 segments defined at any point in the metafile. This includes global segments and local segments.

Note 4. A Closed Figure definition shall include at most 128 other graphical primitive elements. The count does not include CONNECTING EDGE elements. All included graphical primitive elements shall conform to the constraints of this profile.

Note 5. A Protection Region definition shall include at most 128 graphical primitive elements. The count does not include CONNECTING EDGE elements. All included graphical primitive elements shall conform to the constraints of this profile. The maximum number of simultaneously defined regions shall be 32.

Note 6. A Compound Line definition shall include at most 128 graphical primitive elements. All included graphical primitive elements shall conform to the constraints of this profile.

Note 7. A Compound Text Path definition shall include at most 128 graphical primitive elements. All included graphical primitive elements shall conform to the constraints of this profile.

Note 8. The maximum number of tiles shall be 256. The dimensions of each tile shall be less than or equal to 1024 in both the path direction and line progression direction.

4.3.3 Metafile descriptor elements

The Metafile Descriptor element constraints shall be as specified in Table 2.

Note 1. There shall be at least one METAFILE DESCRIPTION element in each conforming PIP metafile. There may be more than one, for example each of the required identifying items in section 4.2.2 may be included in a separate instance of the METAFILE DESCRIPTION element. If there are multiple METAFILE DESCRIPTION elements, then each of the substrings containing identifying information shall be wholely contained within one instance of the element, i.e., the substring contents which occur between matching QUOTE or APOSTROPHE characters shall not be split between instances of the element. When there are multiple instances of the element, it is recommended that they be grouped together without any intervening elements. The METAFILE DESCRIPTION element's (or elements') string parameter(s) shall include the identifying information defined in section 4.2.2. The General Requirements on length and content of non-graphical strings (type SF) of section 4.2.3 shall apply.

Note 2. At most 64 simultaneous fonts are supported. The font names are selected from the font names basic set defined in section 4.3.13. FONT LIST is a mandatory element if there are any graphical text elements in the metafile.

Note 3. This is ANSI X3.4, 7-bit American National Standard Code for Information Interchange (7-bit ASCII). Character set type is '94-character G set' (coded as 0 in Binary).

The notation of the second parameter of the CHARACTER SET LIST parameter pair has caused some confusion amongst implementors. This is a parameter of type SF, String Fixed (non-graphical). 4/2 is "column/row" notation for character code designation (see Section 6 also). 4/2 denotes the character code whose value is 42 hexadecimal (convert the column designator to the first hexadecimal digit and the row to the second), or 66 decimal. If the character code were interpreted according to the default ASCII character set of type SF parameters, it would represent the character "B" - that is, the parameter, considered as an ASCII string, is the single character "B".

Note 4. This is ISO 8859/1, Right-Hand Part of Latin Alphabet Number 1 (ECMA registered), equivalent to right half of ANSI X3.134/2, 8-bit ASCII. Character set type is '96-character G set' (coded as 1 in Binary).

Note 5. For colour metafiles, 0-4095; for grayscale metafiles, 0-63; for monochrome metafiles, 0 or 1. MAXIMUM COLOUR INDEX applies to all colour indexes defined or otherwise referenced, whether they are referenced implicitly or explicitly. This should be clear in CGM:1992 but is not. An example of an implicit reference is a COLOUR TABLE element which defines 100 entries starting at index 250. Only index 250 is explicitly referenced by this element, but index 307, for example, is defined and therefore implicitly referenced.

Note 6. The version value "1" is the only allowed value in conforming PIP/I metafiles. Version values 2 and 3 shall not be used in PIP/I metafiles.

Note 7a. This character set shall be used with the Hershey Greek fonts (cartographic, complex, simplex), or where appropriate with Symbol. Its type is '94-character G set' (coded in Binary as 0), and its tail is equivalent to the 2-character string "/0".

Note 7b. These character sets shall be used with the Symbol font. Their type is '94-character G-set' (coded in Binary as 0), and their tails are equivalent to the 2-character strings "*:" and "&:". If the CHARACTER CODING ANNOUNCER is 'basic 8-bit', then these two halves of the Symbol character set can be treated as a single 8-bit table, whose code assignments are those defined in Section 10 of this profile (which are equivalent to those "PostScript Language Reference Manual, Second Edition", pp. 604-606). If the CHARACTER CODING ANNOUNCER is 'basic 7-bit', then refer to the CGM standard, for the method of referencing and switching between the two halves of the Symbol character set. Note that the code assignments to glyphs for the G-set 2/10 3/10 are identical for the numeric characters (see figure 8, column 3), column 2 except for 2/2, 2/4, and 2/7, most uppercase alphabetics (columns 4 and 5) except for 4/0, 5/12, and 5/15, and most lower case alphabetics (columns 6 and 7) except for 7/6 and 7/14. Most of the commonly used Greek characters match the previous set, (0, 2/15 3/0). It shall be valid to use (0, 2/15 3/0) for the Symbol font where the code assignments match.

Note 7c. This character set shall be used with the Hershey Cyrillic font. Its type is '94-character G set' (coded in Binary as 0), and its tail is equivalent to the 2-character string "/1".

Note 7d. This character set shall be used with the Zapf_Dingbats font, and shall be used only in PIP/II. Its type is 'complete code' (coded in Binary as 4), and its tail is equivalent to the 2-character string "/:". Its code assignments are defined in Section 10.

Note 8. The METAFILE DEFAULTS REPLACEMENT (MDR) element shall not be partitioned, nor shall any element occurring in the element be partitioned. The CGM standard permits multiple occurrences of this element. The recommended usage of the MDR element is to define one element's default per MDR occurrence.

Note 9. It is commonly overlooked by implementors that the default CHARACTER CODING ANNOUNCER is 'basic 7-bit'. This requires that "8-bit characters", for example the characters of ISO 8859/1, RHS, which represent the special characters from several European languages, be accessed using a 7-bit code, by proper use of the ISO 2022 switching mechanisms (SI and SO) within the string, and proper definition of CHARACTER SET INDEX and ALTERNATE CHARACTER SET INDEX. Alternately, the value of CHARACTER CODING ANNOUNCER can be set to 'basic 8-bit', and then with proper definition of CHARACTER SET INDEX and ALTERNATE CHARACTER SET INDEX, these "8-bit characters" can be accessed with an 8-bit code.

Note 10. These elements were considered by the builders of PIP/II to be within the scope of PIP/II. It is anticipated that these elements will be included in a future release of PIP/II, if there is such.

Note 11. The symbol library was considered by the builders of PIP to be within the scope of PIP. In particular, it would provide for inclusion of oilfield symbols in an efficient manner. It is anticipated that this element will be included in a future release of PIP/II or a future level of PIP (III), if there is such, when usable application symbol libraries have been defined and publicly registered with an appropriate industry body. Until this is done the segment capabilities of PIP/II (see section 4.3.8), in particular Global Segments, may be used to efficiently encode oilfield symbols.

4.3.4 Picture Descriptor elements

Picture descriptor element constraints shall be as specified in Table 3.

Note 1. In Version 1 metafiles, which are the only metafiles allowed in PIP/I, these elements are only allowed to occur in the picture descriptor (and in the METAFILE DEFAULTS REPLACEMENT element). Therefore it is not possible, in a legal Version 1 metafile, to change the colour mode or any of the specification modes within the picture. It is possible and allowable for the colour content of the seismic trace GDP extensions (see Section 9) to be in a different mode than the single colour mode of the picture. In Version 2 and Version 3 metafiles (PIP/II), these may be changed within the picture body.

Note 2. The CGM standard rules for this element have been commonly misinterpreted. The scale-factor parameter of SCALING MODE is always a floating point number, even when REAL PRECISION has selected fixed point for other real numbers. If there has been a REAL PRECISION declaration of (floating, n, m) preceding, then the precision is [n,m]. Otherwise it is [9,23]. See CGM:1992, Part 3, p.29.

Note 3. Colour constraints in the General Specifications (section 4.2) and elsewhere in this specification apply.

Note 4. In Version 1 and Version 2 metafiles these elements each have two legal parameter values in the CGM standard. In Version 3 metafiles these elements each have four legal parameter values in the CGM standard.

Note 5. For each bundle table, the maximum number of defined bundle table entries shall be 20. For each bundle table, either all referenced bundle indices (including implicit reference to the default bundle index by the occurrence of a primitive which uses bundled attributes) shall have their representations defined, or none shall.

Note 6. The maximum number of defined line/edge types shall be 32. The maximum number of entries in the dash-gap list for each type shall be 16.

Note 7. The maximum number of defined hatch types shall be 32. The maximum number of entries in the gap width list for each type shall be 8.

Note 8. The maximum number of defined geometric patterns shall be 1024. Note that there may also be 64 defined "bitmap" patterns in PIP/I metafiles and 1024 in PIP/II metafiles - see Table 6, Note 9.

4.3.5 Control elements

Control element constraints shall be as specified in Table 4. See also the ESCAPE definitions in section 4.3.9.2 and section 4.3.9.3, which behaves as a Control elements.

Note 1. Colour constraints in the General Specifications (see section 4.2) and elsewhere in this specification apply.

Note 2. The defined rectangle shall have non-zero area in the metafile. A rectangle is defined by two opposite corner points. A rectangle's definition is zero-area if the x-coordinates of the points are equal, and/or the y-coordinates are equal.

Note 3. There shall be at most 1024 saved contexts at any point in the metafile. Note that saved contexts are local to the picture in which they are saved, and become undefined at the end of that picture.

4.3.6 Graphical primitives

To ensure portability and predictability of results, conforming PIP metafiles shall not contain any Generalized Drawing Primitive (GDP) elements, except as defined in Section 9.

The constraints in Table 5 shall apply to the parameter lists of graphical primitive elements. In the table "npts" refers to the number of points in a point list.

Table 5. Graphical primitive constraints

Element	Constraints	Notes
Version 1 Elements	PIP/I and PIP/II
POLYLINE	npts = 2..32767
POLYMARKER	npts = 1..32767
DISJOINT POLYLINE	npts = 2,4,6..32766
POLYGON	npts = 3..32767
POLYGON SET	npts = 3..32767	1
TEXT	see note	2, 6
APPEND TEXT	see note	2, 6
RESTRICTED TEXT	see note	2, 5, 6
CELL ARRAY	1 nx*ny 2M (1 nx, ny 2M)	3, 4
GDP	see note	7
RECTANGLE, CIRCLE, ELLIPSE	none
Circular & Elliptical Arc Elements	none
Version 2 Elements	only PIP/II
CONNECTING EDGE	none
CIRCULAR ARC CENTRE REVERSED	none
Version 3 Elements	only PIP/II
HYPERBOLIC ARC	none
PARABOLIC ARC	none
NON UNIFORM B-SPLINE	see note	8
NON UNIFORM RATIONAL B-SPLINE	see note	8
POLYBEZIER	see note	9
BITONAL TILE	see note	10
TILE	see note	10
SYMBOL	element not allowed	11

Note 1. In addition, any sub-polygon shall be well defined and shall have at least 3 points.

Note 2. Constraints on the length and content of graphical text strings (see section 4.2.3) shall apply.

Note 3. The rules for colour, defined elsewhere in this specification (see section 4.2) shall apply to the cell colour specifiers.

Note 4. The points P, Q, R shall define an axis-aligned rectangle of non-zero area. The notation "M" refers to the quantity 1024*1024, or 1,048,576.

Note 5. The RESTRICTED TEXT element in conforming PIP metafiles of (CGM:1992) Versions 1 and 2 shall have the meaning equivalent to the 'boxed-cap' style of the RESTRICTED TEXT TYPE element of Version 3 metafiles. See section 5.1.2 for recommendations and requirements concerning this element.

Note 6. The values 'not final' and 'final' are permitted for the flag parameter.

Note 7. There shall be no GDPs in conforming PIP metafiles except for those defined in Section 9, and those shall appear only in metafiles identified by "Extension: extended/seismic".

Note 8. The order shall be at most 3 (cubic). The maximum number of control points shall be 4096.

Note 9. The maximum number of control points shall be 4096.

Note 10. All compression types are allowed. At the time of publication of this document, the JPEG technique is being registered for CGM usage in Tile Array. It is anticipated that JPEG will be added to this profile as a legal PIP option in a future version or release of PIP, if there is such.

Note 11. See Table 2, Note 11.

4.3.7 Attribute elements

Attribute element constraints shall be as specified in Table 6. See also the ESCAPE definition in section 4.3.9.1, which behaves as an Attribute element, affecting text primitives.

The individual primitive colour attributes are omitted from the table, but follow the general limitations and rules on colour defined elsewhere in this specification (see section 4.2).

Note 1. The character set selected shall be representable in the font selected (see discussion of resolution of conflicts with this requirement in section 5.2).

Note 2. Additionally, every referenced font index, including the default font index, shall correspond to a defined entry in the FONT LIST.

Note 3. Additionally, every referenced character set index shall correspond to a defined entry in the CHARACTER SET LIST.

Note 4. For colour metafiles, start index 0-4095; for grayscale metafiles, start index 0-63; for monochrome metafiles start index 0 or 1.

Note 5. The pattern size vectors shall be orthogonal and axis-aligned.

Note 6. All ASFs (ASPECT SOURCE FLAGS) for a given primitive type shall have the same value, 'individual' or 'bundled'.

Note 7. The "all or none" rule (see section 4.2) of colour index definition shall be observed. The "all or none" rule (see section 4.2) of direct colour usage shall be observed.

Colour indexes are defined by the COLOUR TABLE element. Background colour is defined either by the BACKGROUND COLOUR element or by the definition of colour index 0. The CGM standard defines BACKGROUND COLOUR to be synonymous with colour index 0. Because this is often implemented incorrectly, it is recommended that generators do not use COLOUR TABLE index 0 to define the background colour, and do not draw foreground objects using colour index 0.

Recommendation to implementors: The "all or none" requirement can be used to advantage for bi-level plots which might either go to a black-on-white plotter, or to a white-on-black (or any two other colours) preview device. The generator should define no colours, which will leave the interpreter free to choose the appropriate foreground and background colours.

Note 8. If a COLOUR TABLE element defining the representation of a given colour index appears in a picture, it shall appear before reference to that index by an attribute element or use of that index by a graphical primitive element (included in the latter shall be implicit use of default colour index attribute values by the first occurrence of an associated primitive). In other words, all colour indexes shall be defined before they are used, if they are defined at all.

Once a given colour representation is defined and used, it shall not be redefined.

CGM:1992 makes it clear that in fact the COLOUR TABLE element has no retroactive effect when it appears in a picture subsequent to any graphical primitives which were rendered using the defined (or redefined) index. Nevertheless such practice has strong possibility of being misinterpreted and is therefore prohibited in PIP metafiles.

Note 9. A PATTERN TABLE element defining the representation of a given pattern index shall appear: a) before explicit reference to that index by any PATTERN INDEX element; or b) (in the case of the default PATTERN INDEX) before any implicit reference caused by the first occurrence of an associated filled primitive. In other words, all pattern indexes shall be defined before they are used. (Unlike colour, the "all-defaulted" case with pattern indexes provides no useful effect - undefined indexes all default to 1, and the default value of 1 is a 1x1 pattern [solid] in the default foreground colour).

CGM:1992 defines that the PATTERN TABLE element has no retroactive effect when it appears in a picture subsequent to any graphical primitives filled with the affected pattern index. Unlike colour, there is not common instantiation of two different modes of dynamic pattern update capability in hardware, and therefore there is little likelihood of incorrect implementations if pattern redefinition is allowed. Therefore, PIP allows pattern indexes to be "reused" - a pattern index may be redefined after it has already been defined and used.

There shall be at most 64 of these patterns defined in PIP/I, and 1024 of these patterns defined in PIP/II. In PIP/I there are only these "bitmap" patterns. In PIP/II metafiles of CGM:1992 Version 3 there may be 1024 geometric patterns as well.

Note 10. Negative index values are allowed in Version 3 PIP metafiles, and if used shall correspond to a type define with the LINE AND EDGE TYPE DEFINITION element.

Note 11. Negative index values are allowed in Version 3 PIP metafiles, and if used shall correspond to a type define with the HATCH STYLE DEFINITION element.

Note 12. This element has no graphical effect and may be useful for preserving non-graphical application information. Therefore it is harmless when occurring in a metafile and may safely be ignored by interpreters.

Note 13. The notation means "0.0 to 1.0, inclusive".

Note 14. The meaning of the value 1 shall correspond to the single required treatment of RESTRICTED TEXT in PIP/I metafile. See Table 5, Note 5.

Note 15. See Table 2, Note 11.

Note 16. In PIP/II, this allows access to 1024 "bitmap" patterns in metafiles of CGM:1992 Versions 1, 2, 3, plus 1024 geometric patterns in CGM:1992 Version 3 metafiles - conceptually, the bitmap and geometric patterns are stored in different tables.

4.3.8 Segment elements

Segment element constraints shall be as specified in Table 7.

Note 1. Segment references may be nested, by a COPY SEGMENT referring to a segment, which contains a COPY SEGMENT referring to another segment. A COPY SEGMENT element shall not be recursive, i.e., it shall not refer to a segment in which it might be contained, either directly or by following a chain of COPY SEGMENT elements which eventually lead back to the segment in which it is contained.

Note 2. This element has no graphical effect and may be useful for preserving application information. Therefore it is harmless when occurring in a metafile and may safely be ignored by interpreters.

4.3.9 ESCAPE elements

To ensure portability and predictability of results, conforming PIP metafiles shall not contain any ESCAPE elements, except as defined in this section and in Section 9. The ESCAPE elements defined in this section are basic capabilities of PIP metafiles.

The data records (D) of the following ESCAPES are defined consistently with the SDR data format, defined in CGM:1992 annex C. See section 9.3.2 for an explanation of the notation used in the following subsections.

The Select Typeface Weight and Transparent Cell Colour escapes are registered escapes - they have been reviewed according to ISO procedures and have been entered into the ISO Register of Graphical Items (see Section 2). They have been assigned positive identifiers by the Registration Authority. Registered escapes are the only ones that may be referenced by positive identifiers.

Section 4.3.9.1 and section 4.3.9.2 summarize and paraphrase the respective two items in the ISO Register of Graphical Items. In the case of a conflict between these sections and the register, the register shall have precedence - implementors should obtain and work from the register.

4.3.9.1 Set Typeface Weight

4.3.9.2 Transparent Cell Colour

4.3.9.3 Colour Blending

4.3.10 External elements

The action required flag of the MESSAGE element shall not be used in such a way that the picture definition is altered.

There are no restrictions on the use of APPLICATION DATA elements in PIP metafiles, except that they shall have no effect on the picture(s) defined by the metafile.

The Data Record parameters of APPLICATION DATA elements in conforming PIP metafiles shall be formatted according to the SDR technique.

The following specific APPLICATION DATA element is defined for use in PIP metafiles.

4.3.10.1 Named Reference Point

4.3.11 Defaults

The default values for elements of class Metafile Descriptor, Picture Descriptor, Control, and Attribute are defined in clause 6 of ISO/IEC 8632-1:1992 (CGM part 1 - Functional Specification) and clause 8 of ISO/IEC 8632-3:1992 (CGM part 3 - Binary Encoding).

4.3.11.1 Default values of settable parameters

Wherever values are given to default element values in clause 6 of part 1, and clause 8 of part 3 of CGM:1992, those default values shall apply to conforming PIP metafiles, unless superseded by this specification (the latter only in the cases of "implementation-dependent").

The rules of this profile for PIP conforming metafiles effectively prohibit the defaulting of FONT LIST.

The rules of CGM:1992 define (see annex D) that there is no useful default PATTERN TABLE - any undefined pattern index maps to pattern index 1, whose value is effectively a solid interior fill.

The rules of this profile require that either: all colours be defined before use; or all colours be defaulted. It is not allowed in conforming PIP metafiles that some colours be defined and some be defaulted. This profile does not define a specific default colour table or default primitive colours for the case that all colours are defaulted. In this case the result is entirely interpreter dependent.

4.3.11.2 Bundle table default values

To ensure predictable results, the following default definitions shall apply to the bundle indices for conforming PIP metafiles. Since bundle table representations may not be defined in Version 1 metafiles, these are effectively the fixed bundle index values for conforming Version 1 metafiles.

4.3.12 Specification of semantic ambiguities

4.3.12.1 Drawing priority and mode

The CGM standard is not explicit on the graphical effect of overlapping primitives. Primitives occurring later in the file shall overlay primitives occurring earlier in the file, and the drawing mode shall be "replacement" mode, unless specifically altered by a defined ESCAPE of this profile.

4.3.12.2 View surface clearing

The logical view surface is "clear" at the occurrence of the BEGIN PICTURE BODY element - each picture is logically defined on a clean VDC extent in the background colour.

This specification does not constrain interpreters from accepting instructions external to the metafile, which may direct the interpreter to overlay, montage, or compose multiple pictures onto a view surface.

4.3.12.3 Clipping

When the CLIP INDICATOR is 'off', clipping shall be done to the intersection of the device viewport and the device view surface limits. When clipping is 'on', clipping shall be done to the intersection of the clip rectangle, the VDC EXTENT, the device viewport and the device view surface limits (see also Table 4, Note 2).

4.3.12.4 Edge centring

Drawn edges of filled-area elements shall be centred on the ideal mathematically defined edge of the area.

4.3.13 Font specifications

Except for PIP/MonoSansSerif, the fonts in Table 9 are public domain fonts, available as part of NBS SP 424. All of these fonts are basic capabilities of conforming PIP metafiles. Any of these fonts may appear in the FONT LIST element in a conforming PIP metafile. The font name parameter used in the FONT LIST element to designate these fonts shall be the concatenation of the string "Hershey/", to designate one of the Hershey fonts, and a "name string" to designate the particular typeface. The string "Hershey:" shall be an acceptable substitute for "Hershey/", however its use is deprecated.

The fonts named in Table 10 are also basic capabilities of conforming PIP metafiles. The table also indicates the level of PIP in which the fonts may be used: the fonts of the first column are allowed in any PIP metafile; the fonts of the second column are only allowed in PIP/II.

Some of the font names in Table 10 are trademarked. Some of the named fonts are proprietary and copyrighted. This PIP profile in no way requires that implementors of this specification license the named fonts from their trademark or copyright owners. Metric equivalents of the named fonts are widely available. Substitution by generators and interpreters of fonts which are "metrically equivalent", as explained in section 5.2, shall constitute compliance with this specification.

For the fonts in both Table 9 and Table 10, the SPACE and UNDERSCORE characters are considered to be null characters in font names, i.e., they can be deleted and the name will be equivalent.

Note 1. Times and Helvetica are registered trademarks of Allied Corporation, the owner of the copyright on the fonts of those names.

Note 2. The "Symbol" font contains Greek characters in the familiar alphabetic positions, and various mathematical and publishing symbols in the upper code positions (159-255).

Note 3. The Avant_Garde, Bookman, New_Century_Schlbk, and Zapf font names are copyrighted by International Typeface Corporation. Palatino is copyrighted by Linotype AG.

Note 4. For the purposes of PIP, the entire collection in table 10 is referred to as the A35 font set. The fonts of the first column is referred to as the A13 font set, and those of the second column as the A35D font set (for "A35 delta" - fonts in A35 which are not in A13).

Note 5. In commercial practice, "Oblique" is more commonly used than "Italic" for these two font names. However PIP/I adopted the "Italic" usage (as did the CALS profile). Therefore "Oblique" usage is not allowed in PIP metafiles, and "Italic" shall be used for these two names.

The case (upper/lower) of the font names of the above font tables (Table 9 and Table 10) in FONT LIST elements shall not be significant to conforming basic generators and conforming PIP interpreters.

Conforming PIP metafiles shall not reference any font not listed in Table 9 or Table 10. See section 5.2, Interpreter implementation requirements specifications (IIRS) regarding acceptable approximations for the basic set of fonts.