https://issues.apache.org/ooo/show_bug.cgi?id=124002
Armin Le Grand <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |ACCEPTED Summary|DrawObjects filled with |DrawObjects filled with |metafile show comtent in |metafile show content in |wrong size |wrong size --- Comment #4 from Armin Le Grand <[email protected]> --- 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... -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes.
