Bug 100966 - PDF import - some Text allignment differs from other PDF readers
Summary: PDF import - some Text allignment differs from other PDF readers
Status: RESOLVED DUPLICATE of bug 82163
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Import-Draw
  Show dependency treegraph
 
Reported: 2016-07-17 11:20 UTC by Ulrich Veith
Modified: 2021-08-23 11:59 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
document from invoicing software generated by a report generator (189.08 KB, application/pdf)
2016-07-17 11:20 UTC, Ulrich Veith
Details
clip of allignment in LO 5.2.0.1 (and w/current master) (9.84 KB, image/png)
2016-07-18 03:30 UTC, V Stuart Foote
Details
same PDF open in Reader 11 (10.76 KB, image/png)
2016-07-18 03:33 UTC, V Stuart Foote
Details
Sceenshot on WIN10 machine Libre V5.122 (96.22 KB, image/png)
2016-07-18 05:47 UTC, Ulrich Veith
Details
screenshot Win8.1 Libre V 5.202 (138.08 KB, image/png)
2016-07-18 05:48 UTC, Ulrich Veith
Details
screenshot on FoxitReader (180.53 KB, image/png)
2016-07-18 05:49 UTC, Ulrich Veith
Details
screenshot AdobeAkrobat Reader (115.61 KB, image/png)
2016-07-18 05:50 UTC, Ulrich Veith
Details
Comparison Draw 5.3 vs PDF Chrome (40.59 KB, image/png)
2016-07-18 08:23 UTC, Heiko Tietze
Details
Screenshot comparison LibO 6.0 alpha0 (Ubuntu) and Evince 3.18 (66.24 KB, image/png)
2017-09-09 22:53 UTC, Thomas Lendo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Veith 2016-07-17 11:20:26 UTC
Created attachment 126246 [details]
document from invoicing software generated by a report generator

I am sending a pdf- file, where 2 items/ components were wrong in their right alligment, when imported into Draw, compared to Foxit Reader, PDF Xchange, Coral Draw, Reader ....
Pls check the allignment of the date and the sum of the attached doc.
Comment 1 V Stuart Foote 2016-07-18 03:30:18 UTC
Created attachment 126261 [details]
clip of allignment in LO 5.2.0.1 (and w/current master)

Can not reproduce with a recent build of master or 5.2.01 build.

Version: 5.3.0.0.alpha0+
Build ID: 54f83fee8451928b7078c0f9c96ec4187309bc00
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-07-11_05:29:10
Locale: en-US (en_US); Calc: group

Version: 5.2.0.1 (x64)
Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)
Comment 2 V Stuart Foote 2016-07-18 03:33:02 UTC
Created attachment 126262 [details]
same PDF open in Reader 11

same alignment noted in Adobe Reader 11 and the Reader app.

Not seeing an issue.
Comment 3 V Stuart Foote 2016-07-18 03:33:46 UTC
Please provide complete details OS and build of LibreOffice.
Comment 4 Ulrich Veith 2016-07-18 05:47:52 UTC
Created attachment 126264 [details]
Sceenshot on WIN10 machine Libre V5.122
Comment 5 Ulrich Veith 2016-07-18 05:48:49 UTC
Created attachment 126265 [details]
screenshot Win8.1  Libre V 5.202
Comment 6 Ulrich Veith 2016-07-18 05:49:52 UTC
Created attachment 126266 [details]
screenshot on FoxitReader
Comment 7 Ulrich Veith 2016-07-18 05:50:28 UTC
Created attachment 126267 [details]
screenshot AdobeAkrobat Reader
Comment 8 Ulrich Veith 2016-07-18 05:52:50 UTC
As per the attachments I see the problem on Win 8.1 as well as on Win10 running Libre office 5.1x-V5.14x - V5.202
Comment 9 Ulrich Veith 2016-07-18 06:57:10 UTC
I just tested an old Vista PC  with V5.14 - same issue
Comment 10 Heiko Tietze 2016-07-18 08:23:23 UTC
Created attachment 126269 [details]
Comparison Draw 5.3 vs PDF Chrome

No issue for master vs. rendered in Chrome, tested under W7. Date and sum are perfectly right aligned.
Comment 11 V Stuart Foote 2016-07-18 13:46:00 UTC
I do not end with misalligned values for date or total, on Windows 10 or 8.1, and whether I filter import into Draw (or Impress or Writer) with 5.2.0, nor if I use the new Image -> Insert filter in 5.3.0 master for inserting single PDF as image into Draw (or Impress or Writer).

The only thing I note, is that on round trip PDF -> filter opening in LO -> Export to PDF (with embedded fonts enabled) the fonts differ.

Your original PDF embeds:
Arial (Embedded Subset), Type: TrueType(CID), Encoding: Identity-H
Arial Fett (Embedded Subset), Type: TrueType(CID), Encoding: Identity-H

On my Windows 10 system round trip export from 5.2.0 (or if inserted in 5.3.0) the PDF embeds:
Arial MT (Embedded Subset), Type: TruType, Encoding: Built-in
ArialUnicodeMS (Embedded Subset), Type: TrueType, Encoding: Built-in

So, conceivable that once filter imported--your system is assigning a different font (with different metrics), or ours are--and on yours LibreOffice is not substituting and is having trouble composing with original font.

@Miklos, any thoughts? Would differences in on system fonts/font substitution manifest this way? Any specific testing/reconfiguration for OP? Or is this back to a rendering issue with WinSimpleLayout, and the CID TrueType fonts are trouble on the VCL canvas?
Comment 12 Ulrich Veith 2016-07-18 15:39:00 UTC
I do not know if the following will help.
The PDF is generated on our VM-WIN10 system and importing to DRAW is done on the same and only for testing on other machines i.e. Win 8.1 or Vista. For generating the PDF I normally was using the PDF generator from Foxit. 
Now I tried the Microsoft Print to PDF - the result is even worse in the sense that more lines are not allinged.
Comment 13 Buovjaga 2016-09-16 07:45:08 UTC
I asked Miklos on IRC and unfortunately he doesn't know about VCL. I also asked Tor and no luck.
Comment 14 Thomas Lendo 2017-09-09 22:51:09 UTC
I can confirm the false alignment on Ubuntu Linux 16.04 64-bit.
I'll attach a screenshot.
Set bug to NEW.

Version: 6.0.0.0.alpha0+
Build-ID: fc674ad1b795d74a50cb792368ce7eaee74ca904
CPU-Threads: 4; Betriebssystem:Linux 4.10; UI-Render: Standard; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-09_00:34:37
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

and

Evince 3.18.2
Comment 15 Thomas Lendo 2017-09-09 22:53:48 UTC
Created attachment 136140 [details]
Screenshot comparison LibO 6.0 alpha0 (Ubuntu) and Evince 3.18
Comment 16 QA Administrators 2018-09-10 02:37:22 UTC Comment hidden (obsolete)
Comment 17 Ulrich Veith 2018-09-10 10:50:33 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2019-11-25 03:30:56 UTC Comment hidden (obsolete)
Comment 19 Ulrich Veith 2019-12-09 07:45:47 UTC Comment hidden (obsolete)
Comment 20 Ulrich Veith 2020-01-03 18:34:42 UTC Comment hidden (obsolete)
Comment 21 Ulrich Veith 2020-09-08 10:42:46 UTC
Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 8; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded

also tested on a WIN10 machine

in both cases the bug still exists
Comment 22 Kevin Suo 2021-08-22 09:27:37 UTC
The date (i.e., 17.07.2016), headings (i.e., "Gesamt") and the total (i.e., "13,32 EUR") used the font named "Arial Fett", while the numbers "6,66 EUR" and "6,66 EUR" uses the font named "Arial".

Draw does not use the pdf embeded font. At time of PDF import in Draw, if the font "Arial Fett" is not installed on your system, then it fallback to another font, e.g. Arial. The position of the right margin will be slightly different if these two fonts have different metrics.

However, in a pdf reader application, as the font is embeded in the pdf as a subset, it used the embeded font, thus the right margin appears exactly the same for these paragraphs (as initially designed by the invoice issuing software).

The right margin should be the same in Draw if your system has the font "Arial Fett". But I am not 100% sure because I do not have that font to test.

In my opinion, this is not a bug.
Comment 23 Buovjaga 2021-08-22 11:34:19 UTC
Thanks, Kevin. I guess we can close as a dupe of the feature request bug 82163

*** This bug has been marked as a duplicate of bug 82163 ***
Comment 24 Ulrich Veith 2021-08-23 09:48:56 UTC
Thanks Kevin and  Buovjaga  for having an eye on this. 

I checked all the pc's, where I saw the issue (there is no pc, where I don't see the issue) and can confirm that the respective fonts are installed under windows/fonts/arial. 

I am not an expert, but I still allow to rise the question, if a non installed font could be an explanation, when other PDF-reading software on the same machines are not showing the issue and when even the pc, where the document was generated, shows the issue, when the PDF-document is opened on that same PC in the next moment.
Comment 25 Kevin Suo 2021-08-23 10:13:03 UTC
(In reply to Ulrich Veith from comment #24)
"Arial" font is different from "Arial Fett" font. There are two different fonts used in the document. In order to achieve exactly the same look you need to have both two fonts installed.

LibreOffice does not use the "embedded" pdf font. If "Arial Fett" is not installed in your system, it falls back to "Arial". In contrast, other pdf viewer applications used the "Arial Fett" font (which is embedded in the pdf as a subset font) for rendering.
Comment 26 Ulrich Veith 2021-08-23 11:59:12 UTC
I am aware that Arial is different to Arial Fett. On my pc in the folder C:\Windows\Fonts\Arial you can find:

- Arial Standard 
- Arial Fett 
- Arial Fett kursiv 
- Arial kursiv 
- Arial Schwarz 

So that should not be the reason - at least to my very basic understanding.