On Sun, 02 Jan 2005 21:39:57 +1100, Peter Moulder <Peter.Moulder@...38...> wrote:
I've tried testing that just now, but my testing at the moment suggests that it's correct already.
See the attached file. Ctrl+click to select the orange object, Ctrl+C, Ctrl+click to select the yellow object, Ctrl+Shift+V. Expected behavior: the yellow object must take all aspects of the orange object's style, including the same visible stroke width. Actual behavior: The stroke width is much thinner than it should be.
Incidentally, I have my misgivings about trying to compensate lengths in this way. vellum complained about using expansion() to convert a matrix with non-uniform scaling to a scalar for font-size, and similar issues apply to stroke-width, dash lengths and other lengths. The geometric mean involved in expansion() is unpredictable to users, being neither the horizontal scale nor the vertical scale (even before considering skew etc.).
The problem is, it MUST be "neither the horizontal scale nor the vertical scale" because "horizontal" and "vertical" only make sense for fonts.
One issue is how this interacts with SVG mechanisms like style sheets and inheritance from parent elements, where the transform matrix will apply to the inherited number, unlike the number entered in the dialog box in current code since mid-December.
This is only an issue for out-of-line CSS which we don't support yet. If two objects use the same CSS class and one of them is scaled 200%, its stroke width will be twice as wide, and there's no way to prevent that. If however you assign the same stroke width to these two objects via inline styles, as now, there's no reason not to compensate the scale so that both get the same visible stroke width. This is what is done now for all style properties (and by the way, for stroke width assigned via Fill&Stroke it was being done since long ago, I just made this more universal).
Maybe these issues can be handled with the unit menu: whether the number should be interpreted as an effective width on page (under some assumption about px/in), or whether it should be SVG's understanding of the number (subject to transforms).
I see no reason to introduce "SVG's understanding of the number" into the UI. It will be terribly confusing. Those who need it can always use the XML editor.
A related note about units: People have been suggesting that km etc. should be added to the units menu, but I don't think we should be interpreting `10km' as `2822222.22px': partly because that's beyond the range of SVG Tiny (and I think SVG Basic), which can only represent numbers in the range +/-32767.9999. A lesser issue is that clearly we don't want to use up 10km of paper when printing such a document. If the diagram is to scale then the diagram may well include a legend with a `hard-coded' statement of scale, in which case we want that scale to be the default when printing, even if a program other than inkscape prints the SVG file.
Yes, it might be a good idea to introduce an inkscape:units-scale into the namedview, so that e.g. a rect is displayed as 10km wide but is saved into SVG as 10cm wide. Worth an RFE.
