Bug 48068 - [SVG] path d="M 20 120 H 40.5.6" not parsed properly
Summary: [SVG] path d="M 20 120 H 40.5.6" not parsed properly
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL: http://www.w3.org/Graphics/SVG/Test/2...
Whiteboard: target:3.6.0 target:3.5.5
Keywords:
Depends on:
Blocks: SVG-Import
  Show dependency treegraph
 
Reported: 2012-03-29 16:34 UTC by Valek Filippov
Modified: 2023-09-06 15:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
W3C SVG test suite "path-data-18-f" (4.62 KB, image/svg+xml)
2012-03-29 16:34 UTC, Valek Filippov
Details
Fixed test document (4.57 KB, image/svg+xml)
2012-05-23 07:32 UTC, Petr Mladek
Details
W3C SVG test suite "path-data-18-f" (4.62 KB, image/svg+xml)
2013-10-14 23:21 UTC, Thomas Arnhold
Details
Omitted zero in path data (1.62 KB, image/svg+xml)
2014-08-17 12:48 UTC, Regina Henschel
Details
Example without missing zeros (18.78 KB, application/vnd.oasis.opendocument.graphics)
2016-03-04 23:08 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Valek Filippov 2012-03-29 16:34:07 UTC
Created attachment 59246 [details]
W3C SVG test suite "path-data-18-f"

LO Draw doesn't pass W3C SVG test suite 'path-data-18-f' test (see attached file).
"Test passes if no red is visible."
Comment 1 Not Assigned 2012-05-15 13:18:30 UTC
Chr. Rossmanith committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bef8e358b6940fd4a976cb346dfd829643e581b8

fdo#48068 fix parsing of path d-attribute
Comment 2 Christina Rossmanith 2012-05-15 13:20:24 UTC
The patch only fixes the buggy parsing not the buggy anisotropic scaled stroke width.
Comment 3 Petr Mladek 2012-05-23 07:32:28 UTC
Created attachment 62019 [details]
Fixed test document

The test document in the comment #0 was broken. It created the 5th black line on another Y coordinate (110 vs. 120). I did the following change:

--- paths-data-18-f.svg.old
+++ paths-data-18-f-fixed.svg
@@ -63,7 +63,7 @@
       <path d="M 20 100 H 40" stroke-width="4" stroke="black"/>
   
       <path d="M 20 120 H 40.5 0.6" stroke-width="2" stroke="red"/>
-      <path d="M 20 110 H 40.5.6" stroke-width="4" stroke="black"/>
+      <path d="M 20 120 H 40.5.6" stroke-width="4" stroke="black"/>
   
       <path d="M 20 140 h 10 -20" stroke-width="2" stroke="red"/>
       <path d="M 20 140 h 10-20" stroke-width="4" stroke="black"/>
Comment 4 Not Assigned 2012-05-23 07:37:28 UTC
Chr. Rossmanith committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=de4b790fa928f92bf40b2e2b2c2acb622f9ebd8b&g=libreoffice-3-5

fdo#48068 fix parsing of path d-attribute


It will be available in LibreOffice 3.5.5.
Comment 5 Thomas Arnhold 2013-10-14 23:21:12 UTC
Created attachment 87635 [details]
W3C SVG test suite "path-data-18-f"
Comment 6 Thomas Arnhold 2013-10-14 23:23:49 UTC
Petr is right, the test document had an error. I've uploaded the original one from the test suite. There is no red visible anymore, but a new problem pops up:

There are no yellow boxes visible. Libo only has black boxes.
Comment 7 Regina Henschel 2014-08-17 12:48:05 UTC
Created attachment 104761 [details]
Omitted zero in path data

I have written a corresponding issue in OpenOffice with another test document (attached here too). https://issues.apache.org/ooo/show_bug.cgi?id=125447

LibreOffice is wrong in LO4.2 same as OpenOffice, and with additional errors in trunk version.
Comment 8 Xisco Faulí 2015-08-26 13:21:10 UTC
Black boxes problem still present in

Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: es-ES (es_ES)

on Windows 7 (64-bit)
Comment 9 Xisco Faulí 2016-03-04 14:20:04 UTC
Looks like the problem is in the Y value of scale(8, 2). it's easy to see if it's changed to scale(8, 0.5). I'll take a look
Comment 10 Regina Henschel 2016-03-04 23:08:57 UTC
Created attachment 123304 [details]
Example without missing zeros

The attached example shows, that somewhere width and height are exchanged. Currently the stroke-width changes, when scaled in x-direction; and the stroke-width does not change, when scaled in y-direction.

This is an error independent from zero values and should become its own issue.

The rendering is correct in AOO.
Comment 11 Regina Henschel 2016-03-05 18:03:35 UTC
@Xisco: I think the wrong rendering in regard to the scale-transformation is unrelated to the number problem in this issue. I have written bug 98451 for the wrong scaling of the line. Please use that issue, if you work on the problem.
Comment 12 QA Administrators 2017-03-06 15:19:13 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2019-12-03 14:01:28 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2021-12-03 04:25:03 UTC Comment hidden (obsolete)
Comment 15 Xisco Faulí 2023-09-06 15:32:02 UTC
This issue seems to be fixed since LibreOffice 6.2. Closing