Created attachment 116437 [details] for example In attachment on ~272 row all image in one cell on ms excell and open office 4.1.1 file open is norm file save from other software in compatibility ms office 5.0/95 На русском Во вложении, на 272 строке все изображения находятся один под другим. В ms офисе и open office 4.1.1 открывается нормально. Файл сохранен из 1С 7.7, т.е. файл открывается в режиме совместимости с office 5.0/95...
Hi Mikhail, This looks as bug 67712. When I open in 5.0.0beta1, it works fine. So I close as duplicate. If I'm wrong, please explain and reopen. Thanks for filing the issue! Cor *** This bug has been marked as a duplicate of bug 67712 ***
Hi Cor Nouws, I'm install dev version 5.0.0.0.beta1, and this bug it is possible to repeat I'm load screenshot in attach
Created attachment 116439 [details] screenshot
Reproducible with Version: 5.1.0.0.alpha1+ Build ID: 1499425d09a85fea22a1d7087d605b401c93a6dd Locale: ru-RU (ru_RU) under Win7x64. All the images from rows below 272 are stacked in row 272.
Not reproducible with versions 3.3.0.4-3.6.7.2 under Win7x64 Reproducible starting with version 4.0.0.0.beta1 -> regression Also reproducible with 4.4.3.2 under Ubuntu 14.04 Adjusting priority accordingly
Yes I didn't check the issue properly. Apologies,
Created attachment 120282 [details] Minimal testcase 1. This bug is not with import; it happens as well with XLSX, with ODS, and with new sheet. 2. It isn't limited to raster images; it may be easily reproduced: a. Create a new spreadsheet; b. Draw a rectangle (Show Draw Functions -> Rectangle), edit its Position and Size to set Y position to, say, 3000 cm, note that it is located near row 6650; c. Navigate to cell A1 and save and close file; d. Reopen it and use Navigator (F5) to navigate to row 6650; see that it's not there; navigate to row 1930 and see it's there. (It is displayed at Position Y = 870.48) 3. You may use attached testcase to see the bug behaviour. Double-clicking the Picture 836 entry in Navigator in attached file navigates to correct row 5925 (but the picture isn't shown there, and the selection information in the status bar shows coordinates of its current position 2.28 / 870.48). Navigating to row 1930 and clicking on the object makes status bar to show "correct" coordinates (where it _should_ be: 2.28 / 2674.70). 4. It is "worked around" by using zoom; any zoom on rows >=1930 brings all misplaced objects to place. 5. Bisection tells that it's caused by commit c4e649f0cd013e86adbd794859bcc3cb9ee3aa61 Author: Noel Power <noel.power@suse.com> Date: Tue Nov 27 17:56:33 2012 +0000 Sync draw object to calc grid for better alignment when zooming Taking and working on a fix.
sc/source/ui/view/drawview.cxx void ScDrawView::SyncForGrid( SdrObject* pObj ) pViewData->GetScrPos() seems to give max value of 32767, which translate to 866960 returned by PixelToLogic.
A patch has been posted to gerrit for review: https://gerrit.libreoffice.org/19816
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1fa38d29030ae9d9751a1fbec30d8ba3263e681d tdf#91979: ScViewData::GetScrPos(): remove coordinates limit of 32767 It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This isssue is no longer reproducible in Version: 5.2.0.0.alpha0+ Build ID: 451f359023c681a91dbb232a5ea3fffb12c964bc CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-27_07:49:03 Locale: es-ES (es_ES) Thus, close this issue a RESOLVED FIXED