ISO/IEC JTC 1/SC34 N0xxx
ISO/IEC JTC 1/SC34/WG2 N405
ISO/IEC JTC 1/SC34/WG2
Information Technology --
Document Description and Processing
Languages
-- Information Presentation
| TITLE: | Liaison Comment to JTC1/SC29/WG11 |
| SOURCE: | Toshiya Suzuki/Hiroshima University |
| PROJECT: | |
| PROJECT EDITOR: | |
| STATUS: | Informal Liaison |
| ACTION: | For information |
| DATE: | 2011-03-30 |
| DISTRIBUTION: | SC34, SC34/WG2 and Liaisons |
| REFER TO: | |
| REPLY TO: |
Liaison Comment to SC29/WG11 about Panose value in ISO/IEC 14496-22
Background
Importance of the abstract typeface information
In various editable or final form data like ISO/IEC 29500 (OOXML),
PDF, PCL, or the supplementary data like CSS,
the referential informations of the font are written and
important to recover the fonts when the font itself is not
embedded in the document.
In most case, the name of the font face is used as the unique
identifier, but sometimes the document rendering system does
not have the font with the same name. In such case, the abstract
specification of the typeface, with the informations of typographic
characteristics of the font is important to substitute the missing
font by the appropriate font that the rendering system can use.
Discussion in SC34
In OOXML, following properties are written in the documents.
- Data indirectly generated from the fonts
-
- Pitch property used in Microsoft Windows GDI
- Family property used in Microsoft Windows GDI
- charset property used in Microsoft Windows GDI
- Data directly generated from the fonts
-
- supported Unicode range
- Panose
The data indirectly generated from the fonts are
controlled by the document producer, the request of
the validation is easy. The document including invalid pitch,
family and charset are recognized as invalid OOXML document.
The supported Unicode range is a collection of the boolean
values for each range of the scripts in Unicode, so there is
no invalid data.
The last one, Panose-1 is usually described as 10 hexadigits
or 10 digits. In the case of TrueType and OpenType, it is
stored as 10 octets. In comparison with the space of
possible values of 10 octets
(00 00 00 00 00 00 00 00 00 00 - FF FF FF FF FF FF FF FF FF FF),
the defined valid range of Panose is quite smaller.
Thuhere was a long discussion in SC34/WG4 how to validate
the Panose values and what kind of invalid values are popular.
During the discussion, it is found that there are some documents
including insufficient or misleading information about the
Panose definition and it is supposed that many font developers
have not checked genuine Panose spec.
The genuine Panose spec have per-family-kind properties
(e.g. Latin Symbol family kind does not have a property for serif style),
but some insufficient or misleading documents describe
all properties are independently defined and the properties
for Latin Text are generic (thus they described as Latin
Symbol family kind have a property for serif style).
It seems that the earliest one would be MSDN document,
and the insufficient description was duplicated to the earlier
OpenType spec.
The latest OpenType and ISO/IEC 14496-22 spec are improved,
it does not have the text about the valid value range of each
properties.
But the name of properties are still included. They are same
with the properties of Latin Text, and misleading the developers
to the conventional misunderstanding that the propertis are
independent with the family kind.
SC34/WG2 proposes to drop the list of the property names from
next version of ISO/IEC 14496-22 and just refer genuine Panose
spec.
Expected impact of proposed change
Recently, Microsoft participants to SC34/WG4 stated that
the existing implementation in Microsoft products follow
to genuine Panose spec, but MSDN document insufficiently
described. Therefore, it is expected that there is no
change in Microsoft products.
Other comments
Although SC34/WG2 proposed to reduce the description about
Panose in future version of ISO/IEC 14496-22, SC34/WG2 strongly
propose to keep the text
"International: Additional specifications are required for PANOSE
to classify non-Latin character sets."
Importance of the abstract typeface information
In various editable or final form data like ISO/IEC 29500 (OOXML), PDF, PCL, or the supplementary data like CSS, the referential informations of the font are written and important to recover the fonts when the font itself is not embedded in the document. In most case, the name of the font face is used as the unique identifier, but sometimes the document rendering system does not have the font with the same name. In such case, the abstract specification of the typeface, with the informations of typographic characteristics of the font is important to substitute the missing font by the appropriate font that the rendering system can use.Discussion in SC34
In OOXML, following properties are written in the documents.- Data indirectly generated from the fonts
-
- Pitch property used in Microsoft Windows GDI
- Family property used in Microsoft Windows GDI
- charset property used in Microsoft Windows GDI
- Data directly generated from the fonts
-
- supported Unicode range
- Panose
Expected impact of proposed change
Recently, Microsoft participants to SC34/WG4 stated that the existing implementation in Microsoft products follow to genuine Panose spec, but MSDN document insufficiently described. Therefore, it is expected that there is no change in Microsoft products.Other comments
Although SC34/WG2 proposed to reduce the description about Panose in future version of ISO/IEC 14496-22, SC34/WG2 strongly propose to keep the text "International: Additional specifications are required for PANOSE to classify non-Latin character sets."END