On Sat, Jan 01, 2005 at 05:56:53PM -0400, bulia byak wrote:
On Sun, 2 Jan 2005 08:43:17 +1100, vellum <kaver@...68...> wrote:
Peter wrote:
For the moment I've backed out my change, as I consider this a worse bug. I hope to fix things later.
What was the change and what was the bug?
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.