| Summary: | Multi-line artistic text is saved with wrong coordinates for second+ lines | ||
|---|---|---|---|
| Product: | [Applications] karbon | Reporter: | Friedrich W. H. Kossebau <kossebau> |
| Component: | general | Assignee: | Jan Hambrecht <jaham> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Examples where the lines are misplaced or not misplaced. | ||
Git commit d1ac6aa4279d2379f68475f770326699ce605762 by Jan Hambrecht. Committed on 02/03/2012 at 00:10. Pushed by jaham into branch 'master'. fix saving of multiline text M +3 -10 plugins/artistictextshape/ArtisticTextShape.cpp http://commits.kde.org/calligra/d1ac6aa4279d2379f68475f770326699ce605762 |
Created attachment 69171 [details] Examples where the lines are misplaced or not misplaced. Version: unspecified (using Devel) OS: Linux Creating a multi-line artistic text and saving it can result in the second and following lines being misplaced close to the top-left corner of the page. Happens both if saving to ODG and SVG (no real surprise). Reproducible: Didn't try Steps to Reproduce: 1. Create a new Artistic Text object by dropping it into the document (no resizing) 2. Enter text with linebreaks. 3. Save as new file 4. Load that file Actual Results: In the loaded file the lines besides the first line are placed near the top-left corner of the page. Expected Results: All lines are placed in the loaded document like they were before the document was saved. The broken behaviour can be prevented if the object is resized before saving. Seems the reason is that the values of the x,y coords of the following lines are always written relative to the top-left corner of the text box, which seems to only work if also a transform attribute is written, which seems to also take the initial offset of the text object into account, at least partially: <text id="shape0" fill="#000000" x="0.00000000000pt" y="15.20312500000pt" transform="matrix(1.28806 0 0 1.28806 172.503 172.981)"> where the non-resized object has: <text id="shape0" fill="#000000" x="167.89166629684pt" y="127.01942270710pt"> See the two example files (okay, broken) in the attached tarball for the whole data.