Issue 96474 - Underline rendering faults in new drawing layer
Summary: Underline rendering faults in new drawing layer
Status: CLOSED FIXED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: DEV300m35
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@gsl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-23 12:47 UTC by martinwhitaker
Modified: 2009-02-26 09:54 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Drawing used to demonstrate problems (10.09 KB, application/vnd.oasis.opendocument.graphics)
2008-11-23 12:49 UTC, martinwhitaker
no flags Details
UNO application used to create document (for information only) (11.37 KB, text/plain)
2008-11-23 12:51 UTC, martinwhitaker
no flags Details
Screenshot when rendered by new drawing layer (83.76 KB, image/png)
2008-11-23 12:52 UTC, martinwhitaker
no flags Details
Screenshot when rendered by VCL (92.06 KB, image/png)
2008-11-23 12:53 UTC, martinwhitaker
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description martinwhitaker 2008-11-23 12:47:39 UTC
There are a number of problems with the rendering of underlined text in the new
drawing layer. Using the attached file example1.odg (which was created using the
attached Underline.java), I've taken two screenshots. The first screenshot,
example1-normal.png, shows the text being rendered by the new drawing layer. The
second screenshot, example1-edit.png, shows the text being rendered by VCL
(which happens when the text box is in edit mode). The following problems can be
seen:

1) When rendered by VCL, all the different line styles are visually correct.
When rendered by the new drawing layer, the detail is lost.

2) In the last line, the underline colour is set to black. When rendered by the
new drawing layer, it is displayed in red.

3) The last line contains the text "Single and Double". When rendered by the new
drawing layer, the "and" is not displayed.
Comment 1 martinwhitaker 2008-11-23 12:49:10 UTC
Created attachment 58226 [details]
Drawing used to demonstrate problems
Comment 2 martinwhitaker 2008-11-23 12:51:57 UTC
Created attachment 58227 [details]
UNO application used to create document (for information only)
Comment 3 martinwhitaker 2008-11-23 12:52:43 UTC
Created attachment 58228 [details]
Screenshot when rendered by new drawing layer
Comment 4 martinwhitaker 2008-11-23 12:53:30 UTC
Created attachment 58229 [details]
Screenshot when rendered by VCL
Comment 5 philipp.lohmann 2008-11-24 10:30:27 UTC
pl->hdu,aw: please have a look
Comment 6 hdu@apache.org 2009-01-08 13:22:42 UTC
I wrote the original code for supporting the underlining features in the new drawing layer, but AW was the 
last one who changed that code... I"ll look into it (@aw: feel free to take this issue)
Comment 7 Armin Le Grand 2009-01-08 15:29:09 UTC
AW: The good news is: There is a flag to decide if either (a) the decomposition
is being used to render only simple text and the decorations as grapics
(currently the default to test and find exactly such problems) or (b) to use all
those decoration settings and paint the Text in VCL. So, for timeframe concerns,
it is always possible to change this on the fly for 3.1 if time is tight.
Of course it is much better to fix the single issues; this is the path to get
rid of the need to support all that decorations in the future in neither VCL nor
other renderers which will come along.
So this issues should be fixed. HDU did the original decomposition code for
this, so he would evtl. be faster with it. OTOH we all know that he has severe
time constraints for 3.1 with the arabic stuff.

