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
Created attachment 167579 [details] Bug report with illustrations contains the illustrations referenced in the bug report opened using the Bugzilla template
Created attachment 167580 [details] Sample file created in LibreOffice This is the sample to reproduce the Line with dots distance bug
Created attachment 167581 [details] styles.xml relevant for this bug
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
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
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.
Dear Alfred Hellstern, 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
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