Created attachment 19350 [details]
bugdoc

Can you please attach a step by step desscription of what to do with your
attachment? Thanks in advance.

They are a same graphic in different format.
You can open triangle.ood derectly.
Or you can use an flat filter to import "flat format.food".
Or you can use the svg xslt filter attached to i2497 to import triangle.svg.
According to their declare, they should look like "excepted look like.png" I think.
But OOo move all shapes to the topleft of the page.
I can resolve it by remove this line:
http://so-doc.germany.sun.com:8080/lxr/source/svx/source/svdraw/svdopath.cxx?v=SRC680.m62#3322

But I think it also can be releated to this line:
http://so-doc.germany.sun.com:8080/lxr/source/svx/source/svdraw/svdopath.cxx?v=SRC680.m62#3378

Reassigned to Sven. Can you have a look at this please ? Thanks.

Hello, I checked your triangle.oop document and find out that the shape is
positioned via svg:x and svg:y attribute at (0/0), so there is nothing wrong
with the code you mentioned.

Here an extraction of your the file:
<draw:polygon draw:style-name="gr1" svg:viewBox="29200 15600 14200 13900"
svg:x="0cm" svg:y="0cm" svg:width="14.0272cm" svg:height="13.7297cm"
draw:points="33536.480,17625.640 31209.660,27493.050 41425.720,23359.360
33536.480,17625.640 "/>

If you have any further problems, then please take a look at the specification
for the svg:path element.

I known the specification, but suppose I have a polygon like this:

<draw:polygon draw:style-name="gr1" svg:viewBox="0 0 100 100"
svg:x="0cm" svg:y="0cm" svg:width="14.0272cm" svg:height="13.7297cm"
draw:points="30,30 70,30 50,70"/>

Where the polygon should be? I suggest since we had define a viewBox, we had
better to defer to it.

To make it clean. I mean
The following two polygons should not be treat as the same one:
<draw:polygon draw:style-name="gr1" svg:viewBox="0 0 100 100"
svg:x="0cm" svg:y="0cm" svg:width="14.0272cm" svg:height="13.7297cm"
draw:points="30,30 70,30 50,70"/>
<draw:polygon draw:style-name="gr1" svg:viewBox="0 0 100 100"
svg:x="0cm" svg:y="0cm" svg:width="14.0272cm" svg:height="13.7297cm"
draw:points="0,0 40,0 20,40"/>

sj->windly: Yes, you are right, in my understanding the poylgon points have to
be scaled to the ViewBox first and then to the size of the corresponding
position/shape.

Nothing of them is done yet, the size of the viewbox and also the size of the
shape does not matter, instead the points of the polygon itself makes up the
destination position/size of the shape.

To precise this, the XML export of OOo is creating a correct Polygon shape, only
the import does not pay attention to ViewBox and Size/Pos of a shape, this has
to be fixed.

(As a workaround to create polygon objects that can be read properly by the
current and future OOo versions, the Polygon points and viewBox should be in
absolute coordinates, the position and size of the shape as intended)

SJ->CL: This is a XML import propblem, can you please take over.

I will fix it in wordmlfilter01

start

.

Created attachment 20602 [details]
wordml format bug doc

The reason is that aMatrix3D is ignored here
http://so-doc.germany.sun.com:8080/lxr/source/svx/source/unodraw/unoshape.cxx?v=SRC680.m62#1669

fixed in wordmlfilter01

reopen to reassign

assign to qa

fixed in wordmlfilter01

seen good in cws wordmlfilter01
could not verify this against an older SO version, because we could not display this 
objects. but i verified this against ms-office and the file looks equal.
set to verified

seen good in src680_m76 closing ->

fixed but failr

Created attachment 22690 [details]
polygon to (0,0) is only needed when we are doing exporting

Hi,Christian
  Could you please have a look at the last patch I had attathed?
  
Thanks

Armin, can you please have an in depth look into this patch?

As I understand the patch the path is now written without translation, so what
with existing files, are they imported incorrectly?

windly, do not integrate this patch without the aproval from armin and me, this
is a very delicate piece of code.

NOTE TO QA: If this bug is ever to be verified, do extensive testing of loading
and saving of shapes in all applications and with current and past xml formats!

In svx/source/svdraw/svdopath.cxx, aRect is calculated from rPolyPolygon at
runtime. And the points in rPolyPolygon are the absolute coordinates. So when
you draw a polygon,you get a point lists, such as this:
  1000,1000 2000,3000 3000,2000 then your aRect={1cm,1cm,3cm,3cm}. We cann't
save them out directly, because when save to files the points should be in
opposite coordinates defined by viewbox. So we need a
rPolyPolygon.Move(-aRectangle.Left(), -aRectangle.Top()). But currently we call
rPolyPolygon.Move in SdrPathObj::TRGetBaseGeometry which will be called at both
import and export time. The result is when you import a shape with this points
(1000,1000 2000,3000 3000,2000), you will get a (0,0 1000,2000 2000,1000), its
moved to the topleft.
In this patch I move the justify code to SvxShapePolyPolygon::getPropertyValue
which will be called only at export time. Thus we can keep the points as them
should be at import time.

AW: I will investigate.
First thing: When OOo/SO is exporting a polygon, it always creates fitting pairs
of svg:width, svg:height, svg:viewBox and draw:points. E.g. a triangle at pos
(2,2) and with width and height of (5,5) creates:
    svg:width="5cm" svg:height="5cm" 
    svg:x="2.xxcm" svg:y="2.yycm" 
    svg:viewBox="0 0 5501 5001" 
    draw:points="0,0 5500,0 0,5000"
(the xx and yy is the page offset to the page frame). So, the polygon is
unrotated, unsheared and untranslated, but scaled. The ViewBox just describes
the polygon dimensions. That's how all OOo/SO created files look.
Now for the import...

AW: Anonther save note: When saving a rotated or skewed object, the svg:x/svg:y
is left out and an draw:transform containing the translation is generated. The
svg:width/svg:height, svg:viewBox and draw:points always stays the same for the
same triangle. In principle, the svg:viewBox is not necessary for export.
AW: Now for the import, looking at the code in XMLOFF...

AW: Okay, 
- ObjectSize is inited with viewBox width/height, if svg:width/svg:height is not
zero, it will replace ObjectSize.
- ObjectPosition is inited by viewBox:x,y
- bool bScale is true, if ObjectSize != viewBox:width/height
- bool bTranslate is true, if viewBox:x,y != 0L
- xIn: point from draw:points
- xOut: point for returing pointSequence

xOut = ObjectPos.x + (((xIn - viewBox:x) * ObjectSize.width)/viewBox.width)
yOut = ObjectPos.y + (((yIn - viewBox:y) * ObjectSize.height)/viewBox.height)

That poly is the feeded to SdrPathObj::TRSetBaseGeometry.

AW: After that, a transformation is prepared with scaling of
svg:width/svg:height and translation of svg:x/svg:y (if exists). That is then
applied to the object using SdrPathObj::TRSetBaseGeometry again.

So my imression is that svg:viewBox is just used to desribe the input polygons
dimensions to allow using another svg polygon inside the draw object easily.
Let's see what the OASIS file format description says, next.

AW: Here is the excerpt from the OASIS XML file formtat OOo definiton:

The svg:viewBox attribute establishes a user coordinate system inside the
physical coordinate system of the shape specified by the position and size
attributes. This user coordinate system is used by the <draw:enhanced-path> element.
The syntax for using this attribute is the same as the [SVG] syntax. The value
of the attribute are four numbers separated by white spaces, which define the
left, top, right, and bottom dimensions of the user coordinate system.

So, when specifying a user coordinate system 'inside' the phys. coordinate
system of the shape (which is :x, :y, :width, :height) this seems to fit. This
means that the shape's pos and size is fix and not changeable by the viewBox
attribute. I will test with examples.

AW: Moving the code to SvxShapePolyPolygon::getPropertyValue is not valid. That
code is for API command to set the object transformation matrix, so there is no
way to save the current object's translation there (!). This needs to be removed
instantly.

AW: I think the core sentence is >a user coordinate system inside the physical
coordinate system of the shape specified by the position and size attributes<.
On the other hand a polygon object cannot be smaller or bigger tha it's
contained polygon. Also, the TRSet/GetBaseGeometry methods assume the transfered
polygon to be relative to the object, unrotated and unsheared.
AW: So, to set the object's transformation matrix, the correct steps are to call
TRGetBaseGeometry to get the current polygon, and then call TRSetBaseGeometry
with the new transformation and the saved geometry (the polygon).
AW: All the current definitions taken together, the svg:viewBox does not have
much sense at all. It is not intended to work like in SVG (this is not SVG). It
would be enough to read in the polygon, scale it to the object's size and make
it relative (move it to (0,0)). That's what is implied with 'embedded' user
coordinate system and the fact that object pos/size and polygon pos/size need to
be identical internally. Everey other use would no longer be an 'embedded' user
coordinate system, but change the position and size of the object, so overriding
:x, :y, :width and :height settings -> no embedding, not allowed.

AW: Maybe this should be changed, but then the definitions need to be changed,
too. At the moment the error is that the initial polygon which is set at the
object is not relative to the object (not (0,0) aligned). So this needs to be
changed.
AW: Luckily this may be changed in later versions since all written files
contain a svg:viewBox which completely describes the polygon dimensions. But i
see no chance to change the OASIS specification for SO8.

>That's what is implied with 'embedded' user
>coordinate system and the fact that object pos/size and polygon pos/size need to
>be identical internally. Everey other use would no longer be an 'embedded' user
>coordinate system, but change the position and size of the object, so overriding
>:x, :y, :width and :height settings -> no embedding, not allowed.
Could you please point me where can I find this in OASIS specification for SO8.
>But i
see no chance to change the OASIS specification for SO8.
Sorry. I could not find out where should be change in OASIS specification. The
spec just defines that users can use svg:viewBox to attribute establishes a user
coordinate system inside the physical coordinate system. It does not deny us to
use any thing in the user coordinate system. For example, we can set
svg:viewBox="100 100 200 200". I cann't any words in the OASIS specification
deny us using this. And as I know the svg:points and draw:path can use any point
s within the user coordinate system. 
But I think once we define a user coordinate system, we should respect to it.
For example, if we set svg:viewBox="0 0 100 100" then svg:points="40 40 60 40 60
60 40 60 40 40" should draw a square inside the draw element no matter what are
the values of :x, :y, :width, :height. 
I think the problem here is not the OASIS specification, but the current
implementation. It assumes that the points of the polygon is (0,0) aligned.

As you also said, the logic of viewBox should be:
xOut = ObjectPos.x + (((xIn - viewBox:x) * ObjectSize.width)/viewBox.width)
yOut = ObjectPos.y + (((yIn - viewBox:y) * ObjectSize.height)/viewBox.height)

No others.

AW: OASIS specification: OASIS Open Office XML Format Technical Committee
(http://www.oasis-open.org/committees/office/). Should be well-known now.

AW: From Your last answer:
>But I think once we define a user coordinate system, we should respect to it.
>For example, if we set svg:viewBox="0 0 100 100" then svg:points="40 40 60 40 60
>60 40 60 40 40" should draw a square inside the draw element no matter what are
>the values of :x, :y, :width, :height. 

That's exactly the question. Does 'embedded' mean:
(a) the values of :x, :y, :width, :height may be overridden from polygon
specification
(b) the values of :x, :y, :width, :height always define the shape
In my opinion, 'embedded' means (b), so at the moment there would be no way to
change object definition from 'embedded' user coordinate system. I think users
would write bugs if the polygon definition would overwrite their :x, :y, :width,
:height value definitions.

You also wrote:
>As you also said, the logic of viewBox should be:
>xOut = ObjectPos.x + (((xIn - viewBox:x) * ObjectSize.width)/viewBox.width)
>yOut = ObjectPos.y + (((yIn - viewBox:y) * ObjectSize.height)/viewBox.height)
No, i did not say it 'should be', this is an analysis of the existing code. So
it looks like it was intended to do it this way, but it's not completely
implemented at the moment. The implementation handles the polygon that way, but
does not change :x, :y, :width and :height when the polygon definition is
different from that. At the moment it does neither correct the polygon to (0,0)
alignment inside the shape.
So, for correcting this there is solution
(a) change :x, :y, :width, :height
(b) align polygon to (0,0) and object size
corresponding to (a,b) from above. I think to do (a) the OASIS specification
would NEED TO DOCUMENTATE that the embedded polygon data may change object width
and height definitions. That's not the case, so i think the fix needs to be (b)
as long as that is not mentioned/documented.

>AW: OASIS specification: OASIS Open Office XML Format Technical Committee
>(http://www.oasis-open.org/committees/office/). Should be well-known now.
Yes .I know. Thanks.

>That's exactly the question. Does 'embedded' mean:
>(a) the values of :x, :y, :width, :height may be overridden from polygon
>specification
>(b) the values of :x, :y, :width, :height always define the shape
>In my opinion, 'embedded' means (b), so at the moment there would be no way to
>change object definition from 'embedded' user coordinate system. I think users
>would write bugs if the polygon definition would overwrite their :x, :y, :width,
>:height value definitions.

1. I am not wanting to changing the object defines. In my opinion users define a
viewBox to avoid using percent. In my last example, I actually want 
svg:points="40% 40% 60% 40% 60% 60% 40% 60% 40% 40%". And please have a look at
this two polylines:
svg:points="40 40 60 40 60 60 40 60 40 40"
svg:points="0 0 40 40 60 40 60 60 40 60 40 40"
If they have the same :x, :y, :width, :height and viewBox, what do you want they
look like?
2. There is not an 'embedded' as you said defined in OASIS specification. 
3. There is not "align polygon to (0,0)" in OASIS specification. 
4. But there is "The svg:viewBox attribute establishes a user coordinate system
inside the physical coordinate system of the shape specified by the position and
size attributes." So once users define a viewBox, we should *respect* to it in
my opinion. 
5. If the objects have to be aligned to (0,0) please add it to OASIS specification. 
6. And please change the viewBox define from (left top right bottom) to (width
height) in OASIS specification. Since the objects have to aligned to (0,0), why
do we need define left and top in viewBox, they are alway 0,0!

Solution 1:
>(a) change :x, :y, :width, :height
>(b) align polygon to (0,0) and object size
There is another solution 2:
(a) keep the :x, :y, :width, :height
(b) render the polygons as user wanted

And as I know, we are talking about some thing else another then the problem we
meet here. The problem is:
When importing, we convert the points from user coordinate system to physical
coordinate system. If the polygon is not (0,0) aligned, then we:
 1. align it to (0,0)
 2. Using a Translate to compensate the change. You can find the code in
SdrPathObj::TRGetBaseGeometry in svx/source/svdraw/svdopath.cxx.
But unfortunately the step (1) effects the polygon's points list immediately,
but the translate gets lost at svx/source/unodraw/unoshape.cxx#L1646
The code is:
  pObj->TRGetBaseGeometry(aMatrix3D, aEmptyPolygon);
  aMatrix3D[0] = Point3D( aMatrix.Line1.Column1.... );
  aMatrix3D[1] = Point3D( aMatrix.Line2.Column1.... );
  aMatrix3D[2] = Point3D( aMatrix.Line3.Column1.... );
  pObj->TRSetBaseGeometry(aMatrix3D, aEmptyPolygon);

1, It's not what i want (i would prefer to let them look differently) but what
is possible here. As i described, both is possible, but (a) will OVERRIDE user's
definitions of :x :y :width and :height. Who will decide if the user used that 4
values by purpose or the viewBox?
2, embedded -> 'establishes a user coordinate system inside...'
3, also no 'this will override Your :x :y :width :height attribute'
4, Yes, this is a good argument, but is it enough to *ignore* :x :y :width
:height definitions?
5, This might be implied by 'The position attributes svg:x and svg:y specify the
x and y coordinates of the start position of the drawing shape.' and 'The
attributes svg:width and svg:height specify the width and height of the drawing
shape', see OASIS specification. It is also mentioned in the viewBox description
'Some implementations may ignore the view box attribute. The implied coordinate
system then has its origin at the left, top corner of the shape, without any
scaling relative to the shape.'.
6, Yes, itis is a description error in OASIS, but usage is width/height.

>2. Using a Translate to compensate the change.
No, this is exactly what would OVERRIDE the :x :y settings. Also, an extra scale
would be necessary, too (You do not want to have the polygons scaled to original
object size defined by :width and :height if polygon starts 4 cm right and below
:x, :y, do You?). Together this would be a scale and a translate, effectively
changing :x :y :width :height -> exactly solution (b).
The translation does not get 'lost' with TRGetBaseGeometry/TRSetBaseGeometry.
Thoise methods are core interface and are designed to exchange the
transformation and the geometry data in the form of a unrotated, unsheared,
(0,0) aligned polygon, they work as intended. The fix needs to be done where
those methods are used to feed them what is intended.
So back to the problem: What is intended? I repeat the possibilities:

(a) change :x, :y, :width, :height -> polygon will define new :x :y :width and
:height if different from given ones
disadvantages: user's definitions of :x, :y, :width, :height will be *ignored*
advantages: free polygon definitions which may leave the embedded user
coordinate system

(b) align polygon to (0,0) and object size -> polygon will be scaled to :width
:height, translated to (0,0) and set at the object
disadvantages: svg:viewBox would have the only meaning to be able to define the
polygon using another coordinate system (maybe handy when copying from svg
files), advantages: user's definitions of :x, :y, :width, :height will be kept

With both systems You can import whatever You want: With (a) You simply use
svg:viewBox and thge path data, with (b) you will also need to adjust :x :y
:width and :height. Since You can do every polygon import with both methods,
this applies no restrictions in that area. This means the decision what to do
does not depend on that argument.

So the most important argument in my opinion is that user's definitions of :x,
:y, :width, :height may be *overriden* ro *ignored* -> i think solution (b)
should be used.

AW: I discussed with CL, and his interpretation of the usage of svg:viewBox is
that it is there to support user coordinate systems by hiding the measurement
system from the polygon definition (like in svg). All 4 values of x,y,width and
height may be in different measurement units, so that's where the viewBox comes
into play. It allows to define the polygon data itself without measurement
units. In svg, it also clips the polygon data, but we cannot do that in OOo/SO.
This still opens the problem when the viewBox range is not fully used, e.g.
viweBox(0,0,100,100) and a line (50,50 100,100). Since the draw object has to be
the same size as the polygon data, this may make a modification of the object
psoition and size valid.
When the polygon data is overlapping the viewBox range, clipping would be
necessary to do it like svg. Since we cannot do display clipping here, it would
be geometric clipping -> changes polygon definition and produces edges at the
object bounds. Also not good.
So, maybe for all involved stuff, (a) maybe indeed best.

AW: Set to PP1

*** Issue 37500 has been marked as a duplicate of this issue. ***

Is this a problem during import or export? I created (by fiddling around with
the svg2draw filter) a perfectly looking draw document (after being loaded) that
is corrupted when saved again with OOoffice (1.9m100).

The "perfectly looking" is relative, because when clicking on the bezier path in
the middle (I'll attach the document), the handle point that denote the selected
object are outside the bounds of the path elements. Such graphics object cannot
be created within OOoffice itself. 

What's going on during save is some sort of (broken) normalization process. The
result of it is the bezier path being moved with its left upper bounds to the
top left of the document.

The summary of this issue is not much helpful for helping to find it -- before
reporting a duplicate.

Created attachment 26420 [details]
Document that changes when it is being saved again with OOoffice. The bezier path moves to the top left corner of the document during save. The document content.xml is created manually by inserting the results of a svg2draw filter operation.

AW: Shifted due to workload

I am having sma issues. When I create Polygon or polyline it shifts to top 
left corner. If we have any solution to that.

Reset the assignee to the default "issues@openoffice.apache.org".