Apache OpenOffice (AOO) Bugzilla – Issue 68503
underline in pdf-exported odt (full-just)-often bleed over margin
Last modified: 2013-05-18 13:16:36 UTC
Problem occurs in both windows xp (Openoffice 2.0.3) and mepis (openoffice2.0.2). After export to PDF, and at justify-full, the underlines will often bleed over the right margin.
Created attachment 38426 [details] ODT file with underlined text.
Created attachment 38427 [details] output PDF file with bleeding margins (over right margin)
Reassigned to HI.
HI->PL: Occurs also with 680m181
OS changed from Linux to All
The extra underline after the underline is actually an extra underlined space that gets output. For some reason this does not happen on the printer (or the window). This seems strange.
FME: Analysis: Only paint SwHolePortion in tagged pdf mode.
move to target 3.x according http://wiki.services.openoffice.org/wiki/Target_3x
*** Issue 108862 has been marked as a duplicate of this issue. ***
This problem still exist with v3.2 and v3.3 both on Linux and Windows. With OOO 3.2.1 on Linux I am able to print to pdf correctly with the help of cups-pdf, but when exporting to pdf from Writer the bug exists. OOO 3.3 has the bug with both export and cups-pdf. If you need any more info, please let me know. With print preview or printing underline stops at margin as it supposed to do.
Created attachment 78896 [details] Iussue with print If I print this, always presents itself the iussue..
Hi I'll try to explain myself in english... ;-) Already with version 3.3 of OpenOffice (I hoped would be resolved with the new ..) if you stamp a page of text in which are lines with underlining that comes at the end of the line and maybe, continue to the next line, it happens that on paper the underlining is printed and continues "beyond" the word fine line and margin / right edge. I tried to change the spacing, margins, but have never been able to solve. The strange thing it doesn't happen to all the rows but only some ... I think mine is a iussue connected to this, but it found no solutions. Is it provided for the solution with the version 3.4.1? I try to attach a sample document.
Looking at the fix elsewhere ... The problem is in file: sw/source/core/text/portxt.cxx in SwHolePortion::Paint you have to add a new condition in the if (line 743) for SwTaggedPDFHelper::IsExportTaggedPDF(). Obviously when calling IsExportTaggedPDF() you have to check the value of *rInf.GetOut() for the parameter and you will have to include the EnhancedPDFExportHelper.hxx header.
Thanks for the pointer to SwHolePortion. As Frank mentioned in comment 7 painting the hole was only intended for tagged PDF export and doing it instead for all PDF exports is an important part of the problem. On the other hand also a tagged PDF shouldn't have text decorations bleeding over the margins. I think the best solution for this is to disable decorations altogether when painting the hole, so they have consistent visual appearance regardless of being on the screen, in any of PDF export modes or whatever other representations.
"hdu" committed SVN revision 1428424 into trunk: #i68503# a SwHolePortion must not be decorated for a consistent visual appear...
The fix above for SwHolePortion::Paint() solves these problems: - both tagged and non-tagged PDF export looks good - normal PDF also has a slightly reduced size
Hello all, I checked this issue with the version 4.0 and when I opened the PDF file I didn't have any problem with the underlines, they were correctly in the top of the margin. Regards, Daniel Alvaro.