Hi Korrawit, thanks for testing and your hints how to address the problem.
The reason why I was using round was to reduce the difference between the positions while scrolling in one direction and then back. With round it takes more steps to reach a position where they will differ slightly. Since this is not a big problem round could be removed. To my knowledge the type conversion does already act like floor() so a simple removal should be enough. But if ::boost::math::iround will be used in other places or if there is already another usable round function - what does Calc use? - I would replace the function with the os independent counter part. Regards Tim On Sunday 15 January 2012 16:03:33 Korrawit Pruegsanusak wrote: > Hello Tim, all, > > Your patch addressing fdo#44173 regarding zoom level [1] cause the > windows msvc tinderbox failure. > [1] > http://cgit.freedesktop.org/libreoffice/core/commit/?id=022ce7d362f146ed69f54aae20cf2b8c582e9f8d > > Actually, the one to blame is the msvc library, because it doesn't > have round() function. > And I have two methods to resolve this: > > 1. Use ::boost::math::iround. (patch attached) > This solution comes from http://stackoverflow.com/a/5849630 > This has advantage that it won't fail in any platform, I hope ;-), and > it's really "round" the value. > > But as the round.hpp header isn't delivered yet, we have to modify > some boost makefile, then we have to: > > A. Clean boost (rm -rf $INPATH), then rebuild it. I've tried > incremental `build && deliver` but it didn't help. > But this led to almost all rebuild in tail_build, IMHO because it > triggered the dependency tree, ie boost header is just delivered => > rebuild all files which include the boost! I don't think anyone > (except tinderbox) love this. :-) > > OR B. Change the added line into real command (variables > substitution) and run it, then `deliver`. Such as: > @$(GNUCOPY) -r $(PACKAGE_DIR)$/$(TARFILE_NAME)$/boost$/format > $(INCCOM)$/$(PRJNAME) > I run it as: > ./libo/boost/wntmsci12.pro/ $ cp -r > ./misc/build/boost_1_44_0/boost/format ./inc/boost > etc. This wouldn't trigger the dependency tree to rebuild. It just > delivered only new files. > > Note: I don't know why we have to "normalize" and deliver just > only some part of boost library. Because the rest is unused? This > cause the problem when we want to use more library than the delivered > ones, as in this case. ;-) > > Since I discovered the (B.) too late, so I'm in the middle of ~clean > tail_build, but a build passed the modified files well ... > > 2. Instead of round(), take it as ceil() or floor(). This has > advantage that you don't need to rebuild. But it won't really > "round()". > Anyway, I don't think it will cause much difference, except in a very > large/small number. > > Or will we use floor(x+0.5); ? This behaves like round() only for > positive numbers, which we don't have negative zoom factor anyway. :-) > > I don't test this method yet, and I don't know whether we have to > #include <math.h> or something. But the linux/mac build passed well > (in tinderbox), so maybe we don't need including? > > Please feel free to comment or correct me if I'm wrong :-) > Best Regards, > -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany T: +49 (0) 911 74053-0 F: +49 (0) 911 74053-483 http://www.suse.de/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice