Issue 124002 - DrawObjects filled with metafile show content in wrong size
Summary: DrawObjects filled with metafile show content in wrong size
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: 4.1.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact:
Depends on:
Reported: 2014-01-08 17:31 UTC by Armin Le Grand
Modified: 2014-01-09 16:12 UTC (History)
2 users (show)

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

Sample Document with Screenshots (154.35 KB, application/
2014-01-09 06:13 UTC, Rainer Bielefeld
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2014-01-08 17:31:02 UTC
DrawObjects with a metafile (vector graphic) filling show that conent wrongly scaled in writer. To reproduce you need to create a metafile-filled DrawObject and insert it to Writer. To do so:

- open draw, create a ellipse with dimensions 4cm x 4cm
- context menu, convert to metafile
- create a rectangle with 6cm x 6cm
- Drag&Drop the metafile object to the rectangle -> filled now with metafile
- Copy/Paste rectangle to writer -> fill looks different

Probably has to do with the fact that writer internally uses twips not 100thmm.
Comment 1 Armin Le Grand 2014-01-08 17:31:23 UTC
grepping, preparing to work on it...
Comment 2 Armin Le Grand 2014-01-08 17:33:10 UTC
one hint: when Drag&Drop the ellipse to the rectangle, hold CTRL and SHIFT pressed to indicate that the fill style shall be changed.
Comment 3 Armin Le Grand 2014-01-08 17:49:22 UTC
Tried the same with SVG filled objects, also need to check since also looks not initially correct. Probably the same problem.
Comment 4 Armin Le Grand 2014-01-08 20:54:49 UTC
There is already correct code in createNewSdrFillGraphicAttribute which takes an evtl. different MapMode into account. It sets the PrefSize for the graphic accordingly, correctly adapted. This works for bitmap-based graphics since these have their real size information exactly there, but not for metafiles.
For metafiles there was #i100357# for which the metafile-to-primitive decomposer adds a clip region to avoid errors, thus the result is not scaled as intended but clipped. This has to stay since there are metafiles which will need clipping.

One alternative would be to really change the metafile size by applying a scale to the metafile itself. This would work (in most cases, there may be metafile parts which react bad on this) but is expensive to scale that every time. That scalecopies all actions and tries to scale them accordingly.

As an alternative createNewSdrFillGraphicAttribute could not adapt/set the PrefSize at the graphic at all, but alternatively define an extra scaling for the graphic content (also for bitmaps) and add it to the created SdrFillGraphicAttribute. All decompositions from there on would have to be adapted.

Thinking about it...
Comment 5 Armin Le Grand 2014-01-08 20:56:16 UTC
There may also be the alternative to add a LogiocToLogic map action in front of the metafile, but this still means to copy all actions since the metafile and it's list of actions is not refcounted in any way.
Comment 6 Armin Le Grand 2014-01-09 02:24:40 UTC
Experimented with not setting the PrefSize but having a local LogicSize in drawinglazer, not sure yet if this works...
Comment 7 Rainer Bielefeld 2014-01-09 06:13:32 UTC
Created attachment 82245 [details]
Sample Document with Screenshots

Reproducible with server installation of "AOO 4.1.0-Dev – English  UI / English locale - [AOO410m1(Build:9750)  -  Rev. 1554003 - 2014-01-06]" on German WIN7 Home Premium (64bit)", own separate user profile.

Copy / Paste to Calc not affected
Comment 8 Armin Le Grand 2014-01-09 15:46:21 UTC
Thanks Rainer! SC is not affected since it works on 1/100th mm internally as draw/impress do while Writer works on twips internally.

Checked further, problem is that indeed SetPrefSize should not be used at all in the rendering stack (keep the graphic as unchanged as possible). Still in further decomposing, the logical size of the graphic is needed, evtl. adapted to target measurement base.
Thus a GraphicLogicSize is now used instead of GetPrefSize inside the rendering stack. That works well and is evtl. usable for other future tasks, too. Checked this change with all combinations of adding graphics to Writer directly, copy/pasting to writer, all content possibilities as bitmap, metafile and SVG.
Comment 9 Armin Le Grand 2014-01-09 15:47:52 UTC
Also checked print and PDFexport, all looks good. Preparing commit...
Comment 10 SVN Robot 2014-01-09 15:58:41 UTC
"alg" committed SVN revision 1556850 into trunk:
i124002 use own logical size for graphics, do not adapt PrefSize of these in ...
Comment 11 Armin Le Grand 2014-01-09 16:12:45 UTC
Okay, comitted, done.