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:
Created attachment 155924 [details] Testdocument
Created attachment 155925 [details] PDF Export with LO 6.3.3
Created attachment 155926 [details] PDF Export with LO 6.2.6
> 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:
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
(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...
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.
Dear burnuser, 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
Bug is still present in LO 7.2.2.2 (x64) de-AT on Win 10
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
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.
Dear burnuser2, 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