Also appears in: Text Fragment, Rich Text Line, Rich Text Arc, Rich Text Design, Rich Text Path, Rich Text Box, Rich Button, Rich List Box
Link to the Text Fragment object.
This link in used to establish a link to the next text fragment. This can be the first text fragment or the fragment that follows the current one.
Also appears in: Text Extras, Text Line, Text Arc, Text Area, Rich Text Line, Rich Text Arc, Text Path, Rich Text Path
Link to the Baseline object.
This link supplies parameters necessary to render the baselines of text rows.
Link to the Rich Text Area object.
This link in used to establish a link to the first rich text area in a text flow chain. This link will be described more thoroughly in the future.
Link to the Rich Text Area object.
This link in used to establish a link to the next rich text area in a text flow chain. This link will be described more thoroughly in the future.
Also appears in: 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
Also appears in: 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
Also appears in: Text Line, Text Arc, Text Area, Rich Text Line, Rich Text Arc, 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.
Also appears in: Text Line, Text Arc, Text Area, Rich Text Line, Rich Text Arc, 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)
Also appears in: Text Line, Text Arc, Text Area, Rich Text Line, Rich Text Arc, 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.
Also appears in: Text Line, Text Area, Rich Text Line
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.
Also appears in: Text Line, Text Arc, Text Area, Rich Text Line, Rich Text Arc, 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.
Also appears in: 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.
Also appears in: 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"
Also appears in: 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"
Also appears in: 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
Also appears in: 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
Also appears in: 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
Also appears in: 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
C/C++
INTEGRAL DSL