Created attachment 112954 [details] PDF formatting of LO 4.3 and LO 4.4 After converting a Writer document with LO 4.4 to PDF some text formatting is lost. I returned to LO 4.3 since PDF exporting is crucial to me. See attached image.
Your screenshot show width justified text in 435 and left justified text in 440 - just checking, but I take it that the paragraph attributes weren't changed in between in the actual ODT ? In order for us to be able to test this, we would need your document, or a similar reduced size one that displays the odd behaviour. Setting to NEEDINFO, if information requested is provided, please set back to UNCONFIRMED
Created attachment 112962 [details] testfile, justified text, bigger spaced text
Not reproducible for me with version 4.4.1.0.0+ built at home under Ubuntu 14.10 x86-64. Best regards. JBF
Can not reproduce on Windws 7 sp1, 64-bit en-US with Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: en_US or with Version: 4.5.0.0.alpha0+ Build ID: 4b9a9ce8a0e5e0716dad9a9ec87d16237e534dc2 TinderBox: Win-x86@39, Branch:master, Time: 2015-01-31_09:49:44 Locale: en_US Correctly formatted gs based print to PDF, and correct formatting on Export to PDF
Confirmed > NEW OSX 10.10.2, LO latest nightly from 2015-01-31 Open test file, use LO's own pdf export. Open exported PDF, both issues can be confirmed. Alignment of text on right side is not justified and spacing in mail address is gone.
*** Bug 89051 has been marked as a duplicate of this bug. ***
Confirmed in LO 4.4 Mac OS Yosemite Versión: 4.4.0.3 Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Configuración regional: es_
Note that I originally saw this under Mavericks.
I confirm the bug
*** Bug 89569 has been marked as a duplicate of this bug. ***
*** Bug 89587 has been marked as a duplicate of this bug. ***
The bug is still present in LibreOffice 4.4.1, Mac OS X version : Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale : fr_
(This is an automated message.) LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs). As this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc), its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched. You can find out more about MABs and how the process works by contacting the QA Team on IRC: http://webchat.freenode.net/?channels=libreoffice-qa The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list): https://wiki.documentfoundation.org/QA
(This is NOT an automated message.) If the LO team is not interested in their own Bugzilla, why then reporting bugs anyway? On the other hand LO 4.3 runs well on OSX. So anyone relying on the PDF feature (like I do) should stay with 4.3 and be happy. LO 4.3 should run problem free the next 10 years on all upcoming OSX versions.
(In reply to deepflight5 from comment #14) > (This is NOT an automated message.) > > If the LO team is not interested in their own Bugzilla, why then reporting > bugs anyway? On the other hand LO 4.3 runs well on OSX. So anyone relying on > the PDF feature (like I do) should stay with 4.3 and be happy. LO 4.3 should > run problem free the next 10 years on all upcoming OSX versions. There's a simply workaround for this bug, try to use OSX own pdf printer instead. Just press cmd+p for the printer dialog and choose save as pdf.
But that's a very feature-deprived workaround as the export doesn't then include things like a table of contents, active links for cross-references, etc.
I do a weekly newsletter that includes SVG vector graphics. Exported via the OSX Quartz engine all SVG ends up as garbage in Apple's Preview. Exported via the GhostScript of LibreOffice all SVG is in Preview just fine. So this workaround is not really working for me and my readers. (In Adobe Acrobat Reader the OSX exported PDF just looks perfect, but many readers of my newsletter are OSX users and rely on Preview.)
This bug is very annoying. Could some devemopers try to resolve it ASAP ? Regards
*** Bug 89876 has been marked as a duplicate of this bug. ***
Hi, This bug is still present il LO 4.4.2.1 Mac OS X. Regards
Experience with similar PDF/GhostScript problems in former incarnations of OOo/LO teaches, that this bug might be around for a very long time. So better stick to LO 4.3 on OSX since this is the last version working correctly. Except from the newly designed buttons and minor fixes you will miss nothing of importance. LO 4.3 runs just fine. Only update to 4.4+ on your Windows and Linux computers.
(In reply to deepflight5 from comment #21) > Experience with similar PDF/GhostScript problems in former incarnations of > OOo/LO teaches, that this bug might be around for a very long time. So > better stick to LO 4.3 on OSX since this is the last version working > correctly. Keyword -> regression Whiteboard -> bibisectRequest (**NOTE: If someone wants to track this down with existing OSX bibisect work. For further information, someone could git-bisect this bug directly!)
Removing “Blocks 42082”. See bug 42082 comment 14 for why.
(In reply to deepflight5 from comment #14) > If the LO team is not interested in their own Bugzilla, why then reporting > bugs anyway? Who ever said we’re not interested? You’re right. NOBODY. You’re just reacting like a jerk who can’t even bother to read what the message was about.
It is very surprising that this bug has not already been added to MAB 4.4. We receive many questions on this subject on our FR users mailing-list. Done yet. Best regards. JBF
The bug appears also in Draw Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: it_ Osx 10.10.2
(In reply to Veronika from comment #26) > The bug appears also in Draw > Version: 4.4.0.3 > Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 > Locale: it_ > > Osx 10.10.2 Confirming that "Export to PDF" of text entered in Draw document as justified, looses some of its formatting in the resulting PDF.
The bug still exists in version 4.4.2.2. :-(
4.4.3.1 still affected
*** Bug 91164 has been marked as a duplicate of this bug. ***
I can confirm this bug affects the 64-bit versions of LO 4.4.2.2 and 4.4.3.2 on OS X 10.9.5 (Mavericks). I cannot, however, provide a copy of the document in question as it relates to an imminent legal matter. The work-around has been to revert to LO 4.3.7 which works normally (and with less crashes than OOo 4.1.1, as well as less irritation than saving as docbook and converting to pdf with pandoc via LaTeX).
This is really serious bug for Mac's users. I don't see we can expect fix in LO 5.0. It is a bad signal for LO reputation. Seriously, the newer LO wouldn't be released without fix of this.
I completely agree with deepjungle.maca! That is really really annoying bug. I also had to downgrade to 4.3.
In addition to the versions I confirmed in comment 31, we can now add: Version: 5.0.0.0.alpha1+ Build ID: 2ca7795a6a723c701f295323fcc3f6c52ad37976 TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-05-18_00:48:47 Locale: en-US (en.UTF-8)
Attempting to do a version bisection, you too can download old versions here: https://downloadarchive.documentfoundation.org/libreoffice/old/ 3.6.7.2(x86): correct formatting! 4.0.0.0(x86): correct formatting! 4.3.7.2: correct formatting! 4.4.0.0beta1: BAD formating 4.4.0.2: BAD formating 4.4.3.2: BAD formating Unfortunately, the first beta of 4.4 has the bug. So, the bug was introduced between 4.3 and 4.4 making it harder to track down the commit that did it. Changing version from 4.4.0.3 to 4.4.0.0beta1. I could not find the 4.4 alpha series.
*** Bug 91402 has been marked as a duplicate of this bug. ***
Two work-arounds for this ... First, the easy and obvious one, which we all no doubt already use: keep a copy of 4.3.x handy for exporting to PDF. Advantage: the output is always what we expect. Disadvantages: it's a 650MB work-around which needs to be installed somewhere, ideally in a location that won't conflict with 4.4 and may have unintended consequences when accessing user profiles, especially if both are open or active at the same time. Second, the more fiddly one, which takes a lot of trial and error to get right: it is possible to convert to PDF via Pandoc and LaTeX in a form closer to what was intended. Requirements: Pandoc (available from pandoc.org), latexdiff (available from macports.org or tug.org), latexmk (available from macports.org or tug.org), texlive-latex (available from macports.org or tug.org), texlive-latex-extra (available from macports.org or tug.org), texlive-latex-recommended (available from macports.org or tug.org). Alternatively the much smaller BasicTeX package (available from tug.org) can be substituted for a full installation, but it may require additional work to support all available fonts. Method: save ODF as Microsoft .docx, edit as necessary (at minimum remove footers and page numbering) and then in the Terminal run (in the directory where the file is): pandoc -f docx -t latex -o file.pdf file.docx Note: that images are not included, points and bullets lose their content and tables take a bit of fiddling to word wrap correctly (may require faking it with multiple table rows and hiding the borders). The output will always look like a LaTeX document, noticably different from LibreOffice and other PDFs. Page numbering is automatic by default with numbers in the centre at the bottom of the page. Also note that the best results with pandoc were achieved with Microsoft's docx format, both Docbook and HTML conversions resulted in extremely annoying editing challenges before producing the PDF (though a preliminary run using HTML could produce a LaTeX file with the relevant code to insert images to be pasted into another LaTeX conversion from a .docx file). Advantages: Does not require two versions of LibreOffice, avoids user profile conflicts, saves space from second copy of LibreOffice (if BasicTex used or if LaTeX was installed anyway). Disadvantages: LaTeX tools and libraries take more space than a second copy of LibreOffice (unless BasicTex is used), requires additional editing specific to producing the PDF, loses pictures (can be restored by exporting to LaTeX .tex first and editing the LaTeX code manually or with a LaTeX editor). Recommendation: If you don't use LaTeX for anything else already and/or have no familiarity with it, do not use this workaround. If you have used LaTeX and are cautious with available disk space, try the BasicTex variant of this work-around. If you are more familiar with LaTeX then you might consider this work-around. So, which do I use? Both, with a full LaTeX installation, it depends on the target audience of whatever the document is. If I don't use LaTeX I have to shutdown LibreOffice 4.4 before launching 4.3. I've got 4.3.7.2 installed in /Applications/ and 4.4.3.2 installed in $HOME/Applications/ (to apply the language pack I copied the pack's bzipped tarball from the installer into $HOME/Applications/LibreOffice.app/ and extracted it via the Terminal).
LO 5.0 beta1 was released and no fix for this issue. Please, can any of LO developers gives us when they want to fix this? Because PDF export has becomes a bit useless function since LO 4.4 for Mac user. For me it is a crucial function.
*** Bug 91589 has been marked as a duplicate of this bug. ***
I managed to build 4.4.0.0alpha2 and it has the formatting error. 4.4.0.0alpha1 would not compile for me. Timeline of bug: 20 Nov 2014: 4.4.0.0beta1 tag created (release has bug) 6 Nov 2014: 4.4.0.0alpha2 tag created (compile has bug) 19 Oct 2014: 4.4.0.0alpha1 tag created (unknown) 13 Oct 2014: 4.4 branch freeze remember 4.3 branch does not have this bug, so I want to assume the bug was introduced in October 2014. Possible files involved: vcl/source/outdev/text.cxx vcl/source/gdi/sallayout.cxx "To justify a text string, Writer calls OutputDevice::GetTextArray()" vcl/source/gdi/pdfwriter.cxx vcl/source/gdi/pdfwriter_impl.cxx I do not know enough about these files to make a judgement, but there were a lot of changes. I was playing around with git to see the changes between the file and the October 4.3 branch (version 4.3.3.2): git diff libreoffice-4.4.0.0.alpha2 libreoffice-4.3.3.2 vcl/source/gdi/pdfwriter_impl.cxx
I just confirmed that this applies to both Calc and Presentation as well. So, perhaps we can remove Writer/Draw from title of bug, but it applies to all justified text.
An additional rendering glitch concerns italics and superscripted words within justified text, the test.pdf shows gaps before superscripted characters but this also happens with italicised text too.
Created attachment 116651 [details] test.pdf shows excessive gaps before superscripted words see previous comment
This seems to have been introduced by the below commit. Adding Cc: to nthiebaud@gmail.com; Could you possibly take a look at this one? Thanks commit cd3d26b7edbce67805259a71e4118223e02ebdd4 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Jul 18 18:21:12 2014 +0200 vcl consitent use of long for corrdinate most of length in vcl are calculated in 'long' but array of X position tend to be in sal_Int32. As a prep work to be able to support 'double' as the base type of Device Coordinate, harmonize the use of 'long' for non-float coordinate. Change-Id: I7cb33301ff6a5e2c62247b36a4e07e168a58a323
Norbert Thiebaud committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ab39f8c213bffa00f2b196c05a23ab3ccda8f901 tdf#88941 Revert "vcl quartz: Add support back for DXArray tweaking" It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Norbert Thiebaud committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e67b3ef2fd38510634106dbf422762af1e4633e9&h=libreoffice-5-0 tdf#88941 Revert "vcl quartz: Add support back for DXArray tweaking" It will be available in 5.0.0.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This seems to be corrected now, at least the 5.1 alpha build of this morning (http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/2015-07-05_10.41.24) correctly justifies the test .odt file when exporting to pdf. (I did not make more tests) Since 5.x stable may be a bit far off, it would be good to push this back also to the 4.x branch. Thanks for the patch and finding the bug.
verified fix as of comment 47. thanks so much Norbert, for looking into this bug affecting a lot of OS X users.
Un énorme merci à Norbert Thiebaud qui a corrigé ce bug gênant. A huge thank you to Norbert Thiebaud who corrected this annoying bug.
Just FYI, here is an interview of Norbert : https://blog.documentfoundation.org/2010/11/25/developer-interview-norbert-thiebaud/
The weird gaps before superscripted or italicised words is no longer present either, can confirm fixed here. so I can finally delete 4.3.x! It would be good to see this go into 4.4.x too. A thank you to Norbert for taking the time to revert this.
Confirmed that this has fixed the errors I was seeing (with the same document referred to originally) in this build: Version: 5.1.0.0.alpha1+ Build ID: 0251e61640b94094918406b33ee7b05564409feb TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-07-06_23:27:49 Locale: en-US (en.UTF-8) Thanks for the fix, I'm looking forward to a stable deployment later in the year.
*** Bug 92790 has been marked as a duplicate of this bug. ***
*** Bug 92901 has been marked as a duplicate of this bug. ***
Print to PDF is not a option from Impress because doesn't use native print dialogs and page format is fixed to Portrait. Impress is generally Landscape.
*** Bug 93026 has been marked as a duplicate of this bug. ***
This problem is still happening through today, July 30th, 2015, so it does not seem to be fixed, at least not for Writer. I hope this can be fixed in version 5.0, as noted in some of the comments below. Thank you.
(In reply to maxx366 from comment #57) > This problem is still happening through today, July 30th, 2015, so it does > not seem to be fixed, at least not for Writer. I hope this can be fixed in > version 5.0, as noted in some of the comments below. Thank you. @maxx: in which version of 5.0 ? The fix was only supposed to be integrated as from 5.0.0.3, so it should be in rc4 currently available to download. If it isn't then we need to bump this open again, or try and find out why the fix hasn't yet gone into 5.0.x
(In reply to Alex Thurgood from comment #58) > (In reply to maxx366 from comment #57) > > This problem is still happening through today, July 30th, 2015, so it does > > not seem to be fixed, at least not for Writer. I hope this can be fixed in > > version 5.0, as noted in some of the comments below. Thank you. > > @maxx: in which version of 5.0 ? The fix was only supposed to be integrated > as from 5.0.0.3, so it should be in rc4 currently available to download. If > it isn't then we need to bump this open again, or try and find out why the > fix hasn't yet gone into 5.0.x Thanks for the quick reply. I was only perusing the comments with my reference to version 5.0 -- I am not testing it because I'm just a normal user and probably lack the knowledge to best apply the advance releases. Based on your comment, however, perhaps I will try rc4. Thanks.
(In reply to Alex Thurgood from comment #58) > (In reply to maxx366 from comment #57) > > This problem is still happening through today, July 30th, 2015, so it does > > not seem to be fixed, at least not for Writer. I hope this can be fixed in > > version 5.0, as noted in some of the comments below. Thank you. > > @maxx: in which version of 5.0 ? The fix was only supposed to be integrated > as from 5.0.0.3, so it should be in rc4 currently available to download. If > it isn't then we need to bump this open again, or try and find out why the > fix hasn't yet gone into 5.0.x Perhaps I wasn't clear; sorry. When I wrote that the problem was still happening through today, I meant with all versions of Libre 4.4, including the one that was released earlier today (4.4.5). To avoid it, I opted to revert to version 4.3.7 until the bug is fixed. Thanks.
(In reply to maxx366 from comment #60) > (In reply to Alex Thurgood from comment #58) > > (In reply to maxx366 from comment #57) > > > This problem is still happening through today, July 30th, 2015, so it does > > > not seem to be fixed, at least not for Writer. I hope this can be fixed in > > > version 5.0, as noted in some of the comments below. Thank you. > > > > @maxx: in which version of 5.0 ? The fix was only supposed to be integrated > > as from 5.0.0.3, so it should be in rc4 currently available to download. If > > it isn't then we need to bump this open again, or try and find out why the > > fix hasn't yet gone into 5.0.x > > Perhaps I wasn't clear; sorry. When I wrote that the problem was still > happening through today, I meant with all versions of Libre 4.4, including > the one that was released earlier today (4.4.5). To avoid it, I opted to > revert to version 4.3.7 until the bug is fixed. Thanks. This issue was fixed in today's general release of version 5.0 -- thank you very much!
Is there a reason this is not being backported — you have a fix for a major platform bug in the 4.4 series yet haven't backported it yet?
(In reply to maxx366 from comment #61) > (In reply to maxx366 from comment #60) > > (In reply to Alex Thurgood from comment #58) > > > (In reply to maxx366 from comment #57) > > > > This problem is still happening through today, July 30th, 2015, so it does > > > > not seem to be fixed, at least not for Writer. I hope this can be fixed in > > > > version 5.0, as noted in some of the comments below. Thank you. > > > > > > @maxx: in which version of 5.0 ? The fix was only supposed to be integrated > > > as from 5.0.0.3, so it should be in rc4 currently available to download. If > > > it isn't then we need to bump this open again, or try and find out why the > > > fix hasn't yet gone into 5.0.x > > > > Perhaps I wasn't clear; sorry. When I wrote that the problem was still > > happening through today, I meant with all versions of Libre 4.4, including > > the one that was released earlier today (4.4.5). To avoid it, I opted to > > revert to version 4.3.7 until the bug is fixed. Thanks. > > This issue was fixed in today's general release of version 5.0 -- thank you > very much! I confirm that the bug was fixed in version 5.0 Thanks!!
@norbert: could this be backported to 4.4 ?
*** Bug 95817 has been marked as a duplicate of this bug. ***
*** Bug 95838 has been marked as a duplicate of this bug. ***
You reply to my bug report 95838 that this is a duplicate of bug 88941. 88941, however, concerns only PDF export. The bug I reported can be seen in LO during text editing as words cut with an invisible right portion. It is claimed that this bug has been corrected in LO 5.0, however, as I have indicated, it is still there in LO 5.0.1
Created attachment 120580 [details] Illustration that right margin justification is faulty in 4.3.7.1 as well
(In reply to uwehob from comment #68) > Created attachment 120580 [details] > Illustration that right margin justification is faulty in 4.3.7.1 as well No, that is all correct--this is fixed. The patch for incorrect justification in PDF was not back ported to the LO 4.4 releases. Your PDF example shows the correct handling of justified text in PDF for 5.0.3 (as patched at 5.0.0.3). As to issues of bug 95838, agree with Ben M that is a different issue, and closing as duplicate was incorrect. Comments there.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]