sometimes the imported position of shapes are totally and catastrophically wrong.
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9dc4fa1b22a533ba0a6ce0353112c55eef8a14ef fix bad import positions of shapes & controls fdo#49430
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5813422d3eb9657c5a818057be0ebf831ca6a794 tweak imported shape position for xls( binary ) format fdo#49430
The import filters ( for both oox and xls ) miscalculate the positions of imported shapes. In particular it appears the further down the sheet the worse the error can be, additionally when we have lots of different row heights this can also really adversely affect things. By far the worst problem though is that there is an inbuilt error in calc where the position of a row/col calculated by the view can be very different from that calculated by the drawing layer ( or the filter ). In otherwords even in an ordinary calc document you can for example anchor a cell to A769 but the shape will be drawn at A766 or A775 or basically somewhere other than where you expect. This discrepancy is not normally noticed because shapes in a document are positioned manually and the geometry information ( which includes the error ) is persisted, when the document is loaded the geometry information ( including the error ) is re-read and re-applied and the shape position is displayed in the expected position.
Created attachment 60974 [details] picture showing the anchor and actual shape position skewed note: in the attached image the checkbox is anchored to a769 and one would expect the checkbox to be displayed within that bordered cell, reality though... disagrees
Created attachment 60975 [details] document for the image shown earlier I guess we have to live with this 'effect' as afterall the offset error is already built into millions of documents
Now, down to business, the import problem is hard to live with as the import filters calculate the desired shape position based on cell anchor, when we have this offset between anchor position and actual shape position then the shape will be displayed at the wrong position. The oox filter also screws up the position more as it seems there is some row height adjustment that further mucks things up ( for some reason this doesn't affect the binary filter ).
Created attachment 60987 [details] image of some shapes in excel doc some shapes, drawing, form control and a chart in excel document, note the positions
Created attachment 60989 [details] top xlsx version of excel document imported by 3.5 image of the imported ( by libreoffice 3.5 ) excel content xlsx on top and xls on bottom, note the positions of the objects ( in fact the form control seems to be missing, the size is corrupted as the vml anchor interprets the row/col offsets in the wrong units )
Created attachment 60990 [details] images of the imported content after patches applied on top is the imported xlsx content, on the bottom is the xls content, note the positions of the objects, also note the form control is now visible
Created attachment 60991 [details] actual xlsx version of the test document
Created attachment 60994 [details] actual xls version of the test document
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=76bab166e21bc3646ae2d3079aae2c5d9ce0d1e5 reorganise code a little so ole controls are catered for wrt fdo#49430
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b2af4b20a009cce57f547865b02fde41d1232a17 Revert "reorganise code a little so ole controls are catered for wrt fdo#49430"
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=da81525ec2e86364def8b558e16c4e8eca6a121e (reworked )reorg. code a little so ole controls are catered for wrt fdo#49430
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0a8de8d937ea1e9cb26ea7c89951f559961b49de Revert "(reworked )reorg. code a little so ole controls are catered for wrt fdo#49430"
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3ed479a1d83916cb5dc3be0eee0aa6fbe65a844a Revert "fix bad import positions of shapes & controls fdo#49430"
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=56f450187343688f20f88e68a849c8dcd660b629 Revert "tweak imported shape position for xls( binary ) format fdo#49430"
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dbb385df0fc83c36cfc91b82979fabea868592c2 fix missing form control, partial fix for fdo#49430
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=edd7b00431f5d3c008437e974b93dda804300bbf&g=libreoffice-3-5 fix missing form control, partial fix for fdo#49430 It will be available in LibreOffice 3.5.5.
fixed in 4.0 by http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4e649f0cd013e86adbd794859bcc3cb9ee3aa61 (etc)