On Thu, 16 Dec 2004 22:11:16 +1100, vellum <kaver@...68...> wrote:
However, with non-uniform scaling all hell breaks loose. First. Scaling vertically changes the font size as I would expect. However if I then try to change the font size to the original size then the font dialog font size is correct but the screen presentation is not.
Yes, because non-uniform scaling cannot be expressed via font size change. Thus it is factored into two parts, as I explained. When you reset font size to original, you remove only the uniform component of the scale; the non-uniform one remains. I think this is logical.
I honestly don't understand what you are trying to achieve. Imagine you drew a number of equal-sized squares and then scaled them non-uniformly turning them into different rectangles. Now, would you expect there to be an "easy" way to turn them all back to equal-sized squares? I think not. You did what you wanted to them, and now you can only get back by either (1) undo or (2) transforming them again to make them squares. Isn't it logical? It's absolutely the same for text. If you scaled your text non-uniformly and want to get back, do either (1) or (2), exactly the same as with rects. And if (for example) you want different text objects to have the same letter height but different horizontal squeeze, it's easy to achieve that too.
So, can you just explain the final result you're trying to achieve?
I like the way in which the new code generates the new percentage information (H and V) as the scaling is proceeding. This operates intuitively but then it disappears. Why not retain it where it is or regenerate it when the text is reselected? It could also be shown in the text dialog along with the font size.
Because what is stored for an object is not just "scale" but a complete transform which may include rotation, skew, etc. You can look it up in the Object Properties dialog (for now; later I'll probably move it to the Tranformation dialog where it makes more sense).
David Bergs idea of "A button "set as 100%" for height and width will then adjust the font-size according to the skewed/streched width or the height respectively. I think this way all needs are served ;)" seems like a good one. Perhaps this could also go in the font dialog ultimately.
I don't understand still. What will this button do? Just remove the stored transform? Can you explain step-by-step?
Well, now that I think of it, perhaps what you want is for Inkscape to always display and set the "visible" font size, not the font size stored in SVG. This is what is currently done for stroke width: if an object is scaled (either by its own transform= or that of its ancestor group) so that its stroke _looks_ 2pt wide, the Fill & Stroke dialog will be 2pt, even if the source SVG has stroke-width:1pt. However:
(1) I'm not sure this will work for font size the same as it works for stroke width. That's because font size is a vector, not scalar, and it's not always clear how to measure this vector. For example, if your text is skewed, what would you consider its font size: the height perpendicular to the base, or the "length" of skewed letters parallel to the skew? What if this is text on path where each letter is rotated differently, plus they all are skewed and squeezed?
(2) In so far as this is possible, this is _already done_. That was the idea of my latest change: if it is possible to unambiguously factor out the uniform scale component from a transform, it is factored out and applied as font size change; the remainder is applied as a regular transform= as before. This factoring is guaranteed to always work, and it covers the most common practical case of uniform scaling. It _may_ be possible to go further and attempt to factor out (more of) a font size component for a wider class of transforms, such as non-uniform scales and skews, but (a) this is beyond my modest math capabilities at this point; (b) I'm not convinced it is possible in general case; (c) I'm not convinced it will be absolutely "intuitive" (i.e. achieve the ideal match of "how large it looks" and its reported font size) even if we do it.
P.S. Perhaps you noticed the bug: the font size reported in the statusbar in selector for a text object is wrong (unchanged) after scale. This is completely unrelated to the above discussion. Just deselect and reselect it again to see the correct font size.