Bug 128879 - PDF Export Problems in LO 6.3.3 but working in 6.2.6
Summary: PDF Export Problems in LO 6.3.3 but working in 6.2.6
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:pdf, filter:svg
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2019-11-18 17:27 UTC by burnuser2
Modified: 2023-05-22 01:28 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Testdocument (44.48 KB, application/vnd.oasis.opendocument.text)
2019-11-18 17:27 UTC, burnuser2
Details
PDF Export with LO 6.3.3 (100.62 KB, application/pdf)
2019-11-18 17:28 UTC, burnuser2
Details
PDF Export with LO 6.2.6 (79.88 KB, application/pdf)
2019-11-18 17:28 UTC, burnuser2
Details

Note You need to log in before you can comment on or make changes to this bug.
Description burnuser2 2019-11-18 17:27:03 UTC
Description:
On Windows 10 (DE)
Exporting LO Writer Document with clipart from LO Gallery to PDF in LO 6.3.3 creates some artifacts in graphics. In LO 6.2.6 the graphics are OK AND the filesize is remarkable smaller!
(Tested with quality = 80% + 300 dpi)

Steps to Reproduce:
1. Create a Writer document with some graphics from the LO gallery
2. Export to PDF
3. Compare it with Writer document + compare it with PDF Export in LO 6.2.6

Actual Results:
artifacts in graphics + larger PDF file size

Expected Results:
no artifacts + smaller PDF file size


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Comment 1 burnuser2 2019-11-18 17:27:42 UTC
Created attachment 155924 [details]
Testdocument
Comment 2 burnuser2 2019-11-18 17:28:17 UTC
Created attachment 155925 [details]
PDF Export with LO 6.3.3
Comment 3 burnuser2 2019-11-18 17:28:47 UTC
Created attachment 155926 [details]
PDF Export with LO 6.2.6
Comment 4 Oliver Brinzing 2019-11-18 19:10:23 UTC
> creates some artifacts in graphics.
> In LO 6.2.6 the graphics are OK AND the filesize is remarkable smaller!

confirming, LO 6.2.8.2 is fine too.

Version: 6.2.8.2 (x64)
Build-ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc:
Comment 5 BogdanB 2019-11-19 05:44:23 UTC
Bibisected with 6.3
 d61a43fff034b6666038fe2ca3fedb844074b534 is the first bad commit
commit d61a43fff034b6666038fe2ca3fedb844074b534
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Thu Sep 26 02:47:46 2019 +0200

    source 92267cdb1a45e1f40199136849feb692f7e06d0e
    
    source 92267cdb1a45e1f40199136849feb692f7e06d0e

:040000 040000 31416364166b0bbfd7bce30b2c5db92a46f39c0e e6368b319137759bb893742c1e0ea178c605b67d M	instdir
Comment 6 raal 2019-11-20 16:12:53 UTC
(In reply to BogdanB from comment #5)
> Bibisected with 6.3
> 
> d61a43fff034b6666038fe2ca3fedb844074b534 is the first bad commit
> commit d61a43fff034b6666038fe2ca3fedb844074b534
> Author: Jenkins Build User <tdf@pollux.tdf>
> Date:   Thu Sep 26 02:47:46 2019 +0200
> 
>     source 92267cdb1a45e1f40199136849feb692f7e06d0e
>     
>     source 92267cdb1a45e1f40199136849feb692f7e06d0e
> 
> :040000 040000 31416364166b0bbfd7bce30b2c5db92a46f39c0e
> e6368b319137759bb893742c1e0ea178c605b67d M	instdir

This seems to have begun at the below commit.
Adding Cc: to Xisco Faul; Could you possibly take a look at this one? Thanks

author	Xisco Fauli <xiscofauli@libreoffice.org>	2019-09-19 11:45:20 +0200
committer	Michael Stahl <michael.stahl@cib.de>	2019-09-25 10:34:04 +0200
commit 92267cdb1a45e1f40199136849feb692f7e06d0e (patch)
tree 3092d726d365222d9ea302130ae38cf8e818c5c6
parent 1d6429fb86d0ba8c03da8621512f3b675d1bcb81 (diff)
tdf#94765: SVGIO: Look for gradient/pattern ids once the file...
Comment 7 Xisco Faulí 2019-11-20 16:33:01 UTC
IMHO, this is not a regression. my patch fixed a svg import problem ( also fixing the images in the file attached ) as this is a PDF export problem.
My commit just arose another existing PDF problem.
Comment 8 QA Administrators 2021-11-23 04:32:17 UTC Comment hidden (obsolete)
Comment 9 burnuser2 2021-11-24 12:11:29 UTC
Bug is still present in LO 7.2.2.2 (x64) de-AT on Win 10
Comment 10 Stéphane Guillou (stragu) 2023-04-27 00:46:25 UTC
Still present in:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5cd9de202765e243e41416802f3e4486b8a96f16
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 11 Dave Gilbert 2023-05-22 01:27:46 UTC
I've got some sympathy for the pdf code here...

Looking at the two PDF attachments, uncompressed and in meld, the biggest
differences are the newer one has a bunch of added bitmap/images embedded.

Digging into the example screwdriver in inkscape, there are two
paths which have hideously complex masking and filling on, and I think they do have
a forward reference which I guess Xisco's patch made the reference work and now the PDF code has tried to do masking.

In particular, inkscape says path 106 has mask g, fill i,
mask g has a reference to 
  fill: url#h (i.e. to the next fill - so not yet defined)

gradient h:
  has a graident transform and is linked back to a nice simple fill c


   <linearGradient id="c"><stop offset="0" stop-color="#fff"/><stop offset="1"/></linearGradient>

<mask id="g" height="50.138" maskUnits="userSpaceOnUse" width="45.542" x="20.098" y="17.939"><g filter="url(#a)">
  <path d="m30.168 19.316-10.438 9.329-5.914-6.618 10.439-9.328z" fill="url(#h)"/></g></mask>

<linearGradient id="h" gradientTransform="matrix(.7457 -.6663 .6663 .7457 4.3633 147.9164)" gradientUnits="userSpaceOnUse" x1="97.9258" x2="97.9258" xlink:href="#c" y1="-80.3257" y2="-83.1696"/>

so I guess it's something to do with the pdf exporters masking code or it's handling those complex fills.  Perhaps it just gave up and tried to spit out the image.