|
Table of Contents 2. Text Formatting - Main Objectives 2.1. Calculation of Paragraph Sizes 2.3. Calculation of Character Positions 3. Prerequisites – Where do we start? 3.2. Width and Height of the Environment 4. Portions - The Basic Concept of Text Formatting 5.2. Attribute Handler and Attribute Stacks 6.1. The Script Type Data Structure 9. Main Objectives - A closer Look 9.1.1. Line Breaks and the Break Iterator 9.3.1. Cursor Positions inside Fields 10. Details on selected Topics 10.5. The nDelta Member of SwParaPortion 10.8.1. Online (Auto) Spell Checking 10.8.2. Interactive Spell Checking 10.11. Alphabetic Index Sorting
1. IntroductionThis paper can only give a rough summary of the text formatting component of StarWriter. Many important concepts and aspects are not yet discussed here, but maybe they will be one day, since this paper is work in progress. I hope this will be useful for somebody. 2. Text Formatting - Main Objectives2.1. Calculation of Paragraph SizesThe main objective of the text formatting process is the calculation of paragraph sizes. Depending on the direction of writing (left to right in western countries, top to bottom in the Asian world) a width or height is given from the environment, the other value results from the number and sizes of the lines in the paragraph. For this, line breaks have to be calculated. A paragraph has to be split into several parts, if there is not sufficient space for it. The information obtained from the text formatting process are cached for increasing performance. More on this objective can be found in section 9.1. 2.2. VisualizationIn addition, the text formatting is responsible for repainting parts of an paragraph, overlapping with a given rectangle. The rectangular areas to be repainted are obtained from the layout. For this, an output device (usually a monitor or printer) is selected. The output device knows about different fonts and how to paint them. A more detailed description of repaint events is given in section 9.2. 2.3. Calculation of Character PositionsA difference has to be made between document coordinates and paragraph positions. While document coordinates refer to the more physical aspects of pages, paragraph positions refer to the logical position in the string representing a paragraph. Basically, a paragraph is a string containing unicode characters. The text formatting maintains both values and must be able to convert document coordinates into paragraph positions and vice versa. For example, by clicking the document with a mouse, the appropriate position in the paragraph has to be calculated, enabling the user to modify the paragraph at the chosen position. On the other hand, converting paragraph positions into document coordinates takes place each time the cursor position has to be updated. A combination of both aspects occurs, if the cursorUp (cursorDown) key are pressed. First, the current document position has to be transformed into document coordinates. Next, the y-coordinate is shifted to the line above the current line, and finally the resulting point is transferred back to a paragraph position. This will also be discussed in section 9.3. 2.4. InvalidationAs already mentioned above, for performance reasons formatting information are cached. Changing text, modifying attributes, or moving a paragraph within the document result in the invalidity of these information. The formatting information have to be recalculated. 3. Prerequisites – Where do we start?3.1. Document CoordinatesA paragraph has access to its x- and y- position referring to the physical aspect of a window. (0,0) is the upper left corner of the output window, the default value for the upper left text border on the first page of an document is (1702, 1702). Note that these coordinates do not depend on the current resolution. They are measured in twips, i.e., 1/20 pt. 3.2. Width and Height of the EnvironmentA paragraph has to fit into its environment. If a fixed width is given, a paragraph can make a request for more height, if necessary. If this cannot be granted, the paragraph has to be split. 3.3. Character AttributesUsually, character attributes (e.g., font, color, size...) have start and end values referring to paragraph positions. Each paragraph has an array storing character attributes, which determine, how different words or characters of the paragraph are visualized or printed. 3.4. Paragraph AttributesParagraph attributes (e.g., margins, line spacing, hyphenation...) are associated with a paragraph. These are the default attributes for the whole paragraph. 3.5. Output Device and FontFormatting information refer to a reference device, usually the installed printer. HTML documents require the current window to be the reference device. To calculate line breaks, mainly width and height of words are required. For this, font objects can be used. Font objects store a font family, font size, font style, etc. A font object can be passed to an output device, which returns the width and height of a given word. 3.6. Break IteratorA BreakIterator is used to find possible break positions in a given string. The string and the index of the first character not fitting to the line are handed over to the BreakIterator. If hyphenation is disabled, the returned value is the end of the last word fitting to this line. If hyphenation is enabled, the end of the last syllable fitting to the line can be obtained from the result. 4. Portions - The Basic Concept of Text FormattingStarting point for text formatting is a SwTxtFrm object, which receives calls when user interventions take place or parts of a document have to be repainted. The SwTxtFrm object initiates the construction of a data structure, which efficiently supports the repaint, reformat, and invalidation process. This data structure mainly consists of so-called text portions and is accessible via an SwParaPortion object. A text frame has access to an SwTxtNode object, which basically represents the text string (XubString) and the attribute array of this paragraph (illustration 1). Once it has been generated, the SwParaPortion data structure with the formatting information is stored in a cache memory for efficiency reasons.
An SwParaPortion object itself consists of several further text portions. Lines are represented by SwLineLayout objects, each line consists of different derivatives of the SwLinePortion class (illustration 2). Note, that text portions do not store words or characters. They only represent a formatted part of text. For this, they store their width, height, and the maximum ascend of characters, all referring to document coordinates. They also store the number of characters (length) they are representing. Note, that there are portions with width = 0 and length = 1 (e.g., hole portions used to swallow spaces at an end of line) and portions with width ≠ 0 and length = 0 (e.g., portions used to represent notes). Every portion derives from SwLinePortion, which in turn derives from SwPosSize. The main types of portions and their attributes are introduced in the following sections.
4.1. SwPosSize
4.2. SwLinePortionThis class represents a basic text portion.
4.3. SwTxtPortionThese portions represent parts of the paragraph string. They provide functionality for calculating line breaks with respect to the given environment.
4.4. SwLineLayoutIn addition, this class has an pointer to the next line in the paragraph. It can be regarded as representing one line of text.
4.5. SwParaPortionThis portion represents the paragraph text. The SwRepaint and SwCharRange objects are updated, if the appropriate events are triggered.
4.6. Other PortionsThere is a huge amount of other portions, which serve very special purposes. Among these are portions representing
and many other... Have a look at their specification in the *.hxx files 5. AttributesWithin one paragraph it is (of course) possible to apply different formatting attributes to different parts of the text (illustration 3). The next sections explain the handling of attributes. 5.1. Attribute ArraysEach attribute has a start value, pointing to a position in the paragraph string. Usually attributes also have end values, indicating at which position they become invalid. Portion borders are affected by attribute changes, i.e., a change of attributes always requires the beginning of a new portion. Illustration 4 depicts portion borders and attribute changes with respect to the example given in illustration 3. Note that the shown portions can be smaller than in the illustration, but never overlap with an attribute change. Attributes are organized in an attribute array, sorted by their start value.
5.2. Attribute Handler and Attribute StacksAttributes influence the painting and formatting process. During painting, the portions representing the text to print are traversed, collecting for each portion the attributes being set. These attributes are used to generate a font object, which in turn is responsible for printing the text represented by this portion during output mode. During formatting, the portions are set up and their width, height and number of characters are determined considering the font generated for this portion. For generating the appropriate font for a given set of attributes, an attribute handler is used. An attribute handler consist of a number of attribute stacks, one stack for each kind of attribute. Reaching the start of an attribute during traversing of the attribute array, the attribute is pushed onto the appropriate stack and the current font is changed according to this attribute. When reaching an end of an attribute in the attribute array, the attribute is pushed from its stack and the remaining top attribute on this stack is used to change the font again. The state of the attribute stack collection during the traversal of the text represents the state of the current font. The attribute stacks are initialized with default attributes, which are specified for the whole paragraph. 6. Font ObjectsFont objects are generated during the traversal of the set of portions representing the paragraph. The current font object is attached to the output device and destroyed when it becomes outdated. The hierarchy of different font classes is shown in illustration 5. To take Asian or other languages into consideration, an SwFont object consists of three SwSubFonts (Latin, CJK, and CTL1). The SwFont::nActual field indicates the current script, i.e., the currently active subfont.
Font objects are modified by character attributes. The attribute handler (see section 5.2) changes the current font object for each attribute pushed or popped from the stacks. Font objects are able to calculate the width (in document coordinates) of a given string. This is used for the determination of line breaks and portion sizes. 6.1. The Script Type Data StructureIt is possible, to define different fonts for different scripts, e.g., to have a Times New Roman, 12 pt. font for "Latin" characters, while "Asian" characters are shown using an "Andale UT", 20 pt. font. For this, is is essential to know the ranges of the different script types. The SwScriptInfo class is a data structure maintaining these information. Internally, two arrays are used, one for the next script change, an other for the type of script (Illustration 6).
An SwScriptInfo object is part of each paragraph and has to be updated when entering a new character. Referring to the example in illustration 6, entering a character at position 39 invalidates the array at position 1,2 and 3. A change of script type means necessarily a portion change, since different fonts are used for different scripts types. 7. Attribute IteratorsThere are two associated kinds of objects involved in all processes referring operations on portions (format, paint, cursor positioning):
During one of these processes, the SwTxtFrm object generates an iterator and an info object. Depending on the current action, the iterator can by an SwTxtPaint, an SwTxtFormat, or an SwTxtCursor iterator. These iterators traverse portions of an paragraph, at the same time they search the attribute array for attribute changes. SwTxtInfo objects are used to communicate information between iterators and portions. The SwTxtInfo class is introduced in chapter 8. These are the most frequently used iterator classes: 7.1. SwAttrIterBase class for all iterators.
7.2. SwTxtIterThe SwTxtIter class is derived from SwAttrIter. It can be regarded as an iterator with two objectives: iterating over attributes in the attribute array and iterating over lines of a paragraph.
7.3. SwTxtCursorThis iterator is used for cursor positioning purposes. It is generated by the text frame in case a repositioning of the cursor is necessary. Have a look at section 9.3 for more details.
7.4. SwTxtPainterDuring a repaint event (of an rectangular area), the text frame generates an SwTxtPainter object. The DrawTxtLine method of the painter is called by the text frame for each line intersecting the repaint rectangle. Within this method the SwTxtPainter redirects the painting task to the portions in the current line by calling their paint methods. For this, the information collected from the attribute array are encapsulated in the appropriate SwTxtInfo object and passed over to the portions. In fact, the actual painting is done by font objects, which are called by the info structures. Have a look at section 9.2 for a more detailed view on these iterator.
7.5. SwTxtFormatterEach time a reformatting has to be performed (e.g., insertion/deletion of text) the text frame generates an SwTxtFormatter object. The proceeding is similar to the painting process and will be discussed in detail in section 9.1.
8. Text InformationDifferent tasks require a different set of information. These are the most frequently used information encapsulating classes: 8.1. SwTxtInfoThis is the base class for text information classes.
8.2. SwTxtSizeInfoTxtSizeInfo objects are able to calculate the width of a given string. This is used for calculating line breaks and the number of characters fitting into a portion. A call of the GetTxtSize method is redirected to the current font object.
8.3. SwTxtPaintInfoActually, the TxtPaintInfo objects are not only responsible for encapsulating information for the paint process, in fact they are an active part of the paint process. The DrawText method is called by the portions to be painted and it redirects the painting task to the font.
8.4. SwTxtFormatInfoThe SwTxtFormatInfo class maintains all important information for the formatting process. Besides from this, it calls the external word hyphenation tool.
9. Main Objectives - A closer LookFor easier understanding, the main objectives of text formatting, as mentioned in chapter 2, can be examined independently, although for example, the text formatting process always involves a repaint event and makes it necessary to calculate a new cursor position. The basic operations initiated by the iterators are shown in illustration 7:
The main sections (9.1, 9.2, 9.3) of this chapter represent the main tasks of the text formatting process. 9.1. Text FormattingText formatting is one of the main task for a word processor. Formatting information have to correspond to the attributes defined by the user. The following flow roughly shows the actions triggered from an user intervention to the resulting formatting information.
Illustration 8 shows the corresponding function calls for this procedure.
The following sections give an short introduction to common tasks to be regarded during text formatting. 9.1.1. Line Breaks and the Break IteratorIn section 9.1 the text formatting process has been discussed. The instance responsible for finding suitable line breaks is the break iterator. Breaks can be text delimiters (like spaces, tabs...) or, in hyphenation mode, a hyphenation possibility. User defined soft hyphens are also provided. The process described in this section is located between the 9. and 10. step from section 9.1. The functionality of the break iterator is wrapped in the SwTxtGuess class. The operations performed during text formatting are as follows:
Some actions and results occurring during this process are depicted in illustration 9.
9.1.2. Line Break HandlingDuring text formatting, the SwTxtPortion::Format evaluates the information obtained from an SwTxtGuess object. method. Five different cases are distinguished:
The handling of the first three cases is discussed in section 9.1.1. For example, the fifth case has to be handled, if you insert a word which is wider than a line, and you do not allow hyphenation, or the word does not have a hyphenation position. In this situation, a BreakCut is performed, the word is cut at the end of the current line. The fourth case demonstrates a situation, which requires to break the straight forward formatting direction of the portions. Imagine the following case: Attribute What happens, if this word has to be hyphenated, because the "e" doesn't fit to the current line? The above example consists of two text portions with different character attributes. During the formatting process, the first portion is already appended to the current line. Getting the correct hyphenation position ("Attrib-ute") requires to split the last portion and inserting a hyphenation portion between the parts. Because the last portion has to be formatted again, this is called an underflow event. These are the actions performed in the above case:
9.2. Repaint EventsRepaint events are handled quite similar as format events, apart from the fact, that usually formatting information are already available.
9.3. Cursor PositioningCursor positioning requires the conversion from paragraph positions to document coordinates and vice versa. The main methods for this conversion are:
For example, a paragraph position is converted into a cursor position by executing the following steps:
Both methods are combined, when using the cursorUp (cursorDown) key:
9.3.1. Cursor Positions inside FieldsUsually traveling into fields is not allowed. But there is one exception, when it comes to accessibility. For accessibility it is important to obtain the position of each character inside a paragraph. That includes positions inside fields. A field is represented by one special character in the paragraph string. So it must be possible to specify positions inside a field. This is done by using the SwCrsrMoveState structure defined in sw/inc/crstate.hxx. This structure has a pointer to a SwSpecialPos struc:
So if you want to get the position of the second character inside a field, which has the position 5 in the paragraph string, you simply call the GetCharRect function with the SwPosition encapsulating the string position 5 and pass a SwSpecialPos structure with nCharOfst = 2. This also works for fields with follow fields. A follow field is a part of a field, which doesn't have a representation in the paragraph string because the original field has been split into several pieces (e.g., if there are script changes inside the field). 10. Details on selected Topics10.1. Fly FormattingEverything you put into your document except from plain text or tables is called a fly. Examples are frames or drawing objects. It is a task of the text formatting, to consider the required space for these things, i.e., we insert fly portions into our lines to indicate that this space is reserved for a fly. Intersections of flys and a given rectangle can be determined by the SwTxtFly::GetFrame(SwRect) method. The algorithm for fly positioning is explained with regard to illustration 10, showing the common case, where the wrap option is set to "parallel", i.e., the text is supposed to float around the fly:
Note, that in our example, a line spacing of "double" is set. Two flys are potentially overlapping the text (denoted by dotted rectangles). These are the steps performed for calculating fly positions during text formatting:
Note, that our example would cause endless loops in the formerly explained algorithm. While executing step 2 with the darker gray area, a collision with fly 2 is detected, resulting in two portions for the line, one text portion "this" and one fly portion. A new calculation of the line height has the same result as our first execution of step 1. For this reason, we break our algorithm, if we would start a new loop with an area to scan lying higher (with respect to the y coordinate of the upper border) than the area of the last scan (for not causing an endless loop). The final result is that "this String" is distributed on two lines. 10.2. Kerning PortionsWhen using different scripts in one document, we offer the feature “Apply spacing between different scripts”. This additional space between two text portions representing text in different scripts is realized by inserting a SwKernPortion between them. You can see this in the SwTxtFormatter::BuildPortions function. In order to cover all situations, we have to be able to append or prepend a kerning portion. Most cases are covered by the code to append the kerning portion, but when dealing with fields, it can be easier prepending the kerning portion in front of the current portion. We do not want to interfere this feature with the “Allow hanging punctuation” feature used for Asian languages, see section 10.3. For this, we only add an additional gap between two characters of a different script, if both of them are different from punctuation characters. 10.3. Hanging PunctuationHanging Punctuation is used in some Asian languages. Some characters are allowed to overlap the borders, especially punctuation characters. The characters which are allowed to be hanging characters, are defined as “Not at start of line” in the options dialog. In order to have the break iterator recognize Latin characters as possible hanging punctuation characters for Asian languages, we do this: If a new portion does not fit to the current line and its script is different to the one of the last portion, we temporarily change the language passed over to the break iterator to the language set for the last portion. This way, a Latin dot behind a Japanese text portion would become Japanese and the break iterator would return that it is allowed to have the Latin dot outside the boundaries. 10.4. Text OutputThe WYSIWYG mode is a combination of online and printed layout. The reason for this is that we do not want the result on the screen differ to much from the printed output on one hand, on the outher hand the result on the screen should not totally depend on the selected printer and printer driver. The algorithm for computing output positions for the screen works like this:
We have a special treatment for blanks. Finding a blank during step 2, we let the output position for this blank be the position obtained from the printer during step 1. This allow us to have fixed positions in our output to the screen, compared to the printer. We also consider the previous character during this algorithm. If the last character is a blank, the output position of the current character is its position as it occurs in the kerning array. 10.5. The nDelta Member of SwParaPortionDuring text formatting, we only want to format lines, which have been changed because of an input event. Making changes to a line can influence the whole paragraph because of the introduction of new line breaks. The paragraph has a member of the type SwCharRange, which represents a range which has been changed due to a user interaction. Simply typing a character would result in a range with the current input position and length = 1. The nDelta member of the SwParaPortion is the sum of all added or deleted characters. This value is considered during a reformat process of a paragraph. A value of -2 means that two characters have been deleted from this paragraph. During formatting of the paragraph, we first skip each line, which does not lie inside the SwCharRange. The new length of each line, which is formatted, is compared to its old length. The difference between these two values is subtracted from the nDelta value.If the new end of a line does not anymore lie inside the reformatting range and nDelta equals 0, we have reached a stable situation, we do not have to reformat any following lines. 10.6. Font CachesFont caches are used for faster construction of fonts and faster access to then. 10.6.1. SwFontCacheThe SwFontCache is used for faster construction of a font. The SwFontCache stores SwFontObj objects, which in turn encapsulates an SwFont object. The keys for the cache are attribute sets, the values are the fonts. You need a SwFontAccess object to obtain the appropriate font for a given attribute set. If the SwFontAccess::Get method does not find a font object for the attribute set, it generates a new entry for the cache. 10.6.2. SwFntCacheThe SwFntCache is used to find the appropriate output font for a given font set by the user. The font set by the user does not have to be the font used for the output. It is passed over to the printer, which returns the font, which is used for printing. These two fonts (the user font and the printer font) are compared and the result is the font which is best suited for screen output. Since this is an expensive operation, the result of the comparison is cached. The key for the cache is a font, the result is the font for the screen. For faster access to the cached objects, each font in the cache has a magic number, which points to a position in the array of the stored output fonts. You need to have an SwFntAccess object to access the cache. If the key font you want to ask the cache for does not have a magic number, the key font is compared with all the other key fonts in the cache. 10.7. Drop CapsCalculating drop caps can lead to some difficulties with endless loops, quite similar to the situation described in section 10.1. A drop cap portion is build by the SwTxtFormatter::NewDropCapPortion function. A first guess for the height of the drop cap is made by guessing the line height (which has not been calculated yet, because the line still unformatted) and multiplying it with the number of lines the drop cap should cover. A drop cap portion can consist of several parts, one part for each attribute or script change:
The nLen, pFollow and pFnt fields of the SwDropPortionParts are assigned during the building of the portion. The widths of the drop cap parts are calculated in the SwDropPortion::Format function. We even want to allow different font sizes inside a drop cap. For this we have to calculate a common scaling factor for all parts of the drop cap parts, in order to:
The scaling factor and the common baseline for the drop portion parts are calculated in the SwTxtFormatter::CalcFontSize function (see also illustration 11):
Returning from SwTxtFormatter::CalcFontSize, we can now calculate the widths of the drop portion parts. For each part, the font for the part is set at the SwTxtFormatInfo object, and the text represented by this part is formatted with respect to its font. The sum of the widths is the width of the drop portion.
We continue with the formatting process, until all lines the drop cap should cover are formatted. Then we compare the final size of the lines with the height of the drop cap portion. If it differs, we have to format the drop cap and the lines once more, the new wished height for the drop cap portion is now the size of the lines. This can lead to endless loops, therefore we only allow the drop portion either to grow of shrink continuously. 10.8. SpellcheckingThere are two modes for spell checking: Online spell checking and interactive spell checking. The online mode shows red wave lines under wrong words while typing the text. The interactive mode can be accessed by pressing F7. 10.8.1. Online (Auto) Spell CheckingDuring online mode, a so-called wrong list is built and updated each time the user modifies the text. The wrong list continues words which has been identified as wrong words. The invalidate range for the wrong list is set in the SwTxtFrm::Modify function. This range has to be checked again (SwTxtFrm::_AutoSpell). Each word inside the range is spelled again, wrong words remain in the wrong list, new words are added and others are removed from the wrong list. Also the words for auto completion are collected. Finally a rectangle is returned, which indicates the area of change, in order to have the red wave lines be repainted correctly. 10.8.2. Interactive Spell CheckingThe interactive spell checking (SwTxtNode::Spell) works on a given range in the text. You can specify the range by selecting some text, otherwise the whole text is assumed to be checked. The interactive spell checking comes up with a dialog if a wrong word has been found. If we trigger an interactive spell checking while the online mode is enabled, the interactive spell checking only considers the words listed in the wrong list. Otherwise it checks all words in the given range. 10.9. Vertical FormattingSome languages require a vertical formatting of text, e.g., Chinese or Japanese. For them a vertical text formatting and layout has to be integrated. The basic idea for the text formatting is to swap frames, i.e., the width and height of a frame are swapped. The three main tasks of the text formatting (formatting paragraphs, painting of text and cursor travelling) are performed on swapped frames and afterwards the results are translated back.
The advantage is that most of the code inside the text formatting does not have to be adapted to vertical formatting. There are many functions at the SwTxtFrm class to do the conversion from horizontal to vertical formatting. As an example consider the calculation of the cursor position. First the frame which currently contains the cursor is determined. Before calculating the correct screen coordines of the cursor inside the text frame, the frame is swapped. Now we assume that we deal with a common horizontally formatted text frame. The usual functions for calculating the cursor position are called and finally the swapped frame and the resulting rectangle for the cursor position are rotated back. 10.10. Asian Grid ModeIn some Asian countries, people use a grid layout for writing. Usually a page has 10 rows and 20 columns.Above (or optional below) the main cells there is a line reserved for ruby characters. An Asian character should snap to the grid, i.e., it is centered inside a cell. An exception are punctuation characters, which are aligned to the right or left inside a cell. The main funtionality is provided inside the txtnode/fntcache.cxx file, especially in the GetTxtSize(), GetCrsrOfst() and DrawText() functions. The GetTxtSize function returns only multiples of a cell width as the widths of some Asian text. The DrawText() function centeres the characters inside their cells, by considering their real width and height.
Western text should be centered inside as many cells as are needed for them. This is achieved by inserting SwKernPortions between Asian and Western portions (SwTxtFormatter::BuildPortions). First a new SwKernPortions with width = 0 is inserted and a pointer to it is stored before formatting a western text segment. When the end of the western text segment is reached, another SwKernPortion is appended at the end of the western text. The number of required grid cells for the western text is determined and the remaining space inside these cells is distributed to the SwKernPortions in front of and behind the western text. Attention: Due to an underflow event the first SwKernPortion could have been deleted. 10.11. Alphabetic Index SortingIndices for an alphabetic index can be inserted via the Insert – Indexes and Tables – Entry dialog. Some languages require additional information, how the indices should be sorted. Asian languages for example use addition phonetic strings to be sorted. Each entry is represented by an SwTOXIndex object. Illustration 14 shows the class model for the main components of an alphabetic index. The SwTOXInternational class has an Compare function, which compares two SwTOXIndex objects considering language specific rules.
11. Files in the Star Writer Project11.1. inc/atrhndl.hxxThe attribute handler, which maintains the collection of attribute stacks used to change font objects is specified here (see section 5.2).
11.2. inc/drawfont.hxxThe script type data structure (see section 6.1) is defined here.
11.3. text/inftxt.hxxThis file contains specifications for classes encapsulating information required during the formatting/painting/cursor positioning processes (see chapter 8).
11.4. text/itratr.hxxThe base class of all iterators (see chapter 7):
11.5. text/itrform2.hxxIterator class for text formatting purposes (see chapter 7 and section 9.1).
11.6. text/itrpaint.hxxIterator class controlling the painting process (see chapter 7 and section 9.2).
11.7. text/itrtxt.hxxSome other iterator classes for more special operations.
11.8. text/pordrop.hxxSpecial portion used for initials.
11.9. text/porexp.hxxExpanding portions for fields, blanks, and notes.
11.10. text/porfld.hxxDifferent kinds of field portions are defined here.
11.11. text/porfly.hxxPortions used for frames.
11.12. text/porfnt.hxxFootnote portions and portions required for widows/orphans handling are defined here.
11.13. text/porhyph.hxxPortions introduced during hyphenation are defined in the file.
11.14. text/porlay.hxxGeneral text structuring portions, see also chapter 4.
11.15. text/porlin.hxxAbstract base class for all portions.
11.16. text/pormulti.hxxPortions used for multi line style.
11.17. text/porref.hxxReferences are represented by this portions.
11.18. text/portab.hxxPortions used for different types of tabulators.
11.19. text/portox.hxxThese portions are used for tables of contents.
11.20. text/portxt.hxxMost frequently simple text portions are used.
11.21. text/possize.hxxBase class of all portions, stores width and height of an portion (in document coordinates).
1Complex Text Layout: Term for languages whose writing system needs complex transformations in order to visualize the text stored in memory. Examples are bidirectional scripts like Arabic or Hebrew, languages using clustered characters like Thai or languages with characters, whose visual representation depends on their context (e.g., ligatures). |
The free and open productivity suite
- Search
-
Change Language
OpenOffice.org is available in many different languages. You might want to visit the webpages created by one of our many native language communities.
-
Log In
