Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 08/06/12 11:56, Noel Power wrote:
although 31012ab9d7035f942486c87ecc1a79b4d6579975 ( and associated fix 8a838b9fbf46ece9680824cd3a044ab7338bf306 ) make the document mentioned in https://issues.apache.org/ooo/show_bug.cgi?id=116848 behave better with zoom, it makes other documents much worse ( even at 100% zoom ) e.g. the document attached to fdo#49430. When you modify the zoom then the situation gets much much worse. So what I see is

a) with commits 31012ab9d7035f942486c87ecc1a79b4d6579975 ( and associated fix 8a838b9fbf46ece9680824cd3a044ab7338bf306 ) we have one test document ( associated with the orig bug ) that experiences no skew of the relative position of the shape to the position of the cell the shape is anchored to ( regardless of the zoom ). However we have other documents ( typically where the shapes are located further down the document ) where there is significant skew between the shape position and associated cell it is anchored to. Note: in these cases changing the zoom results in wild relative position changes ( e.g. a number of rows offset )

b) with the commits above reverted the test document associated with i#116848 is indeed not behaving itself at zoom levels other than 100% ( so that bug will still exist ) but... with the other scenario ( with shapes located much further down the document e.g. with the document attached to fdo#49430 ) behave much better, indeed the shapes ( at 100% zoom ) are at the correct position. In both cases changing the zoom seems only to affect the relative position error in a small way ( e.g. less than a row height )

Eike we discussed this previously on IRC and I already reverted these patches on master, I think we should revert these on 3.5 also, to me the behaviour without these commits is better than with them ( but thats just my opinion hence the review request ) It would be great to fix the underlying error, unfortunately I didn't have any luck with that. So... please consider reverting 31012ab9d7035f942486c87ecc1a79b4d6579975 ( and associated fix 8a838b9fbf46ece9680824cd3a044ab7338bf306 )
so. I have returned to this a number of times, I must confess I never did seem to figure out how to avoid the rounding effects inherent with how the grid is drawn ( row by row ) and how the that compares with the fixed position of some shape over different zoom levels. As we know the resultant effect is that the position of the shape seems to change relative to the grid. So.. I took a different approach and try to minimize those ( what seems to be inevitable ) display errors. First I find the nearest cell to the shape, then find out where that cell is drawn on the screen for the current zoom, and lastly move the shape ( before it is drawn ) to compensate for any errors. The idea is simple enough but the patch is rather ugly ( especially around the mark view stuff, add offset here, remove it there etc. must be a better way I feel ) . Anyway It does seem to work reasonably well though ( at least all the shape things I tried on the draw toolbar and inserted pictures charts and ole objects ) *seem* to work. I say *seem* because I have to admit that I haven't retested *all* of these objects after every change ( and there were many individual changes sofar to try and tease out the wrinkles ) but I have tested most of them again just before I committed

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4e649f0cd013e86adbd794859bcc3cb9ee3aa61

note: make check passed

so, please beaware of this change, let me know if you spot any new unusual behaviour around this area. One thing I did notice is that after creating some shape/object at some non 100% zoom level that sometimes it is difficult to get the handles ( after clicking the object ) again for the shape after creation. Actually I thought I fixed this earlier but perhaps some more recent change I did broke it again :-( Anyway there are I am sure lots of edge cases around this that I haven't yet spotted, please help find them.

A quick demo screencast ( and the test document used in the screencast ) is located here http://users.freedesktop.org:8080/~noelp/zoom , best to download the video in order to see the subtitles ( not really visible when you play from the browser ) and as poor as the subtitles are they took me half the day to figure out how to do them

Noel

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.