To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=37213
------- Additional comments from [EMAIL PROTECTED] Wed Mar 2 06:44:10 -0800 2005 ------- 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. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
