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

[Noel Power]

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