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

[Noel Power]

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