Index

PowerDoc Objects

Text Area

Overview

This objects represents a simple text area. In Power Engine API, a text area is an array of characters or glyphs drawn within the bounds of an invisible rectangular area and formatted according to the specified parameters. Text areas are frequently used to draw formatted text.

Designated Rendering Function: pdDrawTextArea (3)

Note: pdTextString_08, pdTextString_16, pdTextString_24 and pdTextString_32 cannot be used at the same time. pdTextString_32 takes precedence over pdTextString_24. pdTextString_24 takes precedence over pdTextString_16. Finally, pdTextString_16 takes precedence over pdTextString_08.

pdTypographyPtr (1018)

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Glyph, Char, PowerGlyph, Text Path

Link to the Typography object. When standard glyphs or characters are used, this should be a link to the Typography (For Outline Fonts) object. When PowerGlyphs (or PowerChars in the future) are used, this should be a link to the Typography (For PowerFonts) object.

In either case, this link supplies typographic parameters.

pdTypoFramePtr (1177)

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

Link to the Typographic Frame object.

This link supplies parameters necessary to render frames of glyphs and characters.

pdTextLayoutPtr (1084)

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

This link supplies text layout attributes. When building the Text Design or Rich Text Design object, this is a link to the Text Layout (Manual) object. When building any other text object, this is a link to the Text Layout (Automatic) object.

Text Design and Rich Text Design utilize a manual text layout algorithm which means that the (x, y) position of each glyph/character must be supplied explicitly by the user. All other text objects utilize an automatic text layout algorithm which means that the position of their glyphs/characters is calculated automatically by the text layout engine while the user only supplies higher-level layout attributes such as direction, alignment, kerning, letter/row spacing etc.

pdBaselinePtr (1113)

Also appears in: Text Extras, Text Line, Text Arc, Rich Text Line, Rich Text Arc, Rich Text Area, Text Path, Rich Text Path

Link to the Baseline object.

This link supplies parameters necessary to render the baselines of text rows.

pdTextRulerHorPtr (1111)

Also appears in: Text Fragment, Text Path

Link to the Text Ruler (Horizontal) object.

This links associates a text ruler with the current text fragment. The Text Ruler (Horizontal) object supplies indents and tab stop positions to be respected during the text layout process.

pdTextExtrasPtr (1172)

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

Link to the Text Extras object.

Properties

pdTextString_08 (1023)   PD_ASC

Supported Compression Methods: 006

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

Text string, i.e. an array of character or glyph codes (variable length, 1 byte per code).

Sample values:

"Test"
"D-Type"

pdTextString_16 (1024)   PD_HEX

Supported Compression Methods: 004

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

Text string, i.e. an array of character or glyph codes (variable length, 2 bytes per code).

Sample values:

"54 00 65 00 73 00 74 00" ('T', 'e', 's', 't')
"44 00 2D 00 54 00 79 00 70 00 65 00" ('D', '-', 'T', 'y', 'p', 'e')

pdTextString_24 (1118)   PD_HEX

Supported Compression Methods: 002

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

Text string, i.e. an array of character or glyph codes (variable length, 3 bytes per code).

Sample values:

"54 00 00 65 00 00 73 00 00 74 00 00" ('T', 'e', 's', 't')
"44 00 00 2D 00 00 54 00 00 79 00 00 70 00 00 65 00 00" ('D', '-', 'T', 'y', 'p', 'e')

pdTextString_32 (1119)   PD_HEX

Supported Compression Methods: 000

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

Text string, i.e. an array of character or glyph codes (variable length, 4 bytes per code).

Sample values:

"54 00 00 00 65 00 00 00 73 00 00 00 74 00 00 00" ('T', 'e', 's', 't')
"44 00 00 00 2D 00 00 00 54 00 00 00 79 00 00 00 70 00 00 00 65 00 00 00" ('D', '-', 'T', 'y', 'p', 'e')

pdUserSpecificContent (1120)   PD_HEX

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

User-specific content (variable length)

This property allows end-user applications to store their own (i.e. user-specific) content with each text fragment. This property is suitable for user-specific content of variable length (e.g. strings, custom structures etc). D-Type Engine does not use or interpret this content in any way; the interpretation of the user-specific content is entirely up to the end-user application.

Note: Additional technical information about this property is available to customers with a support contract.

pdTextAreaDw (1025)   PD_LONG_SIGNED

Also appears in: Rich Text Area

Width of a text area in document units. Must not be negative. The value 0 is special and means an infinite width; in this configuration the text never wraps and just outputs on one infinitely long text line (the only text line in that text area).

Sample values:

500 = Width of 500 document units
1000 = Width of 1000 document units

pdTextAreaDh (1026)   PD_LONG_SIGNED

Also appears in: Rich Text Area

Height of a text area in document units. Must not be negative. The value 0 is special and means an infinite height; in this configuration the text never flows to any subsequent text areas and just keeps wrapping in one infinitely high text area.

Sample values:

500 = Height of 500 document units
1000 = Height of 1000 document units

pdGlobalDirection (1075)   PD_BYTE_UNSIGNED

Also appears in: Text Line, Text Arc, Rich Text Line, Rich Text Arc, Rich Text Area, Text Path, Rich Text Path

Global text direction and bidirectional text display method.

Supported values:

A) Horizontal Layout (Text in Rows) and Bidirectional Reordering:

0 = Left-to-Right, Top-to-Bottom (e.g. Latin, Cyrillic, Greek)
1 = Right-to-Left, Top-to-Bottom (e.g. Arabic, Hebrew)
2 = Left-to-Right, Bottom-to-Top
3 = Right-to-Left, Bottom-to-Top
4 = Same as 0 but swap Portrait & Landscape
5 = Same as 1 but swap Portrait & Landscape
6 = Same as 2 but swap Portrait & Landscape
7 = Same as 3 but swap Portrait & Landscape

