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/
Attachment:
signature.asc
Description: This is a digitally signed message part.