[Libreoffice] [REVIEW] bug#36874 to be patched in 3.4.5 as well?

[Petr Mladek]

Winfried Donkers píše v Po 19. 12. 2011 v 09:12 +0100:
> >> Is it an option to push it to 3.4.5 as well?

> This probably is still not the correct way to propose this patch for
>  3.4.5 but hopefully good enough to be reviewed and processed. I'm not
>  fast in learning, but eventually I may get there ;)

You asked for review the right way. :-)

We need to be very careful when pushing changes into 3-4-5. There is not
much time for testing.

Your code looks definitely better than the original one. Well, I am
still not sure about the calculation. It makes perfect sense when I
imagine the paper with blank labels. On the other hand, 
please look at http://download.go-oo.org/tmp/labels.png. The LO GUI
shows the page width as:

    left-margin + 3 * horizontal-pitch

=> the corresponding calculation should be:

	rItem.lLeft + rItem.nCols * rItem.lHDist

=> The code might be:

	long lPgWidth, lPgHeight;
	lPgWidth = rItem.lLeft + rItem.nCols * rItem.lHDist;
        lPgHeight = rItem.lUpper + rItem.nRows * rItem.lVDist;
        // check mimimal size
        if ( lPgWidth < MINLAY )
		lPgWidth = MINLAY;
	if ( lPgHeight < MINLAY )
		lPgHeight = MINLAY;
	rFmt.SetFmtAttr( SwFmtFrmSize( ATT_FIX_SIZE, lPgWidth, lPgHeight ));

As I said, your code makes perfect sense in the real printing. It might
be that just the LO GUI uses wrong visualization.

Have you tested your code with real label printing?
Is just the visualization wrong in LO?

Thanks a lot for the fix.


Best Regards,
Petr


PS: Just a nitpicking. I did not use the ?: operator in my example. I
think that it was not ideal in this case because you cut&pasted the long
calculation, so it was hard to read and prone to a typo ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: labels.png
Type: image/png
Size: 109559 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20111223/3381f5f1/attachment-0001.png>