B) Vertical Layout (Text in Columns) and Bidirectional Reordering:

8 = Top-to-Bottom, Right-to-Left (e.g. Vertical Chinese)
9 = Bottom-to-Top, Right-to-Left
10 = Top-to-Bottom, Left-to-Right
11 = Bottom-to-Top, Left-to-Right
12 = Same as 8 but swap Portrait & Landscape
13 = Same as 9 but swap Portrait & Landscape
14 = Same as 10 but swap Portrait & Landscape
15 = Same as 11 but swap Portrait & Landscape

C) Horizontal Layout (Text in Rows) and Bidirectional Rotation:

16 = Left-to-Right, Top-to-Bottom (e.g. Latin, Cyrillic, Greek)
17 = Right-to-Left, Top-to-Bottom (e.g. Arabic, Hebrew)
18 = Left-to-Right, Bottom-to-Top
19 = Right-to-Left, Bottom-to-Top
20 = Same as 16 but swap Portrait & Landscape
21 = Same as 17 but swap Portrait & Landscape
22 = Same as 18 but swap Portrait & Landscape
23 = Same as 19 but swap Portrait & Landscape

D) Vertical Layout (Text in Columns) and Bidirectional Rotation:

24 = Top-to-Bottom, Right-to-Left (e.g. Vertical Chinese)
25 = Bottom-to-Top, Right-to-Left
26 = Top-to-Bottom, Left-to-Right
27 = Bottom-to-Top, Left-to-Right
28 = Same as 24 but swap Portrait & Landscape
29 = Same as 25 but swap Portrait & Landscape
30 = Same as 26 but swap Portrait & Landscape
31 = Same as 27 but swap Portrait & Landscape

Notes:

D-Type Engine can display text in horizontal writing mode (text in rows) and vertical writing mode (text in columns). In horizontal writing mode, the global text progression can be Letf-to-Right/Top-to-Bottom, Right-to-Left/Top-to-Bottom, Letf-to-Right/Bottom-to-Top or Right-to-Left/Bottom-to-Top. In vertical writing mode, the global text progression can be Top-to-Bottom/Right-to-Left, Bottom-to-Top/Right-to-Left, Top-to-Bottom/Left-to-Right or Bottom-to-Top/Left-to-Right.

Additionally, D-Type Engine can display bidirectional text (e.g. a mixture of left-to-right text such as English or Chinese and right-to-left text such as Arabic or Hebrew) using two different methods: the first method is Bidirectional Reordering, the second method is Bidirectional Rotation. Visually, these two methods produce quite different output. However, both are suitable for displaying text that was processed by the Unicode Bidirectional Algorithm (BiDi).

With Bidirectional Reordering the characters are reordered for display depending on the relative direction of the containing text fragment. Thus, a left-to-right text fragment has its characters ordered (visually) in the opposite order from a right-to-left text fragment. While reading bidirectional text, from start to end, the reader must alternate the reading direction (left-to-right/right-to-left in horizontal writing mode or top-to-bottom/bottom-to-top in vertical writing mode) each time a change of direction occurs. This is also the progression of the cursor as it advances from one character to another. This means that with Bidirectional Reordering, the order in which the characters are displayed is not the same as the order in which they are stored in memory (logical or storage order).

With Bidirectional Rotation all characters are ordered uniformly (e.g. from left-to-right in horizontal writing mode or top-to-bottom in vertical writing mode) regardless of whether the containing text fragment has a left-to-right or right-to-left direction. However, their rotation depends on the relative direction of the containing text fragment. More specifically, characters that are part of a left-to-right text fragment are rotated 180 degrees relative to the characters that are part of a right-to-left text fragment. Thus, while reading bidirectional text, from start to end, the reader must rotate the display surface or tilt his/her head (clockwise or counterclockwise) each time a change of direction occurs. However, the reading direction and the progression of the cursor remain uniform. This also means that with Bidirectional Rotation, the order in which the characters are displayed is the same as the order in which they are stored in memory.

Bidirectional Reordering is frequently used in horizontal writing mode and also works well in vertical writing mode. Bidirectional Rotation is typically not used in horizontal writing mode due to the fact that almost all Unicode scripts, when displayed in horizontal writing mode, have their orientation set to portrait (meaning that the glyph's x-axis in font design space is parallel with the baseline). Using Bidirectional Rotation in this case would require the user to rotate the display surface by 180 degrees (clockwise or counterclockwise) each time a change of direction is encountered -- which is, needles to say, far from practical. However, Bidirectional Rotation works well in vertical writing mode. This is due to the fact that vertical writing is used mostly with CJK scripts (Chinese/Japanese/Korean) which typically have their orientation set to landscape (meaning that the glyph's x-axis in font design space is perpendicular to the baseline). Non-CJK scripts, such as Latin or Arabic then have their orientation set to portrait. Under this scheme, the reading direction and the progression of the cursor is always top-to-bottom. When reading the majority of content (i.e. CJK text), there is no need to rotate the display surface. However, when a left-to-right text fragment (e.g. English) is encountered, the reader rotates the display surface by 90 degrees clockwise. Similarly, when a right-to-left text fragment (e.g. Arabic) is encountered, the reader rotates the display surface by 90 degrees counterclockwise. In all three cases (Chinese, English and Arabic) the characters are ordered from top to bottom and the reader is never expected to alter the reading direction (which would otherwise be required if Bidirectional Reordering was used). This is not to say that Bidirectional Reordering cannot be used in vertical writing mode. However, Bidirectional Rotation might work better in certain applications as rotating the display surface by 90 degrees clockwise or counterclockwise relative to the vertical baseline is sometimes considered a more practical way of reading vertical bidirectional text.

txLockStatus (2005)   PD_BYTE_UNSIGNED

Also appears in: Text Line, Text Arc, Rich Text Line, Rich Text Arc, Rich Text Area, Text Path, Rich Text Path

A flag that indicates whether and how the text is locked for user interactions. This flag is respected by D-Type Text Engine.

Supported values:

0 = Text is not locked (all user interactions are enabled)

1 = Text is completely locked (all user interactions are disabled)

2 = Text is locked for both editing and formatting/styling (but a user can still move the cursor and make text selections)

3 = Text is locked for editing but not for formatting/styling (and a user can still move the cursor and make text selections)

4 = Text is locked for formatting/styling but not for editing (and a user can still move the cursor and make text selections)

txMiscFlags (2006)   PD_BYTE_UNSIGNED

Also appears in: Text Line, Text Arc, Rich Text Line, Rich Text Arc, Rich Text Area, Text Path, Rich Text Path

Miscellaneous text handling flags respected by D-Type Text Engine.

Supported values:

Bit 0: If this bit is set, text selection and cursor movement operations will be processed normally by D-Type Text Engine but will not be shown to the user. It will appear as if the cursor and text selections are completely transparent.

Bits 1 - 7: Reserved for future use.

pdDeviceMode (1101)   PD_BYTE_UNSIGNED

Also appears in: Text Line, Rich Text Line, Rich Text Area

Indicates whether text should be rendered in a device independent, device dependent or mixed mode. Review the "Rendering Great Looking Text With D-Type" document for a comprehensive overview.

Supported values:

0 = Device Independent Mode. Text will be rendered in a device independent mode, which means that text metrics are independent of the device, resolution or zoom factor and are mathematically accurate. Therefore, in text areas and rich text areas, characters that are supposed to vertically line up will always line up. In addition, all text lines will always fit within the width of the enclosing area. This is the default mode. Recommended for WYSIWYG applications.

1 = Device Dependent Mode #1. Text will be rendered in a device dependent mode, which means that text metrics are device specific. This mode utilizes a complex device dependent formula that is specially crafted to give good looking character spacing (calculated in whole-pixel units). This mode corresponds to the DV_TEXTMODE_DEVICE value in D-Type Standard Engine. See the dtxTextDoOutput family of functions in D-Type Standard Engine Manual for details.

Important note for text areas and rich text areas: Because this mode is device dependent, please be aware that the length of certain text lines will sometimes exceed the width of the enclosing area; also characters that are supposed to vertically line up will usually not line up. This behavior is by design.

2 = Device Dependent Mode #2. Text will be rendered in a device dependent mode, which means that text metrics are device specific. This mode is similar to Device Dependent Mode #1 since it also utilizes a complex device dependent formula crafted to give good looking character spacing. However, this mode produces even better looking and easier to read text, especially at smaller sizes. This is accomplished by artificially increasing the amount of character spacing between certain characters and in certain conditions. This mode corresponds to the DV_TEXTMODE_DEVICE_2 value in D-Type Standard Engine. See the dtxTextDoOutput family of functions in D-Type Standard Engine Manual for details.

Important note for text areas and rich text areas: Because this mode is device dependent (and also because the character spacing may be artificially increased), please be aware that the length of certain text lines will sometimes exceed the width of the enclosing area; also characters that are supposed to vertically line up will usually not line up. This behavior is by design.

101 = Mixed Mode #1. By default, the engine will render all text using Device Dependent Mode #1. In text areas and rich text areas, however, if there are any text lines whose length would exceed the width of the enclosing area, then those text lines will be rendered in a device independent manner. Consequently, for text areas and rich text areas, this mode guarantees that all text lines will always fit within the width of the enclosing area.

102 = Mixed Mode #2. By default, the engine will render all text using Device Dependent Mode #2. In text areas and rich text areas, however, if there are any text lines whose length would exceed the width of the enclosing area, then the engine will attempt to render those lines using Device Dependent Mode #1. If, after this, there are still some text lines whose length exceeds the width of the enclosing area, then those lines will be rendered in a device independent manner. Consequently, for text areas and rich text areas, this mode guarantees that all text lines will always fit within the width of the enclosing area. This mode usually produces great looking character spacing and is highly recommended whenever true WYSIWYG support is not a priority.

pdGlyphStart (1076)   PD_ARR_LONG_SIGNED

Also appears in: Text Line, Text Arc, Rich Text Line, Rich Text Arc, Rich Text Area, Text Path, Rich Text Path

Start glyph position within the first text fragment, i.e. the index of the glyph in the first text fragment from which the text layout and display starts. This value cannot be negative and must be less than the length of the first text fragment.

This property is useful when building text flows (i.e. when text fragments span more than one text area). In most other cases, this property should be omitted or its value should be set to 0.

pdTextAreaType (1073)   PD_BYTE_UNSIGNED

Also appears in: Rich Text Area

Type of text area and control of empty text lines.

The first 6 bits (Bit 0 - Bit 5) are interpreted as a single 6 bit value. This value specifies the type of the text area and can be one of the following:

Supported values:

0 = Rectangular

5 = Custom (use in conjunction with pdTextAreaEdgeLeft and/or pdTextAreaEdgeRight)
6 = Custom With Extra Precision (use in conjunction with pdTextAreaEdgeLeft and/or pdTextAreaEdgeRight)

10 = Quarter-Circular A
11 = Quarter-Circular B
12 = Quarter-Circular C
13 = Quarter-Circular D
14 = Half-Circular A
15 = Half-Circular B
16 = Half-Circular C
17 = Half-Circular D
18 = Circular

20 = Quarter-Diamond A
21 = Quarter-Diamond B
22 = Quarter-Diamond C
23 = Quarter-Diamond D
24 = Half-Diamond A
25 = Half-Diamond B
26 = Half-Diamond C
27 = Half-Diamond D
28 = Diamond

The seventh bit (Bit 6) is interpreted as a single bit value that specifies how the left (pdTextAreaEdgeLeft) and right edge (pdTextAreaEdgeRight) in non-rectangular text areas will be calculated. If this bit is set (1), the calculation will be more precise but slower; otherwise, if this bit is unset (0), the calculation will be less precise but faster. In rectangular text areas, this bit is ignored.

The final bit (Bit 7) is interpreted as a single bit value that signifies whether the control of empty text lines is enabled. If this bit is set (1), the control of empty text lines is enabled; otherwise, if this bit is unset (0), the control of empty text lines is disabled.

When the control of empty text lines is enabled, D-Type Engine will ignore any trailing empty text lines (i.e. text lines that only contain white characters such as spaces or carriage returns) when performing vertical alignment of text in this text area. This is useful in high-end text layout applications that require more professional vertical alignment of text.

pdTextAreaEdgeLeft (1077)   PD_ARR_BYTE_UNSIGNED

Also appears in: Rich Text Area

Left edge polyline for text areas. This property makes it possible to create text areas with a custom (i.e. user-defined) left edge. In order for the custom left edge to take effect, the pdTextAreaType property must be set to 5 or 6.

The left edge polyline is defined as a sequence of connected segments which can be made of lines, Quadratic B-Spline and/or Bezier curves. Each sequence begins with the descriptor (value 20, 25 or 24) followed by an appropriate number of coordinates for the control points as shown below:

Line: 20, X1, Y1
Quadratic B-Spline Curve: 25, X1, Y1, X2, Y2
Bezier Curve: 24, X1, Y1, X2, Y2, X3, Y3

The size of each descriptor value (20, 25 or 24) is always 1 byte.

When pdTextAreaType is 5, the size of each coordinate is 1 byte. In this case X1, X2 and X3 represent X coordinates of the segment's control points and must be in the 0-255 range. The value 0 means 0% of the text area width while the value 255 means 100% of the text area width. Similarly, Y1, Y2 and Y3 represent Y coordinates of the segment's control points and must be in the 0-255 range. The value 0 means 0% of the text area height while the value 255 means 100% of the text area height.

When pdTextAreaType is 6, the size of each coordinate is 2 bytes (little endian byte ordering). In this case X1, X2 and X3 represent X coordinates of the segment's control points and must be in the 0 - 65,535 range. The value 0 means 0% of the text area width while the value 65,535 means 100% of the text area width. Similarly, Y1, Y2 and Y3 represent Y coordinates of the segment's control points and must be in the 0 - 65,535 range. The value 0 means 0% of the text area height while the value 65,535 means 100% of the text area height.

Implicitly, the first control point is always located at the coordinate (0, 0) which is the top left corner of the text area. Therefore, the user definition of the polyline starts with the second control point. In addition, the last control point is automatically placed at the coordinate (x_last, y_max) where x_last is the X coordinate of the last user defined control point and y_max is 255 (when pdTextAreaType is 5) or 65,535 (when pdTextAreaType is 6). In this way the polyline and the text area always have the same height.

Although any sequence of connected lines, Quadratic B-Spline and/or Bezier curves can be used to define a polyline, the Y coordinates should be specified in a non-decreasing order. That is, any time a new Y coordinates is specified, its value should not be less than the value of the previously specified Y coordinate. This is to ensure that the polyline does not have multiple intersections with any horizontal line. This restriction does not apply to X coordinates.

Sample values (when pdTextAreaType is 5):

"25, 91, 64, 26, 128, 20, 102, 192"
"20, 255, 0, 20, 190, 90, 24, 190, 200, 140, 200, 70, 210, 20, 0, 255"

pdTextAreaEdgeRight (1078)   PD_ARR_BYTE_UNSIGNED

Also appears in: Rich Text Area

Right edge polyline for text areas. This property makes it possible to create text areas with a custom (i.e. user-defined) right edge. In order for the custom right edge to take effect, the pdTextAreaType property must be set to 5 or 6.

The right edge polyline is defined as a sequence of connected segments which can be made of lines, Quadratic B-Spline and/or Bezier curves. Each sequence begins with the descriptor (value 20, 25 or 24) followed by an appropriate number of coordinates for the control points as shown below:

Line: 20, X1, Y1
Quadratic B-Spline Curve: 25, X1, Y1, X2, Y2
Bezier Curve: 24, X1, Y1, X2, Y2, X3, Y3

The size of each descriptor value (20, 25 or 24) is always 1 byte.

When pdTextAreaType is 5, the size of each coordinate is 1 byte. In this case X1, X2 and X3 represent X coordinates of the segment's control points and must be in the 0-255 range. The value 0 means 0% of the text area width while the value 255 means 100% of the text area width. Similarly, Y1, Y2 and Y3 represent Y coordinates of the segment's control points and must be in the 0-255 range. The value 0 means 0% of the text area height while the value 255 means 100% of the text area height.

When pdTextAreaType is 6, the size of each coordinate is 2 bytes (little endian byte ordering). In this case X1, X2 and X3 represent X coordinates of the segment's control points and must be in the 0 - 65,535 range. The value 0 means 0% of the text area width while the value 65,535 means 100% of the text area width. Similarly, Y1, Y2 and Y3 represent Y coordinates of the segment's control points and must be in the 0 - 65,535 range. The value 0 means 0% of the text area height while the value 65,535 means 100% of the text area height.

Implicitly, the first control point is always located at the coordinate (0, 0) which is the top right corner of the text area. Therefore, the user definition of the polyline starts with the second control point. In addition, the last control point is automatically placed at the coordinate (x_last, y_max) where x_last is the X coordinate of the last user defined control point and y_max is 255 (when pdTextAreaType is 5) or 65,535 (when pdTextAreaType is 6). In this way the polyline and the text area always have the same height.

