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

sorry for the duplication, my mail client broke threading so I reply 
again.....

Hi Eike

On Mon, 2012-05-07 at 21:02 +0200, Eike Rathke wrote:
> 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.
yup so is my attempt to resolve the position by calculating the expected
position the same way as the gridwin does ( or at least using the same
caclulation it uses to position the anchor graphic ) totally off the
mark ? ( to me it makes sense but... )
[...]
>
> > 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.
ok, I can't see how this patch can affect the export :-/ unless there is
some tweak in the export to to attempt to correct the 'same' error ( or
something like that )
>
> 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),
oh :-/ now that is strange 'cause the problem ( xlsx import ) was
originally reported against 3.4.x, I tacked on the xls support as I saw
the same position misbehaviour in 3.5. So... it seems at least from what
you are saying that something nasty has happened with xls import post
3.4
>  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.
this is getting more bizarre :-), I suppose though this is somehow
related to the import behaviour :/ and the xls export seems
( with/without patch ) to be shifting the shape position
> 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 hope this points to the same badness in xls import -), interestingly
saving as xlsx ( from 3.4 ) and the positions shift up also
>
> 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
> ;-)
hmm, not sure I totally agree, but how about just enabling this for oox
import then, I think that in all cases there is an improvement with that
right ? would that be ok? > > Would be good if you could find the cause 
of the jumping around when
> saving/reloading, and why row heights aren't saved properly.

looks like row heights were broken for some time, just at this minute
that's less critical ( and not sure even where to start look for that )
I hope to try and find out why the xls import/export causes such grief
now first.

Thanks again for having a look,

Noel