[PATCH] fdo#32181: don't exceed margins on pdfexport

Caolán McNamara caolanm at redhat.com
Mon Jun 18 14:10:24 PDT 2012


On Fri, 2012-06-15 at 16:24 +0400, Ivan Timofeev wrote:

FWIW, I'm sure you know that #i16816# maps to (thesedays)
https://issues.apache.org/ooo/show_bug.cgi?id=16816 so that's the bug
apparently being addressed by the original commit. Though there's no
immediate explanation there for that specific hunk.

> so on pdfexport we are taking next portion if it is a hole portion 
> regardless of its position. What is this: "a hole portion"?

I haven't a clue, but I see that SwTxtPortion::FormatEOL is one of two
places that makes one, which makes me wonder if
https://bugs.freedesktop.org/show_bug.cgi?id=43737 is related.

> I am thinking: maybe the proper fix is to negate that condition:
> 
>    !pNext->IsHolePortion()
> 
> (it solves the problem as well)

Apparently a HolePortion is a basically a chunk of blank space required
to exist in some edge-cases. My guess is that the logic isn't reversed
in the original and if the choices are between fixing fdo#32181 and
retaining the fix for some obscure palmos pdf problem of #i16816# that
your first patch is the better choice. Just a guess.

Lack of visual layout regression tests is hurting us here :-( Custom
testing font + save to pdf + ye-old-imagemagick-subtract-images-trick is
probable way to go on that front for long term.

C.



More information about the LibreOffice mailing list