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

Status
Published
Publication Date
29-Jun-2020
Current Stage
6060 - International Standard published
Start Date
30-Jun-2020
Completion Date
30-Jun-2020
Ref Project

RELATIONS

Buy Standard

Standard
ISO/IEC 14496-22:2019/Amd 1:2020 - Color font technology and other updates
English language
21 pages
sale 15% off
Preview
sale 15% off
Preview
Draft
ISO/IEC 14496-22:2019/FDAmd 1 - Color font technology and other updates
English language
21 pages
sale 15% off
Preview
sale 15% off
Preview

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
---------------------- Page: 1 ----------------------
ISO/IEC 14496-22:2019/Amd.1:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
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
---------------------- Page: 3 ----------------------
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
---------------------- Page: 4 ----------------------
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
---------------------- Page: 5 ----------------------
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
---------------------- Page: 6 ----------------------
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

FINAL
ISO/IEC
AMENDMENT
DRAFT
14496-22:2019
FDAM 1
ISO/IEC JTC 1/SC 29
Information technology — Coding of
Secretariat: JISC
audio-visual objects —
Voting begins on:
2020-03-31
Part 22:
Voting terminates on:
Open Font Format
2020-05-26
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: .
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC 14496-22:2019/FDAM 1:2020(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS. ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC 14496-22:2019/FDAM 1:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 14496-22:2019/FDAM 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
---------------------- Page: 3 ----------------------
ISO/IEC 14496-22:2019/FDAM 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
---------------------- Page: 4 ----------------------
ISO/IEC 14496-22:2019/FDAM 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
---------------------- Page: 5 ----------------------
ISO/IEC 14496-22:2019/FDAM 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
---------------------- Page: 6 ----------------------
ISO/IEC 14496-22:2019/FDAM 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.