Although any sequence of connected lines, Quadratic B-Spline and/or Bezier curves can be used to define a polyline, the Y coordinates should be specified in a non-decreasing order. That is, any time a new Y coordinates is specified, its value should not be less than the value of the previously specified Y coordinate. This is to ensure that the polyline does not have multiple intersections with any horizontal line. This restriction does not apply to X coordinates.

Sample values (when pdTextAreaType is 5):

"20, 70, 45, 24, 140, 55, 190, 55, 190, 165, 20, 255, 255"
"20, 51, 64, 20, 26, 128, 20, 102, 192"

pdTextAreaRowType (1065)   PD_BYTE_UNSIGNED

Also appears in: Rich Text Area

Row spacing calculation method.

0 = Mathematically calculate spacing between text rows.

10 = Respect typographic values when calculating spacing between text rows. The typographic values must be defined in the font file in order for this method to function as intended. For text in horizontal layout (rows), the typographic values are supplied by the sTypoAscender and sTypoDescender fields of the OS/2 table (TrueType/OpenType fonts) or the Ascender and Descender key of the Font Metrics (AFM) file (Type 1/Type 3 fonts). D-Type Font Engine refers to these values in a portable fashion via the DV_NVAL_ASCENDER and DV_NVAL_DESCENDER identifiers. For text in vertical layout (columns), the typographic values are supplied by the vertTypoAscender and vertTypoDescender fields of the vhea table (TrueType/OpenType fonts). D-Type Font Engine refers to these values in a portable fashion via the DV_NVAL_VER_ASCENDER and DV_NVAL_VER_DESCENDER identifiers. If the typographic values are not defined in the font file, method 0 will be used instead.

20 = Same as method 10 but adds an additional linegap, if available in the font. For text in horizontal layout (rows), this additional linegap is supplied by the sTypoLineGap field of the OS/2 table (TrueType/OpenType fonts); in Type 1 and Type 3 fonts, this information is most likely not available. D-Type Font Engine refers to this value in a portable fashion via the DV_NVAL_LINEGAP identifier. For text in vertical layout (columns), the additional linegap is supplied by the vertTypoLineGap field of the vhea table (TrueType/OpenType fonts). D-Type Font Engine refers to this value in a portable fashion via the DV_NVAL_VER_LINEGAP identifier.

30 = Respect Windows specific typographic values when calculating spacing between text rows. The Windows specific typographic values must be defined in the font file in order for this method to function as intended. For text in either horizontal layout (rows) or vertical layout (columns), the Windows specific typographic values are supplied by the usWinAscent and usWinDescent fields of the OS/2 table (TrueType/OpenType fonts). D-Type Font Engine refers to these values in a portable fashion via the DV_NVAL_WIN_ASCENT and DV_NVAL_WIN_DESCENT identifiers. If the Windows specific typographic values are not defined in the font file, method 0 will be used instead.

110 = Same as method 10, but horizontal typographic values are used for text in vertical layout (columns). Although not ideal from a purely mathematical standpoint, this method seems to work well with most CJK fonts.

120 = Same as method 20, but horizontal typographic values are used for text in vertical layout (columns). Although not ideal from a purely mathematical standpoint, this method seems to work well with most CJK fonts.

Other property values will be described in the future.

Supported values: 0, 1, 2, 3, 4, 10, 11, 12, 13, 14, 20, 21, 22, 23, 24, 30, 31, 32, 33, 34, 110, 111, 112, 113, 114, 120, 121, 122, 123, 124

pdWrapType (1066)   PD_BYTE_UNSIGNED

Also appears in: Rich Text Area, Text Path, Rich Text Path

Text wrap method.

Supported values:

0 = Soft Wrap Enabled
1 = Soft Wrap Disabled - trim text after any character
2 = Soft Wrap Disabled - trim text only after space or some other breakable character (e.g. CJK) but not after a hyphen
3 = Soft Wrap Disabled - trim text only after space or some other breakable character (e.g. CJK) or after a hyphen
4 = Soft Wrap Disabled - trim text after any character and add a horizontal ellipsis

pdTextEncoding (1079)   PD_BYTE_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Design, Text Path

Text encoding format. If this property is not specified, then the value 0 (Unicode character codes) is assumed.

Supported values:

0 = Unicode character codes
1 = Glyph codes (font dependent)
2 = Unicode PowerChar codes - reserved for future use
3 = PowerGlyph codes (font dependent)

pdTextShaping (1080)   PD_LONG_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

Text shaping. Complex features and scripts (e.g. ligatures, Arabic and various Indic scripts) require D-Type or TrueType/OpenType fonts with advanced typography tables.

Supported values:

0 = None
1 = Default
2 = Feature: Optional Latin Ligatures
3 = Feature: Standard Arabic Ligatures
4 = Feature: Discretionary Latin Ligatures
5 = Feature: Historical Latin Ligatures
6 = Feature: Vertical CJK Ideographic Forms
7 = Feature: Vertical Hiragana/Katakana Forms
101 = Script & Line Breaking: Default
102 = Script & Line Breaking: Latin
103 = Script & Line Breaking: Arabic
104 = Script & Line Breaking: Hebrew
105 = Script & Line Breaking: Greek
106 = Script & Line Breaking: CJK Ideographic
107 = Script & Line Breaking: Hiragana/Katakana
108 = Script & Line Breaking: Cyrillic
1001 = Script & Line Breaking: Vertical Default
1002 = Script & Line Breaking: Vertical Latin
1006 = Script & Line Breaking: Vertical CJK Ideographic
1007 = Script & Line Breaking: Vertical Hiragana/Katakana
10000 = Unicode Script & Line Breaking: Common
10001 = Unicode Script & Line Breaking: Inherited
10002 = Unicode Script & Line Breaking: Arabic
10003 = Unicode Script & Line Breaking: Armenian
10004 = Unicode Script & Line Breaking: Bengali
10005 = Unicode Script & Line Breaking: Bopomofo
10006 = Unicode Script & Line Breaking: Cherokee
10007 = Unicode Script & Line Breaking: Coptic
10008 = Unicode Script & Line Breaking: Cyrillic
10009 = Unicode Script & Line Breaking: Deseret
10010 = Unicode Script & Line Breaking: Devanagari
10011 = Unicode Script & Line Breaking: Ethiopic
10012 = Unicode Script & Line Breaking: Georgian
10013 = Unicode Script & Line Breaking: Gothic
10014 = Unicode Script & Line Breaking: Greek
10015 = Unicode Script & Line Breaking: Gujarati
10016 = Unicode Script & Line Breaking: Gurmukhi
10017 = Unicode Script & Line Breaking: Han
10018 = Unicode Script & Line Breaking: Hangul
10019 = Unicode Script & Line Breaking: Hebrew
10020 = Unicode Script & Line Breaking: Hiragana
10021 = Unicode Script & Line Breaking: Kannada
10022 = Unicode Script & Line Breaking: Katakana
10023 = Unicode Script & Line Breaking: Khmer
10024 = Unicode Script & Line Breaking: Lao
10025 = Unicode Script & Line Breaking: Latin
10026 = Unicode Script & Line Breaking: Malayalam
10027 = Unicode Script & Line Breaking: Mongolian
10028 = Unicode Script & Line Breaking: Myanmar
10029 = Unicode Script & Line Breaking: Ogham
10030 = Unicode Script & Line Breaking: Old Italic
10031 = Unicode Script & Line Breaking: Oriya
10032 = Unicode Script & Line Breaking: Runic
10033 = Unicode Script & Line Breaking: Sinhala
10034 = Unicode Script & Line Breaking: Syriac
10035 = Unicode Script & Line Breaking: Tamil
10036 = Unicode Script & Line Breaking: Telugu
10037 = Unicode Script & Line Breaking: Thaana
10038 = Unicode Script & Line Breaking: Thai
10039 = Unicode Script & Line Breaking: Tibetan
10040 = Unicode Script & Line Breaking: Unified Canadian Aboriginal Symbols
10041 = Unicode Script & Line Breaking: Yi syllables
10042 = Unicode Script & Line Breaking: Tagalog
10043 = Unicode Script & Line Breaking: Hanunoo
10044 = Unicode Script & Line Breaking: Buhid
10045 = Unicode Script & Line Breaking: Tagbanwa

pdTextLanguage (1135)   PD_WORD_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

Language of the text. Although optional and rarely used, this value is primarily a hint needed to influence the text shaping process with certain Unicode scripts.

Supported values:

0 = None
1 = araLanguageCode = Arabic
2 = asmLanguageCode = Assamese
3 = benLanguageCode = Bengali
4 = farLanguageCode = Farsi
5 = gujLanguageCode = Gujarati
6 = hinLanguageCode = Hindi
7 = iwrLanguageCode = Hebrew
8 = jiiLanguageCode = Yiddish
9 = janLanguageCode = Japanese
10 = kanLanguageCode = Kannada
11 = kokLanguageCode = Konkani
12 = korLanguageCode = Korean
13 = kshLanguageCode = Kashmiri
14 = malLanguageCode = Malayalam Traditional
15 = marLanguageCode = Marathi
16 = mlrLanguageCode = Malayalam Reformed
17 = mniLanguageCode = Manipuri
18 = oriLanguageCode = Oriya
19 = sanLanguageCode = Sanskrit
20 = sndLanguageCode = Sindhi
21 = snhLanguageCode = Sinhalese
22 = syrLanguageCode = Syriac
23 = tamLanguageCode = Tamil
24 = telLanguageCode = Telugu
25 = thaLanguageCode = Thai
26 = urdLanguageCode = Urdu
27 = zhpLanguageCode = Chinese Phonetic
28 = zhsLanguageCode = Chinese Simplified
29 = zhtLanguageCode = Chinese Traditional
30 = afkLanguageCode = Afrikaans
31 = belLanguageCode = Belarussian
32 = bgrLanguageCode = Bulgarian
33 = catLanguageCode = Catalan
34 = cheLanguageCode = Chechen
35 = copLanguageCode = Coptic
36 = csyLanguageCode = Czech
37 = danLanguageCode = Danish
38 = deuLanguageCode = German
39 = dznLanguageCode = Dzongkha
40 = ellLanguageCode = Greek
41 = engLanguageCode = English
42 = espLanguageCode = Spanish
43 = etiLanguageCode = Estonian
44 = euqLanguageCode = Basque
45 = finLanguageCode = Finnish
46 = fraLanguageCode = French
47 = gaeLanguageCode = Gaelic
48 = hauLanguageCode = Hausa
49 = hrvLanguageCode = Croatian
50 = hunLanguageCode = Hungarian
51 = hyeLanguageCode = Armenian
52 = indLanguageCode = Indonesian
53 = itaLanguageCode = Italian
54 = khmLanguageCode = Khmer
55 = mngLanguageCode = Mongolian
56 = mtsLanguageCode = Maltese
57 = nepLanguageCode = Nepali
58 = nldLanguageCode = Dutch
59 = pasLanguageCode = Pashto
60 = plkLanguageCode = Polish
61 = ptgLanguageCode = Portuguese
62 = romLanguageCode = Romanian
63 = rusLanguageCode = Russian
64 = skyLanguageCode = Slovak
65 = slvLanguageCode = Slovenian
66 = sqiLanguageCode = Albanian
67 = srbLanguageCode = Serbian
68 = sveLanguageCode = Swedish
69 = tibLanguageCode = Tibetan
70 = trkLanguageCode = Turkish
71 = welLanguageCode = Welsh

pdTextShapingParam0 (1136)   PD_LONG_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

