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. The hope was that Armin's new drawing layer with double values could solve that. Maybe we can tweak it a little by calculating row heights to drawing layer differently, but past experience was that each time a can of worms was opened..
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. 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), 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. 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'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 ;-) Would be good if you could find the cause of the jumping around when saving/reloading, and why row heights aren't saved properly. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Attachment:
pgp2YtbpXizSB.pgp
Description: PGP signature