LibreOffice development

headers Ivan Timofeev | 15 Jun 2012 14:24

Hi,

MAB: https://bugs.freedesktop.org/show_bug.cgi?id=32181

I've created a (rather idiotic) patch, that fixes that bug, but I have 
no clue what is going on %-) so it can cause some awful side-effects.

There was
commit
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6425c2884d6013a41adbd76728e15832af7a3220 

which did besides:

>  <at>  <at>  -496,7 +510,13  <at>  <at>  void SwTxtPainter::DrawTextLine( const SwRect &rPaint, SwSaveClip &rClip,
>          if( pPor->IsArrowPortion() && GetInfo().OnWin() && !pArrow )
>              pArrow = (SwArrowPortion*)pPor;
>
> -        pPor = !bDrawInWindow && GetInfo().X() > nMaxRight ? 0 : pNext;
> +        pPor = bDrawInWindow || GetInfo().X() <= nMaxRight ||
> +               // --> FME 2004-06-24 #i16816# tagged pdf support
> +               ( GetInfo().GetVsh()->GetViewOptions()->IsPDFExport() &&
> +                 pNext && pNext->IsHolePortion() ) ?
> +               // <--
> +               pNext :
> +               0;
>      }

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 am thinking: maybe the proper fix is to negate that condition:

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

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

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