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

On 09/05/12 16:48, Eike Rathke wrote:
> Hi Noel,
>
> On Tuesday, 2012-05-08 06:10:01 -0600, Noel Power wrote:
>
> > > 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
> Yup, I only tried with the .xls file that worked fine in 3.4.5
>
> But as seen on IRC you found what's going wrong where...
>
> > > 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?
> > I'm still hoping you'll find the real fix ;-)
[...]

Currently for 3.5 xlsx import I think this *is* the real fix ( or best 
option at least ), e.g. position the shapes absolutely using the same 
calculation ScDataView uses and should positively ensure that the 
absolute position matches where the row/col will be drawn and do this 
just for xlsx alone.

For master I want to be a little more adventurous in the way of getting 
rid of the 2/3 differently calculations of shapeposition, try eliminate 
the anchor/shape skew and for the import filters try to use cell 
anchoring where appropriate etc. If I come up with something for master 
we can look at the suitability of such a broader solution for 3.5 to 
replace the above, make sense ?

thanks
Noel