Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Hi Noel,

On Friday, 2012-05-04 10:33:37 +0100, Noel Power wrote:

There seems to be some issue
with how the drawing layer and the grid/view part calculate
positions :/ they just don't agree.

Yes, that's due to accumulated rounding errors when converting to/from
drawing layer 100th mm mapping and the integer positioning. For unequal
row heights that becomes even worse. The hope was that Armin's new
drawing layer with double values could solve that. Maybe we can tweak it
a little by calculating row heights to drawing layer differently, but
past experience was that each time a can of worms was opened..

Eike I cc you here as maybe you can shed some light on this
weirdness ( I confess it confuses the hell out me )
otoh I think this patch is safe, it also addresses another issue (
see details in bug ) where sometimes ( like in the attached test
document ) the shape size is imported incorrectly and the shape may
not be visible.

While the import looks clearly better now it seems that it fixes only
one symptom. When loading shapeanchorskew.xls of
https://bugs.freedesktop.org/attachment.cgi?id=60994 it looks ok after
load, but saving the file and reloading it's off again, approximately by
the same amount as before, just in the other direction further down, and
row heights wrong, nearly doubled and not saving different heights.

I tried with 3.4.5 and there the objects are imported to the correct row
and also survive save/reload (except that row heights are saved wrongly
also there), from 3.5.0 it's broken. Funny enough, after save/reload
.xls in 3.5.x the objects do appear in row 517 as they should, again
with the wrong and equal row heights. Saving/reloading to/from .ods it's
worse and objects are off even further to the top, in 3.4.5, 3.5.x and
with your patch, but only if loaded from an .xls file. Once saved to
.odf the position stays fixed.

I'm hesitating to push your patch because it changes behavior such that
after import it looks ok but saving messes things up so may go
unnoticed. Before at least it was clearly visible that something's wrong
;-)

Would be good if you could find the cause of the jumping around when
saving/reloading, and why row heights aren't saved properly.

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

Attachment: pgp2YtbpXizSB.pgp
Description: PGP signature


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.