Apache OpenOffice (AOO) Bugzilla – Issue 114512
Overline, underline not working correctly
Last modified: 2017-05-20 10:48:08 UTC
When a decorated text primitive with visible overline or underline is decomposed into primitives the primitives that represent the overline or underline are not spanning the entire text width. It looks like a discrete number of (wave) line parts is painted and that that number is rounded down. Side node 1: VclPixelProcessor2D renders overlines and underlines without the decomposition. The result looks quite different from the rendering of the decomposition, especially at higher zoom levels. Side node 2: Wavy lines from adjacent characters would not meet properly even when the missing cycle were painted. The wavy line of the second character would need an offset to do that.
AW: This is known. Problem is that VCL paints the Wavelines View-dependent (Zoom factor) in three hardcoded scale steps (performance reasons?). This cannot be modeled using a single geometric waveline as decomposition. Thus, the currently used decomposition tries to get as close to the current VCL behaviour as possible. I decided it to be over-estimated to create a view-dependent primitive decomposition just to mimic an old optimization in VCL. In general the text decorations which are hardcoded in VCL text rendering are hard to extract from there and are all view-dependent (zoom factor, internal Font scale) nore or less. I spent a lot of work already (asking HDU, too) to get as close as possible. Due to VCL behaviour decomposed text decorations cannot be expected to be exactly identical to VCL text decoration rendering. Also the wavelines start newly at every new waveline startpoint, also in old VCL. What may need to be done is to split wavelines in a way to add a start offset, but this is specific to processors which have to split text portions to smaller parts. When e.g. the TextDecoratedPortionPrimitive2D gets splitted by a processor to single complex chars, the TextDecoratedPortionPrimitive2D decomposition cannot have the needed knowledge anymore. Thus, the processor has to do that at splitting time. There is nothing more the TextDecoratedPortionPrimitive2D could currently do. Maybe the more common solution to geometrically split evtl. contained text decorations (by clipping the decomposed polygons) would be better if needed. Also for simple under/overline fat lines it is not guaranteed that painting single chars looks the same as painting the whole unsplitted text portion (all splitted decorations correctly overlapping)and the same is true for VCL, too, FYI. What i need to check though is the 'not spanning the entire text width'. AFAIR VCL does the same, but i will check that.
set target to 3.x since not release relevant for 3.4.
Reset assigne to the default "issues@openoffice.apache.org".