[REVIEW 3-5] calc import filters sometimes get shape positions badly wrong ( fdo##49430 )

[Eike Rathke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120507/bf599b38/attachment.pgp>