Created attachment 76424 [details] Test file with lists in "dx" and "dy" attributes of <tspan>. Text in SVG files with a list-of-coordinates in the "x" or "y" attribute of <tspan> or <text> elements are not rendered correctly. The same goes for list-of-lengths in "dx" and "dy" attributes of the same elements. Tested on LibreOffice 3.5.4.2, Build ID: 350m1(Build:2) on Ubuntu Linux on AMD64. Attached are two simple SVG test files and screendump of how they are rendered in Firefox and LibreOffice, respectively.
Created attachment 76426 [details] Test file with lists in "x" and "y" attributes of <tspan>
Created attachment 76428 [details] First test file rendered in LibreOffice: The "dx" and "dy" attributes are ignored.
Created attachment 76429 [details] Second test file rendered in LibreOffice: "x" and "y" lists jumbles the output.
Created attachment 76430 [details] First test file as rendered in Firefox.
Created attachment 76431 [details] Second test file as rendered in Firefox.
Confirmed. Status set to NEW. Component should perhaps be "graphics stack" or "filters and storage" rather than Writer. Provided files tested under Crunchbang 11 x86_64 running: - v3.3.4.1 OOO330m19 Build: 401 - v3.4.6.2 OOO340m1 Build: 602 - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b - v3.6.7.2 Build ID: e183d5b - v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24 - v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a Results (short references are to the graphics provided in comment #0 and comment #1): v3.3.4.1 - no text displayed for either graphic v3.4.6.2 - no text displayed for either graphic v3.5.7.2 - #0 displayed as indicated in comment #2 (for LO) - #1 displayed as indicated in comment #3 (for LO) v3.6.7.2 - #0 displayed as indicated in comment #2 (for LO) - #1 displayed as indicated in comment #3 (for LO) v4.0.6.2 - #0 displayed as indicated in comment #2 (for LO) - #1 displayed as indicated in comment #5 (for Firefox) v4.1.3.2 - #0 displayed as indicated in comment #2 (for LO) - #1 displayed as indicated in comment #5 (for Firefox) So there does seem to have been some improvement, which is encouraging.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Confirmed attachments are like in the screenshots, when inserted to a document. If opened with LibO Draw, however, no text is visible. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 80ec99db4325a439a8a3f1d420d0a80f8bf9c439 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-16_00:00:20 Locale: fi-FI (fi_FI)
*** Bug 95399 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
first file looks wrong in Draw Second file looks same as in Inkscape still repro in Version: 6.2.0.0.beta1 (x64) Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
Dear Jørgen Elgaard Larsen, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Jørgen Elgaard Larsen, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible in LibreOffice 7.2 and the latest LibreOffice 7.4 master. First one (attachment 76424 [details] kern_test.svg) looks wrong. Second one (attachment 76426 [details] kern_test2.svg) looks correct. Version: 7.2.4.1 / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 6ca94dbd576be7aaa643393e2a9e2ee1c723c357 CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
This small example shows the problem: <svg xmlns="http://www.w3.org/2000/svg"> <text x="20" y="20"> <tspan dy="0 20 20">ABC</tspan> </text> </svg> SVG tspan element http://tutorials.jenkov.com/svg/tspan-element.html
bug tested and not corrected yet Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9fc0b2b9b96d87eb642a3b29e9dcb5d6273265eb CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: it-IT (it_IT); UI: it-IT Calc: threaded
The horizontal kernel is now fixed after the fixes for bug 156283 and bug 156577
In order to fix the Dy part, TextSimplePortionPrimitive2D and TextDecoratedPortionPrimitive2D should also support Dy array ( at the moment, only dx array is supported and rendered in drawinglayer/source/processor2d/vclprocessor2d.cxx ) @Khaled, is it something you could be interested to implement since it involves text rendering?
We don’t have a way to change y position of individual letters, you would need to plump this all the way into VCL’s SalLayout. But I don’t see why you need to apply a y array, if a part of text has a different base line it has to be handled separately and then positioned at the desired position, you don’t want to kern or apply ligatures across the different base lines.