Using LibreOffice on Arch Linux x64. Exporting doc to pdf with either cups-pdf or built-in pdf converter, underline doesn't stop at margin, so empty space is underlined after the text. This bug is reported here, too : [url]http://qa.openoffice.org/issues/show_bug.cgi?id=68503[/url] [url]http://user.services.openoffice.org/en/forum/viewtopic.php?f=7&t=36431[/url]
Hi, Is there any chance that it will be fixed? Or is there a solution how to deal with it until a fix is created? Thank you.
Bug still exist in the latest release, 3.3.1.
Please don't add comments like that. If there is no indication in a bug report that the bug has been fixed, it is safe to assume it has not been fixed in a micro update. Adding such comments just increases the amount of pointless mail developers need to "read". (As does this comment, of course, ha ha.)
I can confirm this bug. Also in Archlinux x86_64. Version is the same: 3.3.1
Confirmed on irc channel freenode#libreoffice: confirmed w/ distro-packed LO 3.3.2.2 (OOO330m19 Build:202), openSUSE 11.4/Tumbleweed x86_64 Also, I checked it on Win7 LO 3.3.2, same outcome.
Could you please attach a test document that shows this behavior?
Created attachment 49967 [details] The odt document Exporting this document to pdf shows the underline goes over the margin.
Created attachment 49968 [details] The result You can see in this pdf file that underline doesn't stop at margin.
I see it with LO-3.4.2 as well.
Created attachment 50445 [details] PDF screenshot in LO Draw
(In reply to comment #10) > Created an attachment (id=50445) [details] > PDF screenshot in LO Draw This might be obvious from the screenshot. The last justification area appears to duplicate itself before a new line.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Confirmed on GNU/Linux 64bit with 3.5.0-beta1
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) and with "LibreOffice Portable 3.3.0 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]" Problem already visible in Print dialog print preview (but not in Page preview from menu or toolbar), and still a problem with in 3.6. Modified Version due to <http://wiki.documentfoundation.org/BugReport_Details#Version> 3.4 lifecycle is terminated, so shift to “Bug 37361 LibreOffice 3.5 most annoying bugs” @Cédric: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Only for the sake of completeness: similar effects overline, strikethrough show the same problem.
This's not reproducible using 3.5.1.2 (350m1(Build:102))
No, actually it is, but here the margins in the original document are not respected.
"printing bleed" and "PDF export blees" still reproducible on 3.6.1.
OOo 3.4.0 shows the same problem, so inherited from OOo. Still reproducible with 3.6.3.1” German UI/ German Locale [Build-ID: f8fce0b] on German WIN7 Home Premium (64bit) It seems as if the print process for each line tails as much underlined space (with underlining) as there is found between the words in the line (more or less). We already shifted it from 3.4 MAB to 3.5 MAB, I now nominated this one as possible HardHack on <http://wiki.documentfoundation.org/HardHacks#General>
I tried to fix this in the patch https://gerrit.libreoffice.org/1300 There seems to be one additional whitespace (with variable width?) at the end of each line with soft line break. Underlining this whitespace leads to the problem described here. This is also visible for left- or right-aligned text, where one additional space at the end of line is underlined. For some reason this whitespace can be very big for block-aligned text... Changed the functions which draw textlines to omit a possible trailing whitespace.
hopefully the oldest MAB is going to be fixed. i hope the patch review will be positive.
Catch with your approach though is that underlining e.g. something ending in two spaces like " " gives just one space underlined, not both. fme's original comment in https://issues.apache.org/ooo/show_bug.cgi?id=68503 suggests that he thought that the extra space that are getting underlined are being placed there by the writer SwHolePortion layout class and that it might be possible to tweak that to not emit the spaces unless in some specific mode that requires it
lets try that approach
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d3a9e97164c0071d8b18f8dcf4197ec7c5c5c2f9 Resolves: fdo#32181 #i68503# don't emit pesky space unless in tagged pdf mode 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.
That seems to work, patch proposed for cherry-picking to various 3-x series
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=944e304f0541030f9efdec3f5474a99a93f4c28f&g=libreoffice-4-0 Resolves: fdo#32181 #i68503# don't emit pesky space unless in tagged pdf mode It will be available in LibreOffice 4.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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=df15a240c409ddfd71bb969f2427c7ad846321e6&g=libreoffice-3-6 Resolves: fdo#32181 #i68503# don't emit pesky space unless in tagged pdf mode It will be available in LibreOffice 3.6.5. 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fbb6995155ad98e339a33366db69be78df3f2ee8&g=libreoffice-3-5 Resolves: fdo#32181 #i68503# don't emit pesky space unless in tagged pdf mode It will be available in LibreOffice 3.5.8. 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.
Checked v3.6.5 daily build and I also found the bug fixed. Thank you.
Notes for unit test writers: Revert has to be done manually and it seems a bit complicated. PDF exports can be checked with pdfium, see for example sw/qa/extras/globalfilter/globalfilter.cxx