Peter wrote:
For the moment I've backed out my change, as I consider this a worse bug. I hope to fix things later.
Fair enough. I got the impression earlier from Bulia that the non-uniform scaling area was a little messy to work in. Anyway my original needs have been addressed for which I'm really happy, and I raised that bug for the record. Will you reinstate the bug? Since it will still be there until the code is fixed properly.
When you do decide to fix it let me know and I'll be happy to test and compare with other programs.
vellum
On Sat, Jan 01, 2005 at 05:56:53PM -0400, bulia byak wrote:
On Dec 15, Bulia added a set_transform "method" to sp-text.cpp that would scale the font-size attribute when a text object was scaled (or had any other affine transformation applied to it other than using the object properties dialog box).
vellum pointed out that although this did what vellum expected if the affine transformation was any combination of rotation, translation and uniform scaling, it did not do as he expected for skew or non-uniform scaling. What vellum expected, and what a number of proprietary programs vellum tried do, is that the font-size should become the "height" of the transformed text[*1]: e.g. that horizontal scaling of text should not affect the font-size attribute, and that vertical scaling by 200% of the text (without horizontal scaling etc.) should double the font-size.
[*1] "Height" not measured in the direction of the y axis but in the direction perpendicular to the baseline of the text; i.e. roughly the distance from ascender line to descender line, rather than the height of the bbox.
On Dec 31, Peter changed the expansion calculation of sp_text_set_transform according to this "height" measure rather than expansion() measure that Bulia had used.
However, this produced an unexpected interaction with the sp_css_attr_scale(css_set, 1/local.expansion()) call that Bulia added to desktop-style.cpp:sp_desktop_apply_css_recursive on Dec 19. (Note the use of expansion() there as the scaling metric.)
The result was that after applying non-uniform scaling to a text object, the font-size selector in the Text & Font dialog box didn't do what the user expected: in the "scale horizontally by 200%" example, requesting a font size of 10 would result in the font-size widget showing 14.14 (i.e. 10 * sqrt(2), where sqrt(2) is the expansion() of the transformation matrix left on the text object.
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 note that sp-text.cpp:sp_text_adjust_fontsize_recursive changes font-size and letter-spacing & word-spacing, but that sp_css_attr_scale in addition changes baseline-shift, stroke-width and kerning. I'd guess that there's a bug in that difference.
I'd guess that the other caller of sp_css_attr_scale, in selection-chemistry.cpp (something to do with pasting), should use the same expansion metric, for consistency.
Bulia, can you have a look at these issues please? As the author of most of this code, I thought you might be more familiar with the reasons for the different scaling choices made by the code.
pjrm.
On Sun, 02 Jan 2005 17:31:56 +1100, Peter Moulder <Peter.Moulder@...38...> wrote:
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.
No it's not a bug, sp_text_adjust_fontsize_recursive only applies to text objects and therefore scales text properties (others, if needed, are handled at the SPItem level). But sp_css_attr_scale, as I said, is a universal function that "scales" the entire style string that is going to be applied to something.
There it's used on copying to clipboard, not pasting. The style of the copied object is saved in style_clipboard, but only after it is also prescaled by the copied object's transform expansion. The combination of two prescalings, on copy and on paste style (which uses sp_desktop_apply_css_recursive) ensures that you can always copy style from one object and paste it to another and get the same visible result, regardless of the transforms of the source and target objects.
I haven't tried your fontsize_expansion, but I'm pretty sure it would be incorrect to apply it to anything but font size. E.g. stroke width should obviously use regular expansion[1] because it cannot depend on the direction of scaling. And I'm not sure that, with the style scaling system in place as explained above, it is possible at all to use two different expansions without messing it all up.
[1] Actually stroke should not use any expansion at all, but be transformed by the transform itself as if it were an object, see http://sourceforge.net/tracker/index.php?func=detail&aid=851008&grou..., but that's another matter entirely.
On Sun, Jan 02, 2005 at 03:32:32AM -0400, bulia byak wrote:
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.
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.
The problem is, it MUST be "neither the horizontal scale nor the vertical scale" because "horizontal" and "vertical" only make sense for fonts.
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).
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.
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.
On Sun, 2 Jan 2005, Peter Moulder wrote:
Hmm, this is a good point...
Maybe what we're dealing with is two different types of units for measuring length: Document distance and Scaled distance.
Document distance (px, pt, in, cm, mm, etc.) corresponds exactly to measurements on the printed document.
Scaled units make use of a document-specific scaling factor. For instance, a document my use a scale_factor of 1 cm : 1 km.
I can imagine that a given unit could be *both* document and scaled. For instance, 'm' is an allowed document unit in SVG, but I could imagine creating a landscaping plan using meters at a scale of 1 cm : 1 m. So the system may need to be smart about allowing a given unit name to be either document or scaled. That could be a tricky requirement...
The scaling factor is not a unit property, so wouldn't be stored with the units themselves. I.e., if I'm at a particular scale, I want to be able to switch units from km to mi to furlongs and back without losing accuracy.
Now, how should this affect the dialog unit widgets? Perhaps the user sets a document preference to indicate that the document is 'scaled', which flips all of the dialog unit widgets from document units (px, pt, in, et al) to the scaled units (km, mi, ft, etc.)
Another question is - how do we store this information with the document? This is really two questions - first how to store the scale factor (I imagine adding a new inkscape: property? Or is there something standard in SVG?) and second how to store the numbers (I guess as pt's or px's?)
Bryce
participants (4)
-
Bryce Harrington
-
bulia byak
-
Peter Moulder
-
vellum