Issue 114512

Summary:	Overline, underline not working correctly
Product:	Draw	Reporter:	groucho266
Component:	viewing	Assignee:	AOO issues mailing list <issues>
Status:	CONFIRMED ---	QA Contact:
Severity:	Trivial
Priority:	P3	CC:	issues
Version:	DEV300m86
Target Milestone:	---
Hardware:	All
OS:	All
Issue Type:	DEFECT	Latest Confirmation in:	---
Developer Difficulty:	---

Description groucho266 2010-09-15 09:17:02 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.

Comment 1 Armin Le Grand 2010-09-15 11:33:23 UTC

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.

Comment 2 Martin Hollmichel 2011-03-16 09:44:06 UTC

set target to 3.x since not release relevant for 3.4.

Comment 3 Marcus 2017-05-20 10:48:08 UTC

Reset assigne to the default "issues@openoffice.apache.org".