Hmm seems I really need to return to this, comparing on windows ( where
we really have like for like fonts ) it seems the problem returns (
because the column width issue comes into play again )
On 18/07/11 10:41, Caolán McNamara wrote:
On Fri, 2011-07-15 at 16:35 +0100, Noel Power wrote:
Hi Caolán
could you have a look at this patch
http://cgit.freedesktop.org/libreoffice/writer/commit/?id=95351a519bec2833f5d936c20e3916a4e283b0f6
This should be a nice stroll down memory lane for you as it seems
related to http://openoffice.org/bugzilla/show_bug.cgi?id=1291, yes
issue #1291 !!!
Hmm, well I don't remember the code, I do remember the document itself,
cause its a nasty.
My intent with the SetFmtAttr is apparently to get a floating frame
which shrinks right down the the size of the table contained in it,
reset the positioning of the table so the left of the table is 0 from
the left of the frame and the right 0 from the right of the frame so
that it completely fills it widthwise.
If "FULL" isn't actually "full width of the container", but automatic in
a full-width-of-the-container, but clip-to-the-page-width, sort of way,
that's a pain :-)
yes that is what seems to happen ( although I failed to find exactly
where this is happening ) I can rule out ( afaics ) the table
implementation, so I guess it is happening in the layout stuff ( which I
have don't even have the teeniest clue about ). So the Frame in this
case has shrunk to the correct width of the table ( which is greater
that the page width in my case ) but the actual table width ( when you
raise the table properties dialog ) is the page width. This is due to
the "FULL" setting ( corresponding to 'Automatic' in the Table
properties ) which I guess is doing what it says on the tin, e.g.
aligning with the page margins ( or I suppose really the container
boundries or whichever is smaller it seems )
Bizarely: with either Left or 'From Left' alignment the a 'negative'
right spacing is used to allow the table width to be larger than the
container width. The right spacing value however will only influence the
table width up to the container width ( or page width ) whichever is hit
first
I think I'd prefer an explicit horizontal setting which does the right
thing, e.g. see if any of NONE/CENTER/LEFT do the right thing, rather
than re-use the current setting which might be something weird like
INSIDE, OUTSIDE or something and all we want is a table that completely
fills the floating frame.
ok, how about a limited hack here, e.g. if the horizontal setting is
LEFT_AND_WIDTH ( which seems to be the converted table alignment setting
in question for my test document and indeed the one from iz#1291 ) we
set this at the Frame otherwise leave it as FULL. I suspect that
LEFT_AND_WIDTH ( which I guess should try to fit the table into the
container ( which is already sized ) aligned to the left with the right
spacing adjusted to fit as appropriate ) probably would work in all
cases but I wouldn't want to bet on it.
FWIW, I suggest generally testing for changes in layout to existing docs
with export to pdf before/after and with
composite -compose difference old.pdf new.pdf - | identify -format %k -
did that for the document at iz#1291 and it shows no changes ( e.g.
result of 1 ) on my system, I'd be happy to check any other documents
you could suggest
Noel
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.