Bug 36742 - PDF export of minimal width lines
Summary: PDF export of minimal width lines
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Cédric Bosdonnat
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-05-01 07:11 UTC by Martin Whitaker
Modified: 2016-05-01 12:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple text document to demonstrate the bug (8.66 KB, application/vnd.oasis.opendocument.text)
2011-05-01 07:11 UTC, Martin Whitaker
Details
Result of exporting document to PDF (1.65 KB, application/pdf)
2011-05-01 07:13 UTC, Martin Whitaker
Details
Screenshot of PDF viewed using Adobe Reader (26.18 KB, image/png)
2011-05-01 07:15 UTC, Martin Whitaker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Whitaker 2011-05-01 07:11:46 UTC
Created attachment 46218 [details]
Simple text document to demonstrate the bug

When exporting documents containing table borders or line-based graphic objects where the line width is set to minimum (0.05pt), it is expected that when viewing the PDF, all lines will appear the same. However this is not the case - some lines appear thicker than others. Different lines will be affected as the table or graphic is modified or is moved around in the document.

Attached is a simple document containing a single empty table to demonstrate this. Also attached is the resulting PDF and a screenshot of the PDF being viewed using Adobe Reader.

This bug was/is not present in any of the recent vanilla binary releases of OpenOffice.org (3.1.1, 3.2.1, 3.3.0) but is present in the vanilla binary release of LibreOffice 3.3.2 and also in the Debian build of OpenOffice.org 3.2.1 (OOO320m19 (Build:9505), ooo-build 3.2.1.4, Debian package 1:3.2.1-6~bpo50+1), so was presumably introduced in a patch that was never applied upstream.

For tables it is possible to work round this bug by ticking the "Merge adjacent line styles" box in the table border properties, but as there doesn't seem to be a way of doing this globally, this isn't very practicable if you have a large number of existing documents to maintain.

I haven't found an equivalent workaround for graphic objects.
Comment 1 Martin Whitaker 2011-05-01 07:13:07 UTC
Created attachment 46219 [details]
Result of exporting document to PDF
Comment 2 Martin Whitaker 2011-05-01 07:15:26 UTC
Created attachment 46220 [details]
Screenshot of PDF viewed using Adobe Reader
Comment 3 Muthu 2011-05-05 01:03:56 UTC
Is it because of the "zoom" to 69% or something? 
Anyways, I do see some minute changes in line thickness and color (black vs. grey)... I will assign it to Cedric for more analysis.
Comment 4 Callegar 2011-10-10 07:45:32 UTC
I confirm the bug.

When exporting via PDF some graphs made with libreoffice draw, the line widths appear to be somehow erratic, with some lines slightly thicker, and some other looking thinner. Or at least, this is the rendering that you get on screen via most pdf viewers.

It is unfortunate that this makes some documents produced using libreoffice somehow less professionally looking than they should when read on screen.
Printing of the PDF appears to be OK, though.
Comment 5 Paolo T. 2012-02-16 06:29:54 UTC
I have the same problem. Tables with a 0.05 pt border, that with OpenOffice exported as thin lines in a PDF, are exported as thick lines from LibreOffice. The result is the same with Adobe Reader (9.5.0) or Apple Preview (OS X 10.6.8).

According to Adobe Acrobat Pro, the effective line widht is 0.0. I don't how to compare the same lines exported from OpenOffice, since Acrobat Pro does not show Stroke-type objects in this case (only Fill types are shown, and there is no stroke width).

According to the Properties dialog in Acrobat Pro, it also seem that the two PDF files have been generated using the same PDF version and parameters.

Paolo
Comment 6 Rainer Bielefeld Retired 2012-03-26 08:28:53 UTC
[Reproducible] with reporter's sample and "LibreOffice 3.4.1 RC1 - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:201)]" (JPG, 300dpi)

Worked fine with with "LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]", so this might have been a regression.

Again works fine with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) and
"LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) 
(others not tested.

Removed "Blocks Bug 35673" because because 3.4 lifecycle is terminated.
Worksforme because no longer reproducible.

@sergio, Paolo T.:
Please always contribute detailed information with what version and settings you reproduced a problem.

@reporter:
Please feel free to reopen this bug if you find out that the problem still exists with the current stable 3.5 LibreOffice version.
Comment 7 Jean-Baptiste Faure 2016-05-01 12:54:01 UTC
Comment #6 --> keyword regression added.

Best regards. JBF