dimensions of cloned objects seem wrong

Bug #1414018 reported by Ulrich-windl
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
New
Undecided
Unassigned

Bug Description

I created a test document, cloning four objects at once, then I moved the cloned objects together.
Ispecting the result, I feel the dimentsions in the cloned <use> objects are wrong: I expected the dimensions to be unchanged (on translate), but each object seems to have the dimension of the whole drawing:
top-svg: width="1052.3622" height="744.09448"
original-rect: id="rect4642" width="402.85715" height="515.71429"
cloned-rect: <use xlink:href="#rect4642" transform="translate(555.5839,0)" x="0" y="0" width="1052.3622" height="744.09448" />
Shouldn't the dimensions be preserved on this type of transform?

Inkscape 0.48.5 r10040 (on x86_64 openSUSE 13.2)

Tags: clones svg
Revision history for this message
Ulrich-windl (ulrich-windl) wrote :
Revision history for this message
su_v (suv-lp) wrote :

Please always include information about OS/platform and Inkscape version (see Inkscape menu 'Help > About') to a bug report, thx.

Changed in inkscape:
status: New → Incomplete
tags: added: clones svg
Revision history for this message
su_v (suv-lp) wrote :

On 2015-01-23 15:08 (+0100), Ulrich-windl wrote:
> I feel the dimentsions in the cloned <use> objects are wrong

Please reread the SVG 1.1 spec about the meaning of x, y, width and height of a <use> element [1]: those refer to position and size of "the rectangular region into which the referenced element is placed.", not the position and size of the <use> element itself.

«The ‘use’ element has optional attributes ‘x’, ‘y’, ‘width’ and ‘height’ which are used to map the graphical contents of the referenced element onto a rectangular region within the current coordinate system.»
<http://www.w3.org/TR/SVG11/struct.html#UseElement>

Note that the spec differs between <use> elements referencing a <symbol>, an <svg> element or otherwise.

AFAIU current stable Inkscape 0.48.x adds the width and height attributes as soon as the clone is transformed (e.g. translated), referencing the dimensions of the <svg> viewport the referenced object is in (i.e. the page size as set in the document properties, aka the width and height of the top-level <svg> element).
Upcoming 0.91 will use '100%' for the added width and height attributes of the <use> element if transformed (i.e. referencing the full width/height of the viewport of the referenced element).

[1] http://www.w3.org/TR/SVG11/struct.html#UseElementXAttribute

Revision history for this message
Ulrich-windl (ulrich-windl) wrote :

I guess you know that Inkscape's version is in the file: 0.48.5 r10040 (on x86_64 openSUSE 13.2)

su_v (suv-lp)
Changed in inkscape:
status: Incomplete → New
description: updated
Revision history for this message
su_v (suv-lp) wrote :

Somewhat related earlier reports:
* <use> referencing a <symbol> element:
  Bug #1107924 “Used symbols won't show in webbrowser due missing attribute.”
  http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/40338/focus=40339
* <use> referencing a <svg> element:
  Bug #568833 “<use> with referenced <svg> must set width/height properties”

Based on tests with archived builds (rev <= 12285 uses page size (in user units), rev >= 12292 uses percentages), the fix for bug #1107924 is what changed the width/height attributes to use "100%" instead of the computed page width/height (for upcoming 0.91). The wording in the SVG 1.1 spec is still confusing to me though, and I'm not sure whether setting width/height to '100%' on "regular" clones is more correct than what earlier versions did (or whether the two attributes should be omitted completely in this use case).

Revision history for this message
Ulrich-windl (ulrich-windl) wrote :

Please accept my apologies for not understanding the SVG specs: I wondered what the use of wight and height attributes are if (what they seems to be) they are no actual hints for the bounding box of the insered element.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.