Issue 113922

Created attachment 71133 [details]
Openoffice presentation example

Created attachment 71134 [details]
Printed handout with OO32

Created attachment 71135 [details]
Printed pdf with OO 3.3 beta1

Reproducible. Reassigned.

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

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.

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
formulated).

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
attibutes.

AW: Submitted #i114341# for f'up of UI possibilities...

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...

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...

Good Job !
Thanks for all !

Created attachment 71588 [details]
Patch to solve the task

AW: Added patch. Looking for CWS and target...

Keyword added.

Target adapted.

AW: Added to CWS ooo33gsl08, added patch, built drawinglayer and install set,
tested with printing to file. Works as expechted. Commited change. Done.

Added to the meta issue

AW: checked in CWS ooo33gsl08, all working.
AW->WG: Please review when CWS is reqdy for QA.

Verified in CWS.