Bug 138501 - Distance-Based Dash Patterns Drawn Incorrectly
Summary: Distance-Based Dash Patterns Drawn Incorrectly
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-26 03:35 UTC by Alfred Hellstern
Modified: 2022-11-27 13:52 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Bug report with illustrations (81.17 KB, application/xml)
2020-11-26 03:41 UTC, Alfred Hellstern
Details
Sample file created in LibreOffice (8.46 KB, application/xml)
2020-11-26 03:44 UTC, Alfred Hellstern
Details
styles.xml relevant for this bug (11.26 KB, application/xml)
2020-11-26 03:45 UTC, Alfred Hellstern
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alfred Hellstern 2020-11-26 03:35:19 UTC
Description:
We noticed a discrepancy between how LibreOffice saves and displays the same information.

Background:

A stroke pattern is defined with these parameters: 
•	primary dash length (percentage or distance)
•	primary dash count
•	secondary dash length (percentage or distance)
•	secondary dash count
•	distance between all dashes
So for example, the following dash pattern: one long dash, two short dashes, repeating
 
is defined by:
•	primary dash length = 1100% of width
•	primary dash count = 1
•	secondary dash length = 100% of width
•	secondary dash count = 2
•	distance between all dashes = 500% of width 
Most dash patterns are defined as percentages, and so the dashes change lengths proportionally as the width changes, but some use absolute distance values. These, specifically, appear to have an issue.


Steps to Reproduce:
•	Open LibreOffice Writer and create a vertical line with width 6pt and dash pattern "Line with Fine Dots".
•	Save and close the document. Change the file extension to .zip, extract all the contents, and open styles.xml.


Actual Results:
•Observe that the dash pattern is defined with this XML line:
<draw:stroke-dash draw:name="Line_20_with_20_Fine_20_Dots" draw:display-name="Line with Fine Dots" draw:style="rect" draw:dots1="1" draw:dots1-length="0.7902in" draw:dots2="10" draw:distance="0.0598in"/>
•The primary dash, then, should be .79 inches long, but if you draw a square next to the primary dash, you can see that it's actually drawn 1.39 inches long. [See Fig. 1 at bottom.]
•If you open the ODT in Office Word and perform the same comparison, you can see that Word actually does draw the primary dash .79 inches long. [See Fig. 2 at bottom.]

Expected Results:
It seems that Office Word honors the measurements given, but LibreOffice renders them at about double the given distance. I believe this is a LibreOffice bug.


Reproducible: Always


User Profile Reset: No



Additional Info:
see attached files
Comment 1 Alfred Hellstern 2020-11-26 03:41:00 UTC
Created attachment 167579 [details]
Bug report with illustrations

contains the illustrations referenced in the bug report opened using the Bugzilla template
Comment 2 Alfred Hellstern 2020-11-26 03:44:01 UTC
Created attachment 167580 [details]
Sample file created in LibreOffice

This is the sample to reproduce the Line with dots distance bug
Comment 3 Alfred Hellstern 2020-11-26 03:45:12 UTC
Created attachment 167581 [details]
styles.xml relevant for this bug
Comment 4 Alfred Hellstern 2020-11-26 03:50:25 UTC
I work for Microsoft and we are going to implement ODF 1.3. This was found during investigation of 1.3 changes. Per Regina Henschel (like Regina, I'm a member of the OpenDocument technical committee) this appears to be the ssame error as with hatch distance:

https://bugs.documentfoundation.org/show_bug.cgi?id=100972
Comment 5 [REDACTED] 2020-11-26 13:02:38 UTC
I would not be surprised if every second user has this bug, what to do with this is not clear. I'll try to apply this information https://www.topresumewritingservices.com/resume-com-review/. 
I will try to report on the result, although now it is so tight with time
Comment 6 Regina Henschel 2020-11-26 18:52:21 UTC
It looks as if there is a 100th-mm to Twips conversion, where it should not be.

I see the same values as in file format, if I inspect a dashed line using a macro. But the line style dialog has the same wrong values as rendered.

You get the same error, if you copy a dashed line with fix dash length from Draw to Writer.

It looks similar to the hatch distance problem. But without knowing the place in core, I'm not sure, whether it is the same. Therefore I do not mark it as duplicate.
Comment 7 QA Administrators 2022-11-27 03:38:11 UTC Comment hidden (obsolete)
Comment 8 Regina Henschel 2022-11-27 13:52:29 UTC
The error still exists in Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 17dfc9a9da009cc23d2222e3fb4e2cef9c97d581
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded