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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice