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.
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)
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.
Please provide complete details OS and build of LibreOffice.
Created attachment 126264 [details] Sceenshot on WIN10 machine Libre V5.122
Created attachment 126265 [details] screenshot Win8.1 Libre V 5.202
Created attachment 126266 [details] screenshot on FoxitReader
Created attachment 126267 [details] screenshot AdobeAkrobat Reader
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
I just tested an old Vista PC with V5.14 - same issue
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.
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?
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.
I asked Miklos on IRC and unfortunately he doesn't know about VCL. I also asked Tor and no luck.
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
Created attachment 136140 [details] Screenshot comparison LibO 6.0 alpha0 (Ubuntu) and Evince 3.18
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
upon QA team's , I tested the issue now on Libre Office Version: 6.1.0.3 (x64) problem is still there
Dear Ulrich Veith, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Version: 6.3.3.2 (x64) Build-ID: a64200df03143b798afd1ec74a12ab50359878ed CPU-Threads: 8; BS: Windows 6.3; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded Bug still exists
Version: 6.4.0.1 (x64) Build-ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU-Threads: 8; BS: Windows 6.3 Build 9600; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded Bug still exists
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
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.
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 ***
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.
(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.
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.