Download it now!
Bug 100891 - PDF: Baseline of graphics missing, when exporting downsized graphics
Summary: PDF: Baseline of graphics missing, when exporting downsized graphics
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.0.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2016-07-13 08:21 UTC by Wilfried Koch
Modified: 2018-04-06 14:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Test files: result (pdf) (387.85 KB, application/pdf)
2016-07-13 08:30 UTC, Wilfried Koch
Details
x (21 bytes, text/plain)
2016-07-13 08:39 UTC, Wilfried Koch
Details
source (297.40 KB, application/vnd.oasis.opendocument.text)
2016-07-13 08:40 UTC, Wilfried Koch
Details
Hopefully helpful files to clearly identify the problem (650.80 KB, application/x-zip-compressed)
2018-04-04 15:21 UTC, Wilfried Koch
Details
Screenshots from Okular (93.62 KB, image/png)
2018-04-04 18:34 UTC, Buovjaga
Details
Image extracted from the ODT (128.22 KB, image/jpeg)
2018-04-05 14:04 UTC, Buovjaga
Details
Arcive containing the relevant files (458.83 KB, application/x-zip-compressed)
2018-04-05 19:03 UTC, Wilfried Koch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wilfried Koch 2016-07-13 08:21:43 UTC

    
Comment 1 Wilfried Koch 2016-07-13 08:30:36 UTC
Created attachment 126190 [details]
Test files:  result (pdf)

Bildtest.odt (source) follows with next comment
Comment 2 Wilfried Koch 2016-07-13 08:39:02 UTC
Created attachment 126191 [details]
x

If a picture is in reduced size, after exporting to pdf the baseline is not shown. See lower picture in the pdf-attachment.

Steps
Insert (jpg-) Picture
reduce size
add description
export to pdf

I had problems to add the source attachment her. So it will follow with a dummy comment.
Comment 3 Wilfried Koch 2016-07-13 08:40:35 UTC
Created attachment 126192 [details]
source

source as described before.
Comment 4 Buovjaga 2016-07-18 03:57:10 UTC
What is this "baseline" you speak of?
Your PDF looks exactly like the source document. Same with my own PDF export.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: ab1b351840160655a9f0caedbb35e9fdf203c5a0
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on July 16th 2016
Comment 5 Wilfried Koch 2016-07-18 05:53:23 UTC
Baseline in my terms is the lowest line in the original picture.
It appears in PDF if the picture und the odt is in original size. It disappears very often if the picture in the odt is smaller than the original.

This problem seems to be more severe with jpg than with gif. But this is more an impression than a statement after an in depth test.
Comment 6 Buovjaga 2016-07-18 10:36:03 UTC
(In reply to Wilfried Koch from comment #5)
> Baseline in my terms is the lowest line in the original picture.
> It appears in PDF if the picture und the odt is in original size. It
> disappears very often if the picture in the odt is smaller than the original.

But why does your PDF display the lowest line, then? I thought the point was to attach the problematic PDF?
I also tried making the picture even smaller and my PDF export still shows the lowest line.

Win 7 Pro 64-bit Version: 5.3.0.0.alpha0+
Build ID: 28ac6fdc11559b58ac62089300aa99530b0b822d
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-07-18_02:54:20
Locale: fi-FI (fi_FI); Calc: CL

Win 7 Pro 64-bit, Version: 5.1.3.2 (x64)
Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: fi-FI (fi_FI)
Comment 7 Dieter Praas 2017-09-09 09:28:45 UTC
I agree to Buovjaga. I can't see a difference between the odt-document and the pdf-file. So could you mark in the pdf-file the difference between the two pictures? Is the bug still valid with an actual version of LO?

Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Comment 8 QA Administrators 2018-04-04 13:09:00 UTC Comment hidden (obsolete)
Comment 9 Wilfried Koch 2018-04-04 15:21:27 UTC
Created attachment 141083 [details]
Hopefully helpful files to clearly identify the problem

5.2.0.1.rc is no longer available on my Computer. But the Problem is also present in 6.0.0.1.

bugtest.ods Shows an electric circuit.On e in original an two in differently reduced sizes. In all three cases the resistor R is represented by a complete rectangle. Complete means the the rectangle also has a lower line.

bugtest.pdf is created from bugtest.ods using the means of LibreOffice Writer.
In the oroginal size circuit the lower line is a little bit thinner than the other lines in the rectangle. In the two reduced circuits the lower line is missing. All other lines in the drwaing are not affected.
Comment 10 Wilfried Koch 2018-04-04 15:24:47 UTC
This is just to hange the Status.
You find detailed Information in the message sent some minutes ago
Comment 11 Buovjaga 2018-04-04 18:34:28 UTC
Created attachment 141092 [details]
Screenshots from Okular

Here are two combined screenshots showing a fully-zoomed Okular PDF reader with the smallest drawing in focus. The lower line does exist - it is just a little thinner.

I noticed my export from 6.1 is more crisp, but maybe it is JPEG settings or something. My quality is 90 %.
Comment 12 Wilfried Koch 2018-04-04 19:40:26 UTC
Even if there exists a line. The problem still remaining is:
Why are lines at the lower border of the picture treated differently from lines anywhre else. Lines elsewehere are not made thinner when the size of the picture is reduced.
Comment 13 Buovjaga 2018-04-05 14:04:04 UTC
Created attachment 141131 [details]
Image extracted from the ODT

I unzipped the ODT and this was in Pictures.

In the document, it is somehow and image embedded in an SVG:
<draw:frame text:anchor-type="paragraph" draw:z-index="0" draw:style-name="gr1" draw:text-style-name="P1" svg:width="12.212cm" svg:height="6.016cm" svg:x="3.203cm" svg:y="-0.45cm">
    <draw:image xlink:href="Pictures/1000000000000B450000058D22823768ACF05B76.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">
        <text:p />
    </draw:image>
</draw:frame>

I would rather create an image that has white space at the bottom as well to see, how it helps.
Comment 14 Wilfried Koch 2018-04-05 16:05:38 UTC
Creating the odt-document is (and was) OK.
The problem is still the generation of the pdf from the odt.
White space at the bottom of a picture can be used as a workaround.
The picture example was drawn in libreoffice draw, and then exported to .jpg.
afterwards it was inserted into a newly created writer document.
Comment 15 Buovjaga 2018-04-05 18:20:34 UTC
(In reply to Wilfried Koch from comment #14)
> Creating the odt-document is (and was) OK.
> The problem is still the generation of the pdf from the odt.
> White space at the bottom of a picture can be used as a workaround.
> The picture example was drawn in libreoffice draw, and then exported to .jpg.
> afterwards it was inserted into a newly created writer document.

If you want to continue investigating, attach the original Draw document.
Comment 16 Wilfried Koch 2018-04-05 19:03:28 UTC
Created attachment 141148 [details]
Arcive containing the relevant files

RC-Glied.odg Original Image.

This image ist exported to png (RC-Glieda.png) and jpg (RC-Glieda.jpg)

Export process:

Select all, then export selection.
In both cases the size of the image is kept, but the resolution is increased from 96 to 300 dpi. This has to do with the use of the document.

Bildtest2.odt is openend emptily. In the upper part the jpg, in the lower the png is inserted. Both pictures are reduced in size to 25% using the properties dialog.
Bildtest2. pdf is created by clicking on the pdf-button. It shows the lowest line missing in the image with jpg-origin, but present in the picture with png-origin.