INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
ORGANISATION INTERNATIONALE NORMALISATION
ISO/IEC JTC 1/SC 29/WG 11
CODING OF MOVING PICTURES AND AUDIO
ISO/IEC JTC 1/SC 29/WG 11N5774
July 2003, Trondheim, Norway
Source: / SystemsTitle: /
Text of ISO/IEC 14496-11/FPDAM2: Advanced Text and 2D Graphics
Status: / Approved at 65th meetingNote from the editor: all the references are made according to N5277.
ISO/IECJTC 1/SC29
Date:2003-08-8
ISO/IEC14496-11:200X/FPDAM2
ISO/IECJTC 1/SC29/WG11
Secretariat:
Information technology— Coding of audio-visual objects— Part11: Scene description and application engine, AMENDMENT 2: Advanced text and 2D graphics
Élément introductif— Élément central— Partie11: Titre de la partie
Warning
This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.
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 supporting documentation.
ISO/IEC14496-11:200X/FPDAM2
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's member body in the country of the requester.
ISO copyright office
Case postale 56·CH-1211 Geneva 20
Tel.+ 41 22 749 01 11
Fax+ 41 22 749 09 47
Webwww.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IECDirectives, Part2.
The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75% of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
Amendment2 to ISO/IEC1449611:200X was prepared by Technical Committee ISO/IECJTC 1, Information Technology, Subcommittee SC29, Standardization in the field of information technology.
©ISO/IEC2003— All rights reserved / iiiISO/IEC14496-11:200X/FPDAM2
Information technology— Coding of audio-visual objects— Part11: Scene description and application engine, AMENDMENT 2: Advanced text and 2D graphics
1) Add the following to Clause 2 Normative References
- The Microsoft Typography Web site: The OpenType specification
(http://www.microsoft.com/typography/otspec/default.htm)
- The Adobe Solutions Networks: The OpenType specification
(http://partners.adobe.com/asn/developer/OpenType/main.html)
2) Add the following nodes in alphabetical order in section 9.4.2 (Node specifications)
1.1.1.1 XFontStyle
1.1.1.1.1 Node interface
XFontStyle {
exposedField / MFString / fontName / ["SERIF"]exposedField / SFBool / horizontal / TRUE
exposedField / MFString / justify / ["BEGIN"]
exposedField / SFString / language / ""
exposedField / SFBool / leftToRight / TRUE
exposedField / SFFloat / size / 1.0
exposedField / SFFloat / spacing / 1.0
exposedField / SFString / stretch / “NORMAL“
exposedField / SFFloat / letterSpacing / 0.0
exposedField / SFFloat / wordSpacing / 0.0
exposedField / SFInt32 / weight / 4
exposedField / SFBool / fontKerning / TRUE
exposedField / MFString / style / ["PLAIN"]
exposedField / SFBool / topToBottom / TRUE
exposedField / MFString / featureName / [“”]
exposedField / MFInt32 / featureStartOffset / 0
exposedField / MFInt32 / featureLength / 0
exposedField / MFInt32 / featureValue / 0
}
NOTE - For the binary encoding of this node see Annex AcousticMaterial H.
1.1.1.1.2 Functionality and semantics
The fields of the XFontStyle node are defined as follows.
The horizontal, justify, leftToRight and topToBottom fields have the same meaning as in the FontStyle node.
The fontName field has the same semantic as the family field of the FontStyle node. Special fonts provided in a font data stream can be accessed using the following syntax:
“OD:<odid>;FSID:<fsid>”, where :
- <odid> is the numeric value of the objectDescriptorID of the associated font data stream,
- <fsid> is the numeric value of the requested font subset as conveyed by fontSubsetID within the associated font data stream.
The size field defines the size of the EM box of a font (The EM is a relative measure of the height of the glyphs in a font defined in a device- and resolution-independent font design units). This value corresponds to the distance between two adjacent baselines of unadjusted text, set in a particular font. The value of the size field is conveyed using the same metric units that are used for a scene description. If a scene uses pixel-based metrics, the value of the size field is specified in pixels, otherwise it specifies the size in meters.
The spacing field defines the distance between two adjacent lines of text as the product of size and spacing.
The language field has the same meaning as in the FontStyle node. However, the format of the field is based on the RFC 3066, which supersedes RFC 1766.
The stretch field has an enumerated set of values that specify the font-stretch – desired amount of condensing or expansion of the glyphs in major and minor direction of the alignment “NORMAL | ULTRA-CONDENSED | EXTRA-CONDENSED | CONDENSED | SEMI-CONDENSED | SEMI-EXPANDED | EXPANDED | EXTRA-EXPANDED | ULTRA-EXPANDED”. The value of this field should be consistent with the value “usWidthClass” defined by a font. For description of the set of values please refer to OpenType Specification, version 1.4, chapter “Font File Tables”, section “Required Tables”, OS/2 table.
The weight field represents the boldness of a character. It has a range of values [100..900]. The value of this field should be consistent with the value “usWeightClass” defined by a font. For description of the set of values please refer to OpenType Specification, version 1.4, chapter “Font File Tables”, section “Required Tables”, OS/2 table.
The style field has an extended set of enumerated values specifying text attributes and decoration effects. The permitted values are “PLAIN”, “italic”, “BOLD”, “BOLDitalic”, “UNDERLINE”, “OUTLINE”, “EMBOSS”, “ENGRAVE”, “LEFTDROPSHADOW”, “RIGHTDROPSHADOW”. The font styles should be implemented according to the standard EIA-708-B “Digital Television (DTV) closed captioning”, section 8.5.
The fontKerning field specifies whether font specific kerning data should be applied.
The letterSpacing field specifies, in the font metrics units, the additional space between letters after applying the font kerning.
The wordSpacing field specifies, in the font metrics units, the additional space between words after applying the letterSpacing.
The featureName, featureStartOffset, featureLength and featureValue fields are to be processed as a group. The four fields must have the same length to be valid. These parameters are a set that are to be applied to a run of text. The feature may apply to only one character in the run, or it may apply to the entire run. This is necessary to allow for correct typographic interaction during OpenType operations.
The featureName field specifies a list of four character registered tags that are assigned for a specific feature. Please refer to the registered features listed in the OpenType Specification, version 1.4, Appendix “OpenType Layout Common Table Format”, section “OpenType Layout Registered Features”.
The featureStartOffset field specifies the character offset into the run where the feature will be applied.
The featureLength field specifies the number of characters to which the feature is applied.
The featureValue field specifies the value that is applied for feature processing. A value of 0 is off (false), 1 is on (true). LookupType3 Alternate substitution may have values larger than 1. Please refer to OpenType Specification, version 1.4, chapter “Font File Tables”, section “Advanced Typographic Tables”, GSUB table.
EXAMPLE
Text {
string “The red light is on”
fontStyle XFontStyle {
fontName [“OD:104;FSID:33”]
size 24.0
style “BOLD”
featureSet [“smcp”, “smcp”]
featureStartOffset [4, 17]
featureLength [3, 2]
featureValue [1, 1]
}
}
For the above example, the rendered text string:
The red light is on
1.1.1.2 Viewport
1.1.1.2.1 Node interface
Viewport {
eventIn / SFBool / set_bindexposedField / SFVec2F / position / 0 0
exposedField / SFVec2F / size / -1 -1
exposedField / SFFloat / orientation / 0
exposedField / MFInt32 / alignment / [ 0 0 ]
exposedField / SFInt32 / fit / 0
field / SFString / description / “”
eventOut / SFTime / bindTime
eventOut / SFBool / isBound
}
NOTE - For the binary encoding of this node see Annex AcousticMaterial H.
1.1.1.2.2 Functionality and semantics
A Viewport node can be placed in the viewport field of a Layer2D or CompositeTexture2D node or in the scene tree as a 2D node. It defines a new viewport and implicitly establishes a new local coordinate system. The bounds of the new viewport are defined by the size and position field. The new local coordinate system’s origin is at the center of the parent node in the parent’s local coordinate system.
The orientation field specifies the rotation which is applied to the viewport in the parent node’s local coordinate system with respect to the X-axis.
Viewport nodes are bindable nodes (see 9.2.2.14) and thus there exists a Viewport node stack which follows the same rules than other bindable nodes (e.g. Background2D).
The description field specifies a textual description of the Viewport node.
The alignment and fit fields specify how the viewing area is mapped to the rendering area of the parent node (i.e. Layer2D, CompositeTexture2D, or the 2D top-node).
If the fit field is set to 0, the viewing area is scaled to fit the rendering area without preserving the aspect ratio.
If the fit field is set to 1, the viewing area is scaled preserving the aspect ratio to fit entirely inside the rendering area. The scaling operation is performed possibly after rotation as specified by the orientation field.
If the fit field is set the 2, the viewing area is scaled preserving the aspect ratio to cover entirely the rendering area. The scaling operation is performed possibly after rotation as specified by the orientation field.
The alignement field is an MFInt32 field that contains two values. The first value specifies alignment along the X-axis and the second value specifies alignment along the Y-axis. The first value belongs to the following set of SFInt32: -1, 0, 1. The second value belongs to the following set of SFInt32: -1, 0, 1. An empty alignement field is equivalent to the default value. When the fit field is set to 0, the alignment field is ignored. The meaning of the different values of the fit and alignment fields is described in the following figure.
Figure 1: description of alignment and fit fields
1.1.1.3 TransformMatrix2D
1.1.1.3.1 Node interface
TransformMatrix2D {
eventIn / MFNode / addChildreneventIn / MFNode / removeChildren
exposedField / MFNode / children / []
exposedField / SFFloat / mxx / 1
exposedField / SFFloat / mxy / 0
exposedField / SFFloat / mxz / 0
exposedField / SFFloat / myx / 0
exposedField / SFFloat / myy / 1
exposedField / SFFloat / myz / 0
}
NOTE - For the binary encoding of this node see Annex AcousticMaterial H.
1.1.1.3.2 Functionality and semantics
The TransformMatrix2D node is a grouping node that defines a coordinate system for its children that is relative to the coordinate systems of its ancestors. See ISO/IEC 14772-1:1998 for a description of coordinate systems and transformations and for a description of the children, addChildren, and removeChildren fields and eventIns.
The mxx, mxy, mxz, myx, myy and myz fields define a geometric 2D transformation based on the following transformation matrix:
Given a 2-dimensional point P and TransformMatrix2D node, P is transformed into point P' in its parent's coordinate system by the transformation whose matrix is T.
P' = T × P
The behaviour of TransformMatrix2D with respect to the Sound2D node is the same as the behaviour of the Transform2D node.
The addChildren and removeChildren eventIns are used to add or remove child nodes from the children field of the node as for a Transform2D node.
1.1.1.4 XCurve2D
1.1.1.4.1 Node interface
XCurve2D {
exposedField / SFNode / point / NULLexposedField / SFInt32 / fineness / 0.5
exposedField / MFInt32 / type / []
}
NOTE - For the binary encoding of this node see Annex AcousticMaterial H.
1.1.1.4.2 Functionality and semantics
The XCurve2D node behave exactly as the Curve2D node except that is allows more values in the type field. The permitted values for the type field are:
· 0 = MoveTo: Same as the value 0 for the type field of the Curve2D node. In addition, the coordinate pair consumed from the point list also defines the starting point P0 of a new subpath. MoveTo shall not occur as the first element in type field.
· 1 = LineTo: Same as the value 1 for the type field of the Curve2D node.
· 2 = CurveTo: Same as the value 2 for the type field of the Curve2D node.
· 3 = NextCurveTo: Same as the value 3 for the type field of the Curve2D node.
· 4 = CounterClockWiseArcTo: Three coordinate pairs in the point list are consumed, defining F1, F2 and N. F1 and F2 are the focal points of the ellipse to which P and N belong. On this ellipse, P and N define two arcs. Considering the polar parametric representation of the ellipse and assuming that F1 is the focal point with the negative coordinate on the x-axis, the drawn arc is the one that corresponds to an increase of q when sweeping the arc from P to N. If the points P, F1, F2 and N do not belong to the same ellipse, then the arc is drawn using the quadruple of points P, F1’, F2’ and N, where F1’ and F2’ are scaled version of F1 and F2 with the middle of [F1F2] being the middle of [F1’F2’].