ISO/IEC 14496-22:2019/Amd 1:2020
(Amendment)Information technology — Coding of audio-visual objects — Part 22: Open Font Format — Amendment 1: Color font technology and other updates
Information technology — Coding of audio-visual objects — Part 22: Open Font Format — Amendment 1: Color font technology and other updates
Technologies de l'information — Codage des objets audiovisuels — Partie 22: Format de police de caractères ouvert — Amendement 1: Technologie des polices colorées et autres mises à jour
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 14496-22
Fourth edition
2019-01
AMENDMENT 1
2020-06
Information technology — Coding of
audio-visual objects —
Part 22:
Open Font Format
AMENDMENT 1: Color font technology
and other updates
Technologies de l'information — Codage des objets audiovisuels —
Partie 22: Format de police de caractères ouvert
AMENDEMENT 1: Technologie des polices colorées et autres mises à
jour
Reference number
ISO/IEC 14496-22:2019/Amd.1:2020(E)
©
ISO/IEC 2020
ISO/IEC 14496-22:2019/Amd.1:2020(E)
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
ISO/IEC 14496-22:2019/Amd.1:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence
to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT)
see www .iso .org/ iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO/IEC 14496 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO/IEC 2020 – All rights reserved iii
ISO/IEC 14496-22:2019/Amd.1:2020(E)
Information technology — Coding of audio-visual
objects —
Part 22:
Open Font Format
AMENDMENT 1: Color font technology and other updates
4.5.2
Replace the description of the “Offset” field in the “Table Directory” table with the following:
Offset from beginning of OFF font file.
5.3.4.1.1
Replace the first sentence of the first paragraph with the following:
This is the table information needed if numberOfContours is greater than or equal to zero, that is, a
glyph is not a composite.
Replace the final paragraph (immediately following the “Simple Glyph flags” table) with the following:
A non-zero-fill algorithm is needed to avoid dropouts when contours overlap. The OVERLAP_SIMPLE
flag is used by some rasterizer implementations to ensure that a non-zero-fill algorithm is used rather
than an even-odd-fill algorithm. Implementations that always use a non-zero-fill algorithm will ignore
this flag. Note that some implementations might check this flag specifically in non-variable fonts, but
always use a non-zero-fill algorithm for variable fonts. This flag can be used in order to provide broad
interoperability of fonts — particularly non-variable fonts — when glyphs have overlapping contours.
Note that variable fonts often make use of overlapping contours. This has implications for tools that
generate static-font data for a specific instance of a variable font, if broad interoperability of the derived
font is desired: if a glyph has overlapping contours in the given instance, then the tool should either
set this flag in the derived glyph data, or else should merge contours to remove overlap of separate
contours.
5.4.3.10
In the descriptions of both “FDSelect Format3” and “Range3 Record Format”, add the following NOTE
after the last paragraph:
NOTE Since a sentinel GID is used to delimit the last range in the array, its value, encoded as a uint16, cannot
exceed the value 65535. Therefore, the last GID encoded when using FDSelect Format3 cannot exceed 65534.
In the description of “FDSelect Format4”, in the first paragraph, replace the reference to 65536 [glyphs]
with 65535.
© ISO/IEC 2020 – All rights reserved 1
ISO/IEC 14496-22:2019/Amd.1:2020(E)
In the description of “Range4 Record Format” replace all references to 65536 [glyphs] with 65535.
5.4.3.11
In the 'blend' row of the table – replace "number of blends" with the "numberOfBlends".
5.5.1
Replace the entire content of subclause 5.5.1 with the following:
This table contains SVG descriptions for some or all of the glyphs in the font.
OFF provides various formats for color fonts, one of which is the SVG table. The SVG table provides the
benefits of supporting scalable color graphics using the Scalable Vector Graphics markup language, a
vector graphics file format that is widely used on the Web and that provides rich graphics capabilities,
such as gradients.
SVG was developed for use in environments that allow for a rich set of functionality, including leveraging
the full functionality of Cascading Style Sheets for styling, and programmatic manipulation of graphics
objects using the SVG Document Object Model. Adoption of SVG for use in OpenType does not entail
wholesale incorporation of all SVG capabilities. Text-rendering engines typically have more stringent
security, performance and architectural requirements than general-purpose SVG engines. For this
reason, when used within OFF fonts, the expressiveness of the language is limited and simplified to be
appropriate for environments in which font processing and text layout occurs.
The SVG table is optional, and may be used in OFF fonts with TrueType, CFF or CFF2 outlines. For every
SVG glyph description, there must be a corresponding TrueType, CFF or CFF2 glyph description in the font.
SVG Table Header
Type Name Description
uint16 version Table version (starting at 0). Set to 0.
Offset32 offsetToSVGDocumentList Offset the SVG Documents List, from the start of the SVG table.
Must be non-zero.
uint32 reserved Set to 0.
SVG Document List
The SVG document list provides a set of SVG documents, each of which defines one or more glyph
descriptions.
Type Name Description
uint16 numEntries Number of SVG Document Index Entries.
Must be non-zero.
SVGDocumentRecord documentRecords[numEntries] Array of SVG document records.
2 © ISO/IEC 2020 – All rights reserved
ISO/IEC 14496-22:2019/Amd.1:2020(E)
SVGDocumentRecord
Each SVG document record specifies a range of glyph IDs (from startGlyphID to endGlyphID, inclusive),
and the location of its associated SVG document in the SVG table.
Type Name Description
uint16 startGlyphID The first glyph ID for the range covered by this record.
uint16 endGlyphID The last glyph ID for the range covered by this record.
Offset32 svgDocOffset Offset from the beginning of the SVGDocumentList to an SVG document.
Must be non-zero.
uint32 svgDocLength Length of the SVG document data. Must be non-zero.
Records must be sorted in order of increasing startGlyphID. For any given record, the startGlyphID must
be less than or equal to the endGlyphID of that record, and also must be greater than the endGlyphID of
any previous record.
NOTE Two or more records can point to the same SVG document. In this way, a single SVG document can
provide glyph descriptions for discontinuous glyph ID ranges. See Example 1 in subclause 5.5.6
5.5.2
Insert a new subclause 5.5.2 and renumber the remaining subclauses within subclause 5.5:
5.5.2 SVG Documents
SVG specification
The SVG markup language used in the SVG table shall be as defined in the Scalable Vector Graphics
(SVG) 1.1 (2nd edition), W3C Recommendation. Any additional SVG features are not supported, unless
explicitly indicated otherwise.
Previous editions of this document allowed use of context-fill and other context-* property values,
which are defined in the draft SVG 2 specification. Use of these properties is deprecated: conforming
implementations may support these properties, but support is not required or recommended, and use
of these properties in fonts is strongly discouraged.
Document encoding and format
SVG documents within an OFF SVG table may either be plain text or gzip-encoded, and applications that
support the SVG table shall support both.
The gzip format is defined in RFC 1952 (Reference [31]). Within a gzip-encoded SVG document, the
deflate compression method (defined by RFC 1951) must be used. Thus, the first three bytes of the gzip-
encoded document header must be 0x1F, 0x8B, 0x08.
Whether compressed or plain-text transfer encoding is used, the SVGDocLength field of the SVG
document record specifies the length of the encoded data, not the decoded document.
The encoding of the (uncompressed) SVG document must be UTF-8.
While SVG 1.1 is defined as an XML application, some SVG implementations for the Web use an
“HTML dialect”. The “HTML dialect” differs from the XML-based definition in various ways, including
being case-insensitive (XML is case-sensitive), and not requiring an xmlns attribute on the SVG root
element. Applications that support the OFF SVG table shall support the XML-based definition for SVG
1.1. Applications may use SVG-parsing libraries that also support the “HTML dialect”. However, SVG
documents within the OFF fonts must always conform to the XML-based definition.
© ISO/IEC 2020 – All rights reserved 3
ISO/IEC 14496-22:2019/Amd.1:2020(E)
While SVG 1.1 requires conforming interpreters to support XML namespace constructs, applications
that support the OpenType SVG table are not required to have full support for XML namespaces. The
root element of each SVG document must declare SVG as the default namespace:
If the XLink href attribute is used, the root must also declare “xlink” as a namespace in the root element:
xmlns:xlink=”http://www.w3.org/1999/xlink”>
No other XLink attributes or other mechanisms may be used anywhere in the document. Also, no other
namespace declarations should be made in any element.
SVG capability requirements and restrictions
Most SVG 1.1 capabilities are supported in OFF and should be supported in all OFF applications that
support the SVG table. Some SVG 1.1 capabilities are not required and may be optionally supported
in applications. Certain other capabilities are not supported in OFF and must not be used in SVG
documents within OFF fonts.
The following capabilities are restricted from use in OFF and must not be used in conforming fonts. If
use of associated elements is encountered within a font, conforming applications must ignore and not
render those elements.
— , , and associated elements
— elements
— elements
—
INTERNATIONAL ISO/IEC
STANDARD 14496-22
Fourth edition
2019-01
AMENDMENT 1
2020-06
Information technology — Coding of
audio-visual objects —
Part 22:
Open Font Format
AMENDMENT 1: Color font technology
and other updates
Technologies de l'information — Codage des objets audiovisuels —
Partie 22: Format de police de caractères ouvert
AMENDEMENT 1: Technologie des polices colorées et autres mises à
jour
Reference number
ISO/IEC 14496-22:2019/Amd.1:2020(E)
©
ISO/IEC 2020
ISO/IEC 14496-22:2019/Amd.1:2020(E)
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
ISO/IEC 14496-22:2019/Amd.1:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence
to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT)
see www .iso .org/ iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
A list of all parts in the ISO/IEC 14496 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO/IEC 2020 – All rights reserved iii
ISO/IEC 14496-22:2019/Amd.1:2020(E)
Information technology — Coding of audio-visual
objects —
Part 22:
Open Font Format
AMENDMENT 1: Color font technology and other updates
4.5.2
Replace the description of the “Offset” field in the “Table Directory” table with the following:
Offset from beginning of OFF font file.
5.3.4.1.1
Replace the first sentence of the first paragraph with the following:
This is the table information needed if numberOfContours is greater than or equal to zero, that is, a
glyph is not a composite.
Replace the final paragraph (immediately following the “Simple Glyph flags” table) with the following:
A non-zero-fill algorithm is needed to avoid dropouts when contours overlap. The OVERLAP_SIMPLE
flag is used by some rasterizer implementations to ensure that a non-zero-fill algorithm is used rather
than an even-odd-fill algorithm. Implementations that always use a non-zero-fill algorithm will ignore
this flag. Note that some implementations might check this flag specifically in non-variable fonts, but
always use a non-zero-fill algorithm for variable fonts. This flag can be used in order to provide broad
interoperability of fonts — particularly non-variable fonts — when glyphs have overlapping contours.
Note that variable fonts often make use of overlapping contours. This has implications for tools that
generate static-font data for a specific instance of a variable font, if broad interoperability of the derived
font is desired: if a glyph has overlapping contours in the given instance, then the tool should either
set this flag in the derived glyph data, or else should merge contours to remove overlap of separate
contours.
5.4.3.10
In the descriptions of both “FDSelect Format3” and “Range3 Record Format”, add the following NOTE
after the last paragraph:
NOTE Since a sentinel GID is used to delimit the last range in the array, its value, encoded as a uint16, cannot
exceed the value 65535. Therefore, the last GID encoded when using FDSelect Format3 cannot exceed 65534.
In the description of “FDSelect Format4”, in the first paragraph, replace the reference to 65536 [glyphs]
with 65535.
© ISO/IEC 2020 – All rights reserved 1
ISO/IEC 14496-22:2019/Amd.1:2020(E)
In the description of “Range4 Record Format” replace all references to 65536 [glyphs] with 65535.
5.4.3.11
In the 'blend' row of the table – replace "number of blends" with the "numberOfBlends".
5.5.1
Replace the entire content of subclause 5.5.1 with the following:
This table contains SVG descriptions for some or all of the glyphs in the font.
OFF provides various formats for color fonts, one of which is the SVG table. The SVG table provides the
benefits of supporting scalable color graphics using the Scalable Vector Graphics markup language, a
vector graphics file format that is widely used on the Web and that provides rich graphics capabilities,
such as gradients.
SVG was developed for use in environments that allow for a rich set of functionality, including leveraging
the full functionality of Cascading Style Sheets for styling, and programmatic manipulation of graphics
objects using the SVG Document Object Model. Adoption of SVG for use in OpenType does not entail
wholesale incorporation of all SVG capabilities. Text-rendering engines typically have more stringent
security, performance and architectural requirements than general-purpose SVG engines. For this
reason, when used within OFF fonts, the expressiveness of the language is limited and simplified to be
appropriate for environments in which font processing and text layout occurs.
The SVG table is optional, and may be used in OFF fonts with TrueType, CFF or CFF2 outlines. For every
SVG glyph description, there must be a corresponding TrueType, CFF or CFF2 glyph description in the font.
SVG Table Header
Type Name Description
uint16 version Table version (starting at 0). Set to 0.
Offset32 offsetToSVGDocumentList Offset the SVG Documents List, from the start of the SVG table.
Must be non-zero.
uint32 reserved Set to 0.
SVG Document List
The SVG document list provides a set of SVG documents, each of which defines one or more glyph
descriptions.
Type Name Description
uint16 numEntries Number of SVG Document Index Entries.
Must be non-zero.
SVGDocumentRecord documentRecords[numEntries] Array of SVG document records.
2 © ISO/IEC 2020 – All rights reserved
ISO/IEC 14496-22:2019/Amd.1:2020(E)
SVGDocumentRecord
Each SVG document record specifies a range of glyph IDs (from startGlyphID to endGlyphID, inclusive),
and the location of its associated SVG document in the SVG table.
Type Name Description
uint16 startGlyphID The first glyph ID for the range covered by this record.
uint16 endGlyphID The last glyph ID for the range covered by this record.
Offset32 svgDocOffset Offset from the beginning of the SVGDocumentList to an SVG document.
Must be non-zero.
uint32 svgDocLength Length of the SVG document data. Must be non-zero.
Records must be sorted in order of increasing startGlyphID. For any given record, the startGlyphID must
be less than or equal to the endGlyphID of that record, and also must be greater than the endGlyphID of
any previous record.
NOTE Two or more records can point to the same SVG document. In this way, a single SVG document can
provide glyph descriptions for discontinuous glyph ID ranges. See Example 1 in subclause 5.5.6
5.5.2
Insert a new subclause 5.5.2 and renumber the remaining subclauses within subclause 5.5:
5.5.2 SVG Documents
SVG specification
The SVG markup language used in the SVG table shall be as defined in the Scalable Vector Graphics
(SVG) 1.1 (2nd edition), W3C Recommendation. Any additional SVG features are not supported, unless
explicitly indicated otherwise.
Previous editions of this document allowed use of context-fill and other context-* property values,
which are defined in the draft SVG 2 specification. Use of these properties is deprecated: conforming
implementations may support these properties, but support is not required or recommended, and use
of these properties in fonts is strongly discouraged.
Document encoding and format
SVG documents within an OFF SVG table may either be plain text or gzip-encoded, and applications that
support the SVG table shall support both.
The gzip format is defined in RFC 1952 (Reference [31]). Within a gzip-encoded SVG document, the
deflate compression method (defined by RFC 1951) must be used. Thus, the first three bytes of the gzip-
encoded document header must be 0x1F, 0x8B, 0x08.
Whether compressed or plain-text transfer encoding is used, the SVGDocLength field of the SVG
document record specifies the length of the encoded data, not the decoded document.
The encoding of the (uncompressed) SVG document must be UTF-8.
While SVG 1.1 is defined as an XML application, some SVG implementations for the Web use an
“HTML dialect”. The “HTML dialect” differs from the XML-based definition in various ways, including
being case-insensitive (XML is case-sensitive), and not requiring an xmlns attribute on the SVG root
element. Applications that support the OFF SVG table shall support the XML-based definition for SVG
1.1. Applications may use SVG-parsing libraries that also support the “HTML dialect”. However, SVG
documents within the OFF fonts must always conform to the XML-based definition.
© ISO/IEC 2020 – All rights reserved 3
ISO/IEC 14496-22:2019/Amd.1:2020(E)
While SVG 1.1 requires conforming interpreters to support XML namespace constructs, applications
that support the OpenType SVG table are not required to have full support for XML namespaces. The
root element of each SVG document must declare SVG as the default namespace:
If the XLink href attribute is used, the root must also declare “xlink” as a namespace in the root element:
xmlns:xlink=”http://www.w3.org/1999/xlink”>
No other XLink attributes or other mechanisms may be used anywhere in the document. Also, no other
namespace declarations should be made in any element.
SVG capability requirements and restrictions
Most SVG 1.1 capabilities are supported in OFF and should be supported in all OFF applications that
support the SVG table. Some SVG 1.1 capabilities are not required and may be optionally supported
in applications. Certain other capabilities are not supported in OFF and must not be used in SVG
documents within OFF fonts.
The following capabilities are restricted from use in OFF and must not be used in conforming fonts. If
use of associated elements is encountered within a font, conforming applications must ignore and not
render those elements.
— , , and associated elements
— elements
— elements
—
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.