Issue 113922

Summary: Line witdh are too large in printed handout
Product: Impress Reporter: bobrazowski <educlos>
Component: printingAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: clippka, issues
Version: OOo 3.3 Beta 1Keywords: regression
Target Milestone: OOo 3.3   
Hardware: All   
OS: Windows XP   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 111112    
Description Flags
Openoffice presentation example
Printed handout with OO32
Printed pdf with OO 3.3 beta1
Patch to solve the task none

Description bobrazowski 2010-08-16 18:38:09 UTC
When I print handouts (3 slide per page for example), line width of graphics are
really too large.

Examples joined :
openoffice file : OO33_examplehandout.odp
pdf created with OO 3.3beta : OO32_examplehandout.pdf
pdf created with OO 3.2 : OO32_examplehandout.pdf
Comment 1 bobrazowski 2010-08-16 18:40:56 UTC
Created attachment 71133 [details]
Openoffice presentation example
Comment 2 bobrazowski 2010-08-16 18:42:01 UTC
Created attachment 71134 [details]
Printed handout with OO32
Comment 3 bobrazowski 2010-08-16 18:42:47 UTC
Created attachment 71135 [details]
Printed pdf with OO 3.3 beta1
Comment 4 wolframgarten 2010-08-17 08:16:06 UTC
Reproducible. Reassigned.
Comment 5 clippka 2010-08-18 17:57:54 UTC
The problem is that the line width is not transformed. So when printed in a page
preview shape the line width is the same as it would be if the contents of the
page preview shape is printed to the whole page.

I think the problem is VclProcessor2D::RenderPolygonStrokePrimitive2D which
transforms its geogetry but not its fLineWidth. I tried to solve the issue with
the following code but had no success

				basegfx::B2DPoint aLineWidthPoint( fLineWidth, fLineWidth );
				fLineWidth = (aLineWidthPoint *= maCurrentTransformation).getX();

cl->aw: I think you have to take over
Comment 6 sp908 2010-08-25 10:39:20 UTC
I just stumbled about the same problem and was about to submit a new issue when
I found this. It also seems to me that line widths are not scaled down properly
when the slide is reduced in size to be printed in handout format. In my case,
it would make it impossible for me to use the new version, since the printed
handouts for lectures would be illegible.
Comment 7 Armin Le Grand 2010-09-06 10:48:24 UTC
AW: Yes, i have to. This is a non-trivial problem. Well, mathematically it is
(and CL's suggestion goes in the right direction, even when not optimally

Basic problem is that LineWidth (and other attributes) are historically defined
to NOT be scaled with object transformation, so that when resizing the shape the
LineWidth stays the same. This means that by purpose the object transformation
is not applied to the attribute (and others). This was hard to emulate when
changing paint to transformation based (would have been easier the other way
around) and leads to problems in various directions.

I already checked other programs and what they do. In general, they use some
switch(es) to define e.g. in this case if when resizing the object, the
LineWidth should be scaled (and e.g. text size where we have requests for for a
while). I would suggest to add a 'Apply to attributes' switch in the UI
somewhere, default deactivated to stay compatible. But this is just the
interactive part of the problem and i will file a new task for this...

In this concrete case using primitives will allow to find some kind of solution,
but it will not be easy. In principle it will be necessary to keep a object and
view transformation seperated and to apply the view transformation always to
Comment 8 Armin Le Grand 2010-09-06 10:54:04 UTC
AW: Submitted #i114341# for f'up of UI possibilities...
Comment 9 Armin Le Grand 2010-09-06 15:37:27 UTC
AW: OOps, i have overlooked that everything works well in DrawingLayer, it's a
problem with PRINTED handouts. That changes everything. All the mechanisms in
Drawinglayer i talked about are in place and working.

When printing, a Metafile gets created. Thus, (again) one of the many, many
problems with Metafile contents. Guess: The LineWidth is not yet transformed
when the FatLine data is added. Also caused through adding FatLines at all to
Metafiles due to tasks with too big Metafiles when the fille dpolygon geometry
was added. Thus, a follow-up of 10 years not administering the Metafile actions
and data ... Sigh :-(

Looking at the Metafile case...
Comment 10 Armin Le Grand 2010-09-06 16:24:48 UTC
AW: Indeed, in VclMetafileProcessor2D::processBasePrimitive2D in case
PRIMITIVE2D_ID_POLYGONSTROKEPRIMITIVE2D the LineWidth is not transformed at all,
that's just missing. Adding shows the desired effect.
This makes the fix simple and safe.
BTW: The same error must also be in printed notes, just less obvious since the
PagePreview object is less scaled against the full page...

AW: Preparing patch...
Comment 11 bobrazowski 2010-09-06 16:51:04 UTC
Good Job !
Thanks for all !
Comment 12 Armin Le Grand 2010-09-06 17:43:21 UTC
Created attachment 71588 [details]
Patch to solve the task
Comment 13 Armin Le Grand 2010-09-06 17:43:57 UTC
AW: Added patch. Looking for CWS and target...
Comment 14 wolframgarten 2010-09-07 12:06:34 UTC
Keyword added.
Comment 15 wolframgarten 2010-09-07 12:07:03 UTC
Target adapted.
Comment 16 Armin Le Grand 2010-09-07 14:46:56 UTC
AW: Added to CWS ooo33gsl08, added patch, built drawinglayer and install set,
tested with printing to file. Works as expechted. Commited change. Done.
Comment 17 Olaf Felka 2010-09-07 15:02:37 UTC
Added to the meta issue
Comment 18 Armin Le Grand 2010-09-09 17:52:20 UTC
AW: checked in CWS ooo33gsl08, all working.
AW->WG: Please review when CWS is reqdy for QA.
Comment 19 wolframgarten 2010-09-13 10:39:12 UTC
Verified in CWS.