HDU...?
Comment 8 Armin Le Grand 2009-01-08 15:34:50 UTC
AW->martinwhitaker: Thanks for checking this out, we need people testing the new
stuff!
I have a question, though. Have You zoomed into the new DrawingLayer display?
Since the decorations are now drawn using polygons, maybe they are just too
close positioned (e.g. at the dotted line one) and graphically interfere,
despite being geometrically correct...?
Comment 9 martinwhitaker 2009-01-08 20:27:35 UTC
martinwhitaker->AW: Regarding item (1) in my list of problems, yes, when zoomed
in or when the drawing is printed it can be seen that the line styles are
geometrically correct - this is a problem only with screen rendering. But these
days I rarely print documents I want to read (and I know I'm not alone in this)
so I do consider this a serious issue - and it will be even more so when the new
drawing layer gets used for the Impress slideshow mode.

I guess what's needed is something that adjusts the geometry for low resolution
rendering - similar to the hinting techniques used in font rendering.
Comment 10 martinwhitaker 2009-01-08 20:29:53 UTC
I've just noticed that item (2) in my list only occurs when the text is created
by running the Java application - when saved to file and reloaded the underline
is rendered in the correct colour.
Comment 11 Armin Le Grand 2009-01-09 11:57:48 UTC
AW->martinwhitaker: Yes, this is a serious issue, but visualisation at discrete
pixel level always has it's caveats :-)

AW->HDU: I think the Problem will be solved with DEV300 m39 (AntiAliasing for
all Drawinglayer objects), so visualisation should increase drastically. You may
already check with Your Mac-version. The good news is that the general
decompositions for text decorations seem to be indeed correct. Visualisation is
another task.

So, for Point (1) we need to:
- When AAed (the default) do nothing
- When not AAed: do not use the decomposition, but continue to use VCLs
FontRendering

And we need to check this when DEV300 m39 is available.

AW->martinwhitaker: For item (2) not occurring after load/save: I think You
should then make a separate task for 'error when creating text using ....'

AW: So, Item (3) still happens...? All in all,, i guess this task is for me and
i will need to take a look when i have a CWS based on DEV300 m29 myself.
Changing owner...
Comment 12 Armin Le Grand 2009-01-14 11:50:28 UTC
AW: Accepting, adding note wait for DEV300m29
Comment 13 Armin Le Grand 2009-01-16 14:54:16 UTC
AW: Changed target
Comment 14 Armin Le Grand 2009-01-22 15:42:11 UTC
AW: Indeed, AAis better. Checked the flag for fallback to VCL rendering, this is
available. Started to compare.

Wavelines: There is no way to really make these the same as in VCL since VCL
kind of 'fakes' them by simple, resolution-dependent (i think three rough steps)
line painting. The decomposition is more precise and will e.g. use a line width
for the waveline where VCL falls back to hairline (probably historically due to
speed concerns). This makes setting the wavelength (which is always the same in
VCL in each rough step) impossible. Anyways, i optimized the wave's height and
use a 2.0times relative wavelength to get a smooth wave. Also adapted the wave
dustance for double wave, this was really wrong.

Adapted the double line distance a little bit, too.

This is all to correct the decomposition of the TextDecoratedPortionPrimitive2D.
Each renderer may handle it directly and add some kind of hinting here. For 3.1
i will use the VCL fallback for pixel devices (VDev and Window), so we will use
the VCL-FontRendering Hinting, but have a good graphic quality for higher-res
devices. Testing to do that...
Comment 15 Armin Le Grand 2009-01-22 16:17:42 UTC
AW: Works as expected. In the VCL renderer i opt to use VCL direct text
rendering with line hinting, for AA and non-AA as default. The decompositions
will be used by very simple renderers and for object decomposition (advanced
geometric processing).
Doing some more tests...
Comment 16 Armin Le Grand 2009-01-22 17:20:10 UTC
AW: Looking for the lost word in the last line. Indeed, the break iterator in
TextDecoratedPortionPrimitive2D::impSplitSingleWords does lose this word.
getWordBoundary() with 6 as start gives (0,6) as word bound which is the first
word in the string again. Asking ER for his
::com::sun::star::i18n::XBreakIterator knowledge...
Comment 17 Armin Le Grand 2009-01-23 12:22:15 UTC
AW: Identified with the help of FME (thanks!). The
com::sun::star::i18n::XBreakIterator may choose the previous word (if one
exists) when calling getWordBoundary when the start position is on a space. E.g.
with the current string (the last in the example) and the 2nd word: Char 6 is a
space, and getWordBoundary starts there for the 2nd TextPortion of the string
(it's already in three portions due to the first word and the last having
different attributes, e.g underlined). The call gives back (0,6= as word
boundary which is the previous word. In that case, the break iterator needs to
be used again and forced to look at the next position (7 in this case). Doing
some more tests...

So, (1) is solved, (3) is solved, too. For (2), another task should be generated
if this only happens over API creation.
Comment 18 Armin Le Grand 2009-01-23 13:01:43 UTC
AW: Checked in, done for (1) and (3).
AW->martinwhitaker: Please file another task for (2) since it only happens for
the API usage. I will set this task to fixed.
Comment 19 martinwhitaker 2009-01-23 20:26:59 UTC
Created issue #98419 for problem (2) as requested.
Comment 20 Armin Le Grand 2009-01-30 09:48:20 UTC
AW->WG: Please review. (1) and (3) solved with this task, #i98419# exists for (2)
Comment 21 wolframgarten 2009-01-30 12:28:10 UTC
Verified in CWS.
Comment 22 wolframgarten 2009-02-26 09:54:24 UTC
Tested in OOO310_m3. Closed.