-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object scale is not preserved after editing #11
Comments
This is a misunderstanding of what the term "scale factor" means in TexText. "Scale" means that the length unit coming from the latex-svg node is scaled by the specified factor. So if you change the length or hight of the content -- as in the exmample -- then the size of the node will change, too, and the node is roughly placed in the middle of the olde one. Please see the attached figure. In all three nodes the sin(x) has the same size, but the recreated node with (There is a very small placing issue after rescaling/reediting. This will be fixed in the pdf2svg version of TexText) |
Let me be more clear about this issue. I'm perfectly fine with change of object width along with length of formula, it's not an issue. In the attached image I have three sets of figures and formulae, row by row: original formula, by-hand-scaled formula, edited-by-hand-scaled formula. My concern is edited-by-hand-scaled formula was reverted to the original size and my hand-tuned scale is lost. |
This behaviour is intended. Although I understand that in your scenario this might by annoying. Let me explain: When @leberwurstsaft implemented the scale factor feature some time ago we wanted to have the possibility to scale the svg-node resulting from pdflatex+pstoedit in such a way that it fits to the geometry of the other objects (boxes, lines, etc.) in the Inkscape drawing. On the other hand, from a typographic point of view, there should be only one or maybe two font sizes used in a single document. So, if one is of the opinion that a scale factor of e.g. 0.8 is suitable for the current Inkscape document all other nodes should also have a scale factor of 0.8. We think that this is more easily and intuitively realized by a number than by scaling each object manually by the mouse. Hence, the scale factor directly manipulates the transform-attribute of the svg-group and overwrites any changes done by the mouse in Inkscape. Of course we could offer an option "Use scaling from Inkscape" but even then it is not really clear what is the intention of the user: Preserver the width of the node? Or the hight? Additional options would be required. |
I see you point to have this typographic-based approach. The convenient thing to do is to update I.e if I created Such change would not affect people who use several fixed scales across the document, but could be very helpful in other cases. Of course there is an ambiguity when an object is a subject of non-uniform scaling, but this could be solved by extra (optional) radio button control("keep x scale" vs "keep y scale"). But this could be seen as a new feature. I think it's should be rare use case. Note, now non-uniform scaled object simply disappears after editing. I think I'll fill it as another issue. |
Certainly, this would be a nice feature and we can define it as an enhancemant request for milestone x.y, I am totally OK with that. Non uniformly scaled nodes do not disappear. They are flying "somewhere". Try it by creating one node in a blank document, scale it non-uniformly, re-edit it in TexText and then, after it seems to be disappeared, press 4. (The reason for this is our handling of the svg node which does not take care of any scaling, only on positions and that in a very rough manner, but enough for the requirements so far.) As a consequence of this discussion I will add a comment in the documentation that any manual scaling done in Inkscape is not preserved and leads to unexpected effects after recompiling. Regards, Jan |
Steps to reproduce:
Desired behavior: object scale same as at step 2
Actual behavior: object scale is reset
The text was updated successfully, but these errors were encountered: