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.