Description: When drawing a dashed line in either impress or draw and attempting an export to an EPS file, the exported .eps file is written with a meaningless value for the PostScript dash pattern, resulting in a line that essentially appears as a solid line in a Postscript viewer. Steps to Reproduce: 1. In either impress or draw, create a new document, draw a line, and set the line type to anything like 'dash', 'shortdash', 'longdash' etc. 2. Export the document to an EPS file 3. View the EPS file in any PS viewer or import into a Latex document Actual Results: The exported graphics appears with the line essentially solid. In the exported EPS file the line dash pattern is set with a Postscript command '[ 2 ] 0 ld'. (The string 'ld' has been bound to the native Postscript command 'setdash'.) The matrix argument '[ 2 ]' is supposed to specify the line length intervals of the on and off dash pattern. In the coordinate system a length of 2 is an absurdly short distance, and results in the line appearing as solid. The same argument is supplied no matter what libreoffice line type is set on the line. Expected Results: The Postscript argument to 'setdash' should be a matrix with a pattern of meaningful lengths, like 100, 200, whatever, and have various patterns according to the line type selected in libreoffice, so that the line appears in the Postscript image with the same dash pattern as in the libreoffice document. Reproducible: Always User Profile Reset: No Additional Info: A workaround is to manually edit the exported Postscript file before importing into Latex and making the matrix argument '[ 200 ]'. This will appear as at least a simple dashed line with some reasonable intervals.
One additional condition for this bug: The dashed line must also be set with a width greater than the default 0. Dashed lines with 0 width actually get exported with proper dash patterns in the EPS file. But for dashed lines set even one step thicker, at 0.2 inch, the exported dash pattern is incorrect as described.
Tested with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 1c0aa970650ffc7c749e0b5ea655ebb2d137c8ae CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo And I see dashed line in Evince viewer. Seems to be fixed with dev version. Please could you test it with dev version? You can download it here: http://dev-builds.libreoffice.org/daily/master/ Thank you
Created attachment 178252 [details] export from LO 7.4 dev version
I installed the 7.4 Development version into a clean temporary Fedora 35 Live OS, and it appears to me to behave the same as 7.1.8.1. I did indeed get a proper dashed line in the .eps file export as you did for a line left at the default width of 0, but as per my comment I added on 2022-01-29, another requirement to expose this bug is to set the line width up from its default to something thicker, like the first step of 0.02". When doing this with the version 7.4 the dashed line export is again erroneous, with the PostScript dash pattern set to "[2]", and appearing as a solid line in the atril viewer present in Fedora 35 Live.
Please attach test file.
Created attachment 178461 [details] Test .odp file and exported .eps file showing dashed line export failure The attached .tgz tarball file contains two files, DashedLineTest.odp and DashedLineTest.eps. The LO .odp file has two drawn lines, both set to the "Long Dash" mode. One is at the default width of 0, and the other with the width set up to 0.02 inch. When the exported .eps is viewed in gv, qpdfview, or atril, the first line appears as dashed and the second shows up as solid. Examining the .eps file text, the first line has a proper PostScript setdash command '[ 107.8 80.85 ] 0 ld', but the setdash command for the second line is an erroneous '[ 2 ] 0 ld'. The absurdly small value of 2 for a dash interval results in the essentially solid line appearing in a PostScript viewer.
I can confirm with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 0723b41bed9bb4ad50d2993744a60177966d1a21 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo but not in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit. Adding Cc: to Luboš Luňák; Could you possibly take a look at this one? Thanks 94d03624daba3738e1882fa404b7b3d7d3ff6948 is the first bad commit commit 94d03624daba3738e1882fa404b7b3d7d3ff6948 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Apr 29 20:14:17 2021 +0200 source b71d9a6d15cfb8a50afdea5ac064f40d84c561f8 https://git.libreoffice.org/core/+/b71d9a6d15cfb8a50afdea5ac064f40d84c561f8 do not apply line dashing in drawinglayer (tdf#136957)
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ff8b9f6fca5784f62427302026642de0cdb1ef11 use dashing info from struct LineInfo in EPS writer (tdf#146804) It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tested the RPMs in the 7.4.0 development version with a clean Live Fedora 35 OS, and the problem looks to be nicely fixed. Thank you Luboš! Dashed thickened lines in my document figures now appear in the exported EPS file just as in the LO display.