[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