Issue 68503 - underline in pdf-exported odt (full-just)-often bleed over margin
underline in pdf-exported odt (full-just)-often bleed over margin
Status: CLOSED FIXED
Product: Writer
Classification: Application
Component: save-export
OOo 2.0.2
All All
: P3 normal with 4 votes (vote)
: 4.0.0
Assigned To: frank.meies
issues@sw
:
: 108862 (view as issue list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-10 18:43 UTC by 20freshwater
Modified: 2013-05-18 13:16 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: 3.4.1
Developer Difficulty: moderate


Attachments
ODT file with underlined text. (17.15 KB, application/vnd.sun.xml.writer)
2006-08-10 18:45 UTC, 20freshwater
no flags Details
output PDF file with bleeding margins (over right margin) (40.65 KB, application/pdf)
2006-08-10 18:46 UTC, 20freshwater
no flags Details
Iussue with print (10.65 KB, application/vnd.oasis.opendocument.text)
2012-08-09 13:30 UTC, guarom
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description 20freshwater 2006-08-10 18:43:41 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.
Comment 1 20freshwater 2006-08-10 18:45:22 UTC
Created attachment 38426 [details]
ODT file with underlined text.
Comment 2 20freshwater 2006-08-10 18:46:34 UTC
Created attachment 38427 [details]
output PDF file with bleeding margins (over right margin)
Comment 3 michael.ruess 2006-08-11 07:47:24 UTC
Reassigned to HI.
Comment 4 h.ilter 2006-08-11 11:39:10 UTC
HI->PL: Occurs also with 680m181
Comment 5 h.ilter 2006-08-11 11:39:48 UTC
OS changed from Linux to All
Comment 6 philipp.lohmann 2006-10-31 12:55:38 UTC
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.
Comment 7 frank.meies 2007-01-08 11:40:47 UTC
FME: Analysis: Only paint SwHolePortion in tagged pdf mode.
Comment 8 Martin Hollmichel 2007-09-10 14:10:12 UTC
move to target 3.x according http://wiki.services.openoffice.org/wiki/Target_3x
Comment 9 michael.ruess 2010-02-03 12:23:43 UTC
*** Issue 108862 has been marked as a duplicate of this issue. ***
Comment 10 siriusb 2011-04-28 17:00:15 UTC
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.
Comment 11 guarom 2012-08-09 13:30:13 UTC
Created attachment 78896 [details]
Iussue with print

If I print this, always presents itself the iussue..
Comment 12 guarom 2012-08-09 13:32:06 UTC
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.
Comment 13 Pedro Giffuni 2012-12-14 15:18:43 UTC
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.
Comment 14 hdu@apache.org 2013-01-03 16:00:49 UTC
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.
Comment 15 SVN Robot 2013-01-03 16:04:40 UTC
"hdu" committed SVN revision 1428424 into trunk:
#i68503# a SwHolePortion must not be decorated for a consistent visual appear...
Comment 16 hdu@apache.org 2013-01-03 16:13:40 UTC
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
Comment 17 DanielAlvaro 2013-05-18 13:16:36 UTC
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.