A value consisting of 4 independent bits. Each bit indicates whether a certain typographic feature for a script is enabled or disabled. This makes it possible to fine tune the text shaping process.

Supported values:

1 (bit 0 set) = Disable kerning
2 (bit 1 set) = Disable optional ligatures
131072 (bit 17 set) = Enable discretionary ligatures
262144 (bit 18 set) = Enable historical ligatures

Sample values:

3 = Disable kerning and optional ligatures
131074 = Enable discretionary ligatures and disable optional ligatures
393216 = Enable discretionary and historical ligatures

pdTextBreakFlags (1116)   PD_BYTE_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

A value consisting of 5 independent bits. Each bit indicates whether a line break is allowed after a certain user-selectble class of characters. This makes it possible to fine tune the behavior of the text wrapping algorithm (on arbitrary text selections) in order to improve the appearance of text.

Supported values:

Bit 0 - If set, line break is allowed after common punctuation marks (e.g. period, comma, exclamation mark, question mark, colon, semi-colon)
Bit 1 - If set, line break is allowed after other punctuation marks (e.g. middle dot, inverted exclamation mark, inverted question mark)
Bit 2 - If set, line break is allowed after minus/hyphen signs and dashes (e.g. en dash, em dash, horizontal bar)
Bit 3 - If set, line break is allowed after forward or backward slashes
Bit 4 - If set, line break is allowed after other separators (e.g. pipe)
Bit 5 - If set, line break is allowed after closing brackets/parentheses
Bit 6 - If set, line break is allowed after other terminating symbols (e.g. percent, degree, cent sign)

Sample values:

0 = Line break is not allowed after any user-selectable class of characters
1 = Line break is allowed after common punctuation marks
8 = Line break is allowed after forward or backward slashes
9 = Line break is allowed after common punctuation marks and forward or backward slashes
11 = Line break is allowed after common punctuation marks, other punctuation marks and forward or backward slashes
31 = Line break is allowed after all user-selectable classes of characters

pdTextHyphenBits (1117)   PD_ARR_BYTE_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

Index of the hyphenation dictionary (1 byte) followed by one reserved byte (must be zero) followed by an array of hyphen bits (variable length, one bit for each glyph or character).

This property makes it possible to apply language specific hyphenation rules to arbitrary text selections. This typically results in improved text wrapping behavior, especially when text is laid out in narrow columns. This is useful in high-end text layout applications that require more professional justification of text lines.

Hyphenation dictionaries are set up via dtype.inf. Each hyphenation dictionary is a file (steam) that contains specific hyphenation instructions and hyphenation patterns for the supported target language. The index of the hyphenation dictionary (first byte) simply references one of these files (streams). For example, index 1 references the first hyphenation dictionary set up via dtype.inf (which is the English hyphenation dictionary), index 2 references the second one (which is the French hyphenation dictionary) and so on. Consequently, a positive index enables automatic hyphenation while the index 0 disables the hyphenation (in which case no additional bytes are needed).

D-Type Power Engine by itself does not use the index of the hyphenation dictionary as parsing the hyphenation instructions and patterns in real time can be slow. The purpose of this index is to allow text processing clients to re-hyphenate text as the user makes changes to it and store processed hyphenation results in the array of hyphen bits. D-Type Power Engine then reads the array of hyphen bits to extract these processed hyphenation results. The array of hyphen bits tells D-Type Power Engine whether a hyphen is allowed after the glyph or character in the corresponding text fragment. If a bit in the array of hyphen bits is set (1), a hyphen is allowed after the corresponding glyph/character; if unset (0) then the hyphen is not allowed after the corresponding glyph/character. Any trailing unset bits can be omitted. This means that the number of bits in the array of hyphen bits can be less than the number of glyphs/characters in the corresponding text fragment.

Sample values:

0 = Disable hyphenation

1, 0, 12, 10, 128, 136 = Enable automatic hyphenation; use the English hyphenation dictionary to hyphenate text. The array 12, 10, 128, 136 (00001100, 00001010, 10000000, 10001000) means that a hyphen can be inserted after the 5th, 6th, 13th, 15th, 17th, 25th and 29th character in the corresponding text fragment.

2, 0, 33, 112, 128 = Enable automatic hyphenation; use the French hyphenation dictionary to hyphenate text. The array 33, 112, 128 (00100001, 01110000, 10000000) means that a hyphen can be inserted after the 3rd, 8th, 10th, 11th, 12th and 17th character in the corresponding text fragment.

pdTextAreaVAlign (1109)   PD_BYTE_UNSIGNED

Also appears in: Rich Text Area

Vertical alignment of text inside a text area, when the text flow does not end or break in that text area.

Supported values:

0 = Top
1 = Middle
2 = Bottom
3 = Justified

pdTextAreaVAlignEnd (1110)   PD_BYTE_UNSIGNED

Also appears in: Rich Text Area

Vertical alignment of text inside a text area, when the text flow ends or breaks in that text area.

Supported values:

0 = Top
1 = Middle
2 = Bottom
3 = Justified

pdTextMiscAttribs (1128)   PD_BYTE_UNSIGNED

Also appears in: Text Fragment, Text Line, Text Arc, Text Path

Misc Text Attributes

Bit 0: 1 = Don't allow line break at the end of the text fragment

Example

C/C++

DT_ID_SLONG obj[9];

obj[0] = pdObjAdd(pd, 0, "TextArea Outline Style");
obj[1] = pdObjAdd(pd, 0, "TextArea Body Style");
obj[2] = pdObjAdd(pd, 0, "TextArea Shadow Style");
obj[3] = pdObjAdd(pd, 0, "TextArea Outline");
obj[4] = pdObjAdd(pd, 0, "TextArea Shadow");
obj[5] = pdObjAdd(pd, 0, "TextArea Typography");
obj[6] = pdObjAdd(pd, 0, "TextArea Layout");
obj[7] = pdObjAdd(pd, 0, "TextArea Ruler");
obj[8] = pdObjAdd(pd, 0, "TextArea");

