incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 118643] Unexpected behaviour with Shapes → Intersect
Date Mon, 06 Feb 2012 12:48:55 GMT
https://issues.apache.org/ooo/show_bug.cgi?id=118643

Armin Le Grand <Armin.Le.Grand@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Armin.Le.Grand@me.com

--- Comment #1 from Armin Le Grand <Armin.Le.Grand@me.com> 2012-02-06 12:48:55 UTC ---
ALG: Intersection is a geometrical operation on two polygon shapes, so the
bitmap you try to work with gets converted to a polygon object (context menu,
convert to contour). These two polygon shapes then get intersected, leading to
the ellipse result.
The intersection always uses the fill/line style of the deepest object, in this
case the converted polygon with fill style bitmap. Thus, the result gets the
line/fill style copied from that, so the result ellipse will just get the fill
style of the deepest object. This is designed to work with any fill style, e.g.
color and/or others.
This function is not intended to cut portions out of a bitmap, though. It works
as intended, but you make a nice suggestion how this feature could be extended.
It would be necessary to cut bitmap contents to the result geometry. A big
caveat is that the result geometry could not only be smaller and inside the
source image (which will make clipping simple and logic), but also be much
bigger and empty (shapes merge). How should the bitmap meeded as a result be
extended?

I suggest to make this task a feature request.

-- 
Configure bugmail: https://issues.apache.org/ooo/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Mime
View raw message