On Sun, Jan 02, 2005 at 03:32:32AM -0400, bulia byak wrote:
On Sun, 02 Jan 2005 17:31:56 +1100, Peter Moulder <Peter.Moulder@...38...> wrote:
Just now I've recommitted the different expansion metric, but this time I've similarly changed the sp_css_attr_scale call in desktop-style.cpp. I'm not very confident with this change, in particular the interaction with letterspacing, kerning etc.
I'm pretty sure this is incorrect too (though I haven't tested yet). sp_desktop_apply_css_recursive is a universal style setting function used for all kinds of style, not only text style. The call to sp_css_attr_scale was added so that when I apply e.g. the stroke-width of 2pt to an object which is scaled 200%, the actual value written to SVG is 1pt so that the _visible_ width is the requested 2pt. Thus sp_css_attr_scale scales all style properties that can have a <length> as value, not only font size. By using fontsize_expansion you fixed font size but likely broke prescaling of all other properties. Please rethink.
I intend to leave this to you to look at, as you're evidently more familiar with the relevant bits of code than I.
I'll just add a note that when testing, I suggest testing both stroke-width of text objects and stroke-width of non-text objects.
I've tried testing that just now, but my testing at the moment suggests that it's correct already. That conflicts with my understanding of what's happening, so either my understanding is wrong or my testing is wrong (perhaps because of poor understanding of what's happening and hence how I should test that things are working correctly). More reason for me to leave this to you.
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.).
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.
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).
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.
pjrm.