Created attachment 137272 [details] odt file I have many docs that created with Libreoffice 5.2 or even older. Now I notice that PDF export is messy. To test open the attached doc and try to print or export.
Created attachment 137273 [details] the error
Created attachment 137274 [details] PDF output
I notice also that this problem is appear when I am using justified text.
Regression introduced by: author Khaled Hosny <khaledhosny@eglug.org> 2016-12-19 23:36:34 (GMT) committer Khaled Hosny <khaledhosny@eglug.org> 2016-12-20 05:14:25 (GMT) commit 9eb4b14ffa57cd7bbdf0fc43096f5f1e65c8e388 (patch) tree 535d14ede1db48f0c1651b27f0ebd78579819b47 parent 2e9c02feca732f6dd012ccbe5d7c6853c64075a5 (diff) tdf#103765: Round positions instead of truncating Bisected with bibisect-linux-64-5.4. Adding Cc: to Khaled Hosny
*** Bug 113529 has been marked as a duplicate of this bug. ***
Hmm, that is weird! But I guess we should revert it and re-open bug 103765 until we find a better solution for since this issue is more serious than the other.
(In reply to Khaled Hosny from comment #6) > Hmm, that is weird! But I guess we should revert it and re-open bug 103765 > until we find a better solution for since this issue is more serious than > the other. I reverted (In reply to Xisco Faulí from comment #4) > Regression introduced by: > > author Khaled Hosny <khaledhosny@eglug.org> 2016-12-19 23:36:34 (GMT) > committer Khaled Hosny <khaledhosny@eglug.org> 2016-12-20 05:14:25 (GMT) > commit 9eb4b14ffa57cd7bbdf0fc43096f5f1e65c8e388 (patch) > tree 535d14ede1db48f0c1651b27f0ebd78579819b47 > parent 2e9c02feca732f6dd012ccbe5d7c6853c64075a5 (diff) > tdf#103765: Round positions instead of truncating > > Bisected with bibisect-linux-64-5.4. > > Adding Cc: to Khaled Hosny I reverted this commit locally (on Windows) and I still get the same buggy output, can someone else try locally?
(In reply to Khaled Hosny from comment #7) > (In reply to Khaled Hosny from comment #6) > > Hmm, that is weird! But I guess we should revert it and re-open bug 103765 > > until we find a better solution for since this issue is more serious than > > the other. > > I reverted (In reply to Xisco Faulí from comment #4) > > Regression introduced by: > > > > author Khaled Hosny <khaledhosny@eglug.org> 2016-12-19 23:36:34 (GMT) > > committer Khaled Hosny <khaledhosny@eglug.org> 2016-12-20 05:14:25 (GMT) > > commit 9eb4b14ffa57cd7bbdf0fc43096f5f1e65c8e388 (patch) > > tree 535d14ede1db48f0c1651b27f0ebd78579819b47 > > parent 2e9c02feca732f6dd012ccbe5d7c6853c64075a5 (diff) > > tdf#103765: Round positions instead of truncating > > > > Bisected with bibisect-linux-64-5.4. > > > > Adding Cc: to Khaled Hosny > > I reverted this commit locally (on Windows) and I still get the same buggy > output, can someone else try locally? This is weird. I've just tried locally as well and the issue is reproduced while reverting the commit if it's done from the UI, however from commandline it's not. Ie: instdir/program/soffice --headless --convert-to pdf /home/xisco/Baixades/test.odt --outdir /home/xisco/Escriptori/
Ok, I've bisected it again using the UI at export time and it points me to this commit instead: author Khaled Hosny <khaledhosny@eglug.org> 2016-12-07 22:43:09 (GMT) committer Khaled Hosny <khaledhosny@eglug.org> 2016-12-10 00:58:26 (GMT) commit b894104a0b02a9b074c76feb925389d7bee6a493 (patch) tree 93e8a9362281f2c992f503a4e38ec17d04a9132b parent b52167df08511239c3d08904a3d12a3c92141f38 (diff) Pass GlyphItem around We have this nice structure that contains (almost) all the information we need, so pass it around instead of passing separate fragments of said information. The ultimate is to kill the horrible sal_GlyphId hack if encoding various bits of information in the higher bits of a 32-bit integer. @Khaled, Does it make more sense now?
(In reply to Xisco Faulí from comment #9) > Ok, I've bisected it again using the UI at export time and it points me to > this commit instead: > > author Khaled Hosny <khaledhosny@eglug.org> 2016-12-07 22:43:09 (GMT) > committer Khaled Hosny <khaledhosny@eglug.org> 2016-12-10 00:58:26 (GMT) > commit b894104a0b02a9b074c76feb925389d7bee6a493 (patch) > tree 93e8a9362281f2c992f503a4e38ec17d04a9132b > parent b52167df08511239c3d08904a3d12a3c92141f38 (diff) > Pass GlyphItem around > We have this nice structure that contains (almost) all the information > we need, so pass it around instead of passing separate fragments of said > information. > > The ultimate is to kill the horrible sal_GlyphId hack if encoding > various bits of information in the higher bits of a 32-bit integer. > > @Khaled, Does it make more sense now? Yes, that makes a lot of since. I was expecting something around this area as it touched PDF export. Thank you!
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb72ec9b6222c8a18445c078c0367e7d507720af tdf#113428: Fix glyph positions in PDF export It will be available in 6.0.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.
(In reply to Commit Notification from comment #11) > Khaled Hosny committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=fb72ec9b6222c8a18445c078c0367e7d507720af > > tdf#113428: Fix glyph positions in PDF export > > It will be available in 6.0.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. what is this? I clearly do not get and understand it. can you give me more detail and a solution to this bug? best regards
Please do not change the status of the bug unless you test the next release and the bug is nit fixed there. Thank you.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=86707e80c32c8deeef9c0992ca3ff184f42faed7&h=libreoffice-5-4 tdf#113428: Fix glyph positions in PDF export It will be available in 5.4.4. 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.
Verified in Version: 6.0.0.0.alpha1+ Build ID: a7f961ddd88df4117de5f7c199881cf75d2905b5 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group