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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
