|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | DrawObjects filled with metafile show content in wrong size | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Writer | Reporter: | Armin Le Grand <Armin.Le.Grand> | ||||
| Component: | editing | Assignee: | Armin Le Grand <Armin.Le.Grand> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | Normal | ||||||
| Priority: | P3 | CC: | issues, rainerbielefeld_ooo_qa | ||||
| Version: | 4.1.0-dev | ||||||
| Target Milestone: | 4.1.0 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
| Developer Difficulty: | --- | ||||||
| Attachments: |
|
||||||
|
Description
Armin Le Grand
2014-01-08 17:31:02 UTC
grepping, preparing to work on it... one hint: when Drag&Drop the ellipse to the rectangle, hold CTRL and SHIFT pressed to indicate that the fill style shall be changed. Tried the same with SVG filled objects, also need to check since also looks not initially correct. Probably the same problem. 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... 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. Experimented with not setting the PrefSize but having a local LogicSize in drawinglazer, not sure yet if this works... 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
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. Also checked print and PDFexport, all looks good. Preparing commit... "alg" committed SVN revision 1556850 into trunk: i124002 use own logical size for graphics, do not adapt PrefSize of these in ... Okay, comitted, done. |