| POSC Specifications Version 2.2 | CGM*PIP Volume 1 - PIP/I/3 and PIP/II/3 |
Conforming PIP implementations shall use the character code assignments of Figure 20a and Figure 20b (Section 10) for the "ISO Latin 1" character sets. (the two G-sets, ASCII and ISO 8859-1 RHS, see also section 4.3.3). The code assignments shown are those to be used if the metafile uses the 'basic 8-bit' value for character coding announcer.
If the metafile uses the default 'basic 7-bit' value for character coding announcer, then the two halves of the table in Figure 20a (Section 10) are treated as two character sets (the left half and right half could be treated independently as 94/96 character sets and included in the CHARACTER SET LIST with the designation sequence tails given in Table 2 in section 4.3.3). These are associated with CHARACTER SET INDEX and ALTERNATE CHARACTER SET INDEX, and the characters are then referenced in text strings by a 7-bit codes. Using both sets within a single text string is accomplished by the use of the ISO 2022 controls SI and SO to switch the association of the 7-bit code between the two sets.
The selection of 'basic 8-bit' eliminates the necessity of the SI/SO intra-string controls. The setup of the CHARACTER SET LIST, CHARACTER SET INDEX, and ALTERNATE CHARACTER SET INDEX would be identical.
The fonts listed in Table 9 (section 4.3.13) include the public domain Hershey fonts and a public domain mono-spaced sans serif font that was selected for inclusion in the PIP basic font set.
The Hershey "fonts" were originally released into the public domain with the publication of NBS SP 424. Subsequent to publication, a number of variants of the font set have arisen. Various parties have adjusted both the glyph metrics, to achieve desired changes to the proportional spacing of characters, and the code assignments associated with the glyphs.
For the purposes of unambiguous interchange using the fonts of Table 9 (section 4.3.13), conforming PIP implementations shall use the code assignments in Figure 21 through Figure 37. (Section 10).
The notation used in the figures for the Hershey character codes is "column/row" notation. In the figures, both the columns and the rows of the tables are labelled, in both binary and decimal. The column/row notation, for example, for the "A" glyph in the Hershey/SimplexRoman font (Figure 23 in Section 10) is 4/1.
If the two digits of "column/row" notation are each converted to hexadecimal, the "/" is removed, and the 2-digit number treated as a hexadecimal number, then it corresponds to the character code of the glyph. Example: 4/1 becomes hexadecimal 41, which is decimal 65, which is the character code for "A" in Hershey/SimplexRoman.
The code assignments for use with the fonts of Table 10 (section 4.3.13), except for Symbol and Zapf_Dingbats, shall be as in Figure 20a and Figure 20b (Section 10).
The code associations for the character sets which are to be used with the Symbol font and the Zapf_Dingbat font of Table 10 in section 4.3.13 (see Table 2, Note 7b. and Table 2, Note 7d. in section 4.3.3) shall be as defined in Figure 55 and Figure 77 (Section 10).
Figure 38 (Section 10) shows, in a single figure, the printing of all of the glyphs in all of the fonts of Table 9 (section 4.3.13). It was generated using a Clear Text metafile, so that the requested CGM CHARACTER HEIGHT would result in characters 2mm high when printed ('metric' scaling mode was used to do this). This figure provides a quick "global" benchmark for comparing the required PIP glyph metrics of the Table 9 fonts with the metrics of an implementation of those fonts.
Conforming PIP implementations shall use the Hershey glyph metrics in Figure 39 through Figure 42 (Section 10). The width of each glyph in each font is given at a reference height.
For the two Cartographic Hershey fonts (Figure 39 in Section 10) the reference height is 9 units (in the same address units as given for the width). For the rest of the Hershey fonts the reference height is 21 units. The given widths include white space. In the Hershey data base from which this data is extracted, most character bodies are nearly centred in whitespace. These fonts are all proportionally-spaced fonts.
PIPMonoSansSerif is a mono-spaced font. The character width, white space included, equals the character height. In the data base from which this information is extracted, the character bodies are nearly centred in the white space.
Note: the original design of the Hershey fonts assumed that the line width was 4-5% of the character size. This is an essential feature for preventing "hollowing" of the stems of the characters which are designed with multiple strokes.
The character body reference points which shall be used for these fonts are given in Table 11. The data have been adjusted so that the value 0 corresponds to the baseline. The CGM baseline to capline distance corresponds to the character height. These data can thus be used to calculate the reference points as percentages of character height.
Font
Bottom
Base
Half
Cap
Top
Hershey Cartographics
-3
0
4
9
14
Other Hershey
-7
0
10
21
25
PIPMonoSansSerif
-8
0
13
27
36
For the fonts in Table 10 (section 4.3.13), conforming PIP implementations shall use the glyph metrics given in Figures 43-55 and Figures 56-77 (Section 10).
Informative Note: These figures contain width information for each glyph, and they contain a single CapHeight number for each font. It should be recognized that the CGM standard uses a different text model than is used by some modern font foundries. The width information in the figures is relative to a "design height" of 1000 units for each font. This design height includes (at least) ascenders, descenders, diacritical marks, etc. In general, versions of a given font from different sources will agree in the glyph widths at the design height. However there may be, and often is, some slight variation in the CapHeight number for the same font from different sources. Therefore when typographic systems display text strings at a given point size, using the same font from different sources, the string width should be identical but there may be small differences in the measured CapHeight. The CGM text model differs from these typographic models. In CGM the key text metric is the CHARACTER HEIGHT, which corresponds to the CapHeight. If a font version had slightly different CapHeight than the reference number in the figures, at its design height, and if this number were mapped straight to the CHARACTER HEIGHT, then the string width might vary slightly for the same font from different sources at the same CHARACTER HEIGHT. A future version of PIP may address this issue directly.
Figure 1 is a copy of the formal definition of the SDR data type from annex C of CGM:1992 (including all of the material in section C.2.2, pp. 272-273).
Figure 2 gives the coding requirements for the SDR data in the Binary Encoding - the encoded byte stream is treated as if it were a string, and formatted with the string introducer (count) of the Binary Encoding. The long/short form and string continuation features must be accommodated. (The encodings in Character and Clear Text follow the same principle - the encoded byte stream as a whole is formatted as a string, i.e., as if the encoded data bytes were character codes). Only the relevant material from note 6, p.15, and note 17, p.17, is included in Figure 2 .
Figure 3 and Figure 4 define the data types associated from the abbreviations in figure 21 (this is extracted from the table in clause 5.1 of CGM:1992).
Figure 1. Formal definition of the SDR data type (from annex C of CGM:1992)
Figure 2. Coding requirements for the SDR data in the Binary Encoding (extracted from CGM:1992)
Figure 3. Definition of data types - 1 of 2 (extracted from clause 5.1 of CGM:1992)
Note: For datatype UI32, the range is shown as 0..(231 - 1), as it appears in the CGM:1992 specification. This range is being corrected by ISO as a defect resolution. The 231 should be 232.
Figure 4. Definition of data types - 2 of 2 (extracted from clause 5.1 of CGM:1992)