/* Properties for object 0 */
pdPropAdd(pd, obj[0], pdRGBT, "50641400", PD_HEX);

/* Properties for object 1 */
pdPropAdd(pd, obj[1], pdRGBT, "B4961400", PD_HEX);

/* Properties for object 2 */
pdPropAdd(pd, obj[2], pdRGBT, "80808078", PD_HEX);
pdPropAdd(pd, obj[2], pdEP, "030A", PD_HEX);

/* Properties for object 3 */
pdLinkAdd(pd, obj[3], pdStylePtr, obj[0]);
pdPropAdd(pd, obj[3], pdLineThickness, "240", PD_WORD_SIGNED);

/* Properties for object 4 */
pdLinkAdd(pd, obj[4], pdStylePtr, obj[2]);
pdPropAdd(pd, obj[4], pdShadowDx, "5", PD_WORD_SIGNED);
pdPropAdd(pd, obj[4], pdShadowDy, "5", PD_WORD_SIGNED);

/* Properties for object 5 */
pdLinkAdd(pd, obj[5], pdBodyPtr, obj[1]);
pdLinkAdd(pd, obj[5], pdShadowPtr, obj[4]);
pdLinkAdd(pd, obj[5], pdOutlinePtr, obj[3]);
pdPropAdd(pd, obj[5], pdFontIndex, "0", PD_WORD_SIGNED);
pdPropAdd(pd, obj[5], pdFontDw, "90", PD_WORD_SIGNED);
pdPropAdd(pd, obj[5], pdFontDh, "90", PD_WORD_SIGNED);

/* Properties for object 6 */
pdPropAdd(pd, obj[6], pdSpacingRow, "10", PD_WORD_SIGNED);
pdPropAdd(pd, obj[6], pdSpacingLetter, "5", PD_WORD_SIGNED);
pdPropAdd(pd, obj[6], pdKerning, "1", PD_BYTE_UNSIGNED);
pdPropAdd(pd, obj[6], pdAlign, "3", PD_BYTE_UNSIGNED);

/* Properties for object 7 */
pdPropAdd(pd, obj[7], pdTabStopPositions, "40, 80, 150, 220", PD_ARR_BYTE_UNSIGNED);
pdPropAdd(pd, obj[7], pdTabStopFlags, "1, 0, 0, 2", PD_ARR_BYTE_UNSIGNED);

/* Properties for object 8 */
pdLinkAdd(pd, obj[8], pdTypographyPtr, obj[5]);
pdLinkAdd(pd, obj[8], pdTextLayoutPtr, obj[6]);
pdLinkAdd(pd, obj[8], pdTextRulerHorPtr, obj[7]);
pdPropAdd(pd, obj[8], pdTextAreaDw, "800", PD_LONG_SIGNED);
pdPropAdd(pd, obj[8], pdTextAreaDh, "400", PD_LONG_SIGNED);
pdPropAdd(pd, obj[8], pdTextString_08, "This is a simple text area", PD_ASC);


/* Image placement */
pdImgAdd(pd, obj[8], 0, 50, 50, 0, 0, 0, pdDrawTextArea, DV_NULL);

INTEGRAL DSL

/* Lambda shortcuts */

local o = @(label = "") CDTObj(::my.doc, label); /* to make object */
local p = @(id, str, len = PD_DEFAULT) CDTProp(id, str, len); /* to add property - general */
local s = @(id, str) CDTPropStr(id, str); /* to add property - string */
local i = @(id, num) CDTPropInt(id, num); /* to add property - integer */
local l = @(id, obj) CDTLink(id, obj); /* to add link */

/* Objects */

local obj_0 = o("TextArea Outline Style");
local obj_1 = o("TextArea Body Style");
local obj_2 = o("TextArea Shadow Style");
local obj_3 = o("TextArea Outline");
local obj_4 = o("TextArea Shadow");
local obj_5 = o("TextArea Typography");
local obj_6 = o("TextArea Layout");
local obj_7 = o("TextArea Ruler");
local obj_8 = o("TextArea");

/* Object Properties */

obj_0 + s(pdRGBT, "50641400");

obj_1 + s(pdRGBT, "B4961400");

obj_2 + s(pdRGBT, "80808078");
obj_2 + s(pdEP, "030A");

obj_3 + l(pdStylePtr, obj_0);
obj_3 + i(pdLineThickness, 240);

obj_4 + l(pdStylePtr, obj_2);
obj_4 + i(pdShadowDx, 5);
obj_4 + i(pdShadowDy, 5);

obj_5 + l(pdBodyPtr, obj_1);
obj_5 + l(pdShadowPtr, obj_4);
obj_5 + l(pdOutlinePtr, obj_3);
obj_5 + i(pdFontIndex, 0);
obj_5 + i(pdFontDw, 90);
obj_5 + i(pdFontDh, 90);

obj_6 + i(pdSpacingRow, 10);
obj_6 + i(pdSpacingLetter, 5);
obj_6 + i(pdKerning, 1);
obj_6 + i(pdAlign, 3);

obj_7 + p(pdTabStopPositions, "40, 80, 150, 220");
obj_7 + p(pdTabStopFlags, "1, 0, 0, 2");

obj_8 + l(pdTypographyPtr, obj_5);
obj_8 + l(pdTextLayoutPtr, obj_6);
obj_8 + l(pdTextRulerHorPtr, obj_7);
obj_8 + i(pdTextAreaDw, 800);
obj_8 + i(pdTextAreaDh, 400);
obj_8 + s(pdTextString_08, "This is a simple text area");

/* Image Pinning */

obj_8.Pin(0, 50, 50, pdDrawTextArea);
 

Index