This is caused by MM100 to TWIP conversion. An A4 page is 210mm,
11906twip. The calculated document width is 210mm, 11907twip.
Do you know where the code is that calculates 11907 as the result ?
No. I know that:
-a macro (MM100_TO_TWIP) is used.
-the paper width is calculated from (leftMargin * 2 + (columns-1)*labelPitch + labelWidth
(core/sw/source/ui/app/applab.cxx) and each has converted form MM100 to TWIP before that. The
problem is not here, because when I apply bugfix 44516 (which I have not yet submitted), the paper
width is taken from the label definition and amounts to 11906twip.
-when creating the new document, somewhere the document takes shape and the label definition is
used to locate the labels on the paper.
Otherwise would PaperInfo::doSloppyFit be of any use to you here ?, can
opengrok for usages, snaps paper sizes that are within a tiny distance
of a known paper size to that paper size
PaperInfo::doSloppy could be a great help indeed, although the paper format is not the problem (it
is correct), but the contents of the created document are one twip wider than the paper.
If it were only a couple of label definitons with this problem, I would have reduced the label
width with one MM100 and the problem would be solved. Unfortanely, I count 522 -potential- problems
(I only checked 3, all problem).
Winfried
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.