GNOME Bugzilla – Bug 131563
Use %s rather than ratios for zoom factors
Last modified: 2005-05-19 18:25:25 UTC
I'd like to be have Zoom 75 % in the GIMP. I find that the Jump from 1:1 or 100% to 2:1 or 50% is a bit too dramatic Many images I use are about the size of my screen but because of various combinations of panels, and menu bars and status bars toolbars and other things a 75 % is just about right to actually fit things on screen. Adding it should be simple enough. I hope I'm not presuming too much by adding the easy-fix keyword. I really should have filed this _years_ ago or at least filed it when I asked for Zoom support in the ImageMap plugin. http://bugzilla.gnome.org/show_bug.cgi?id=118080 The only problem I can see is that 75% cannot be nicely expressed as a ratio. The only solution to this I think would be to replace the Zoom items with Percentage values instead of ratios. The titlebar already shows the Zoom level in percentages, I think it makes sense to be consistant. I'm really hoping that older users wont be upset by the change, I'm far more comfortable with percentages from the many other programs I use, which makes me think this might count as HIG bug too.
Hi, We have recently changed the zoom in/out behaviour in CVS to zoom in/out by a factor of sqrt(2). This means that your zoom percentages are now 100% -> 71% -> 50% -> 36% -> 25% 100% -> 141% -> 200% -> 282% -> 400% Hopefully this means a more natural zoom in/out. In addition, zooms are displayed as %s in the image title bar (they are still internally calculated as rationals), and the algorithm to generate the fraction has recently been modified to favour small denominators and numerators. I think that this more or less takes care of all the issues you bring up. I'll mark this as a duplicate of the bug in which all this stuff was brought up & fixed. Dave. *** This bug has been marked as a duplicate of 124073 ***
I'm pretty sure that 71% will look way ugly and be much more badly scaled than 75% but then I'm assuming that more often than not the height and width in pixels will be a factor of 2 or 4. I am not sure this really does cover want I want but what you describe i is an improvment and I'm not going to argue about it but I may as well quickly ask a few quick questions. Has "Zoom..." Dialog allowing you to input arbitrary zoom values, or or Zoom to "Fit in Window" been added?
Fit to window hasn't been added, but could probably be done pretty easily. I misunderstood your original request I think - you're asking to modify the zoom factors in View->Zoom? I'll reopen the bug and put it on the 2.2 milestone - it's still a pretty easy fix. Cheers, Dave.
I am absolutely certain that 75% is exactly the Zoom ratio I want and although the improvements described are good I still think 75% would be a better. I've reduced the priority because it is not a very important detail. Enough of my images are do have an even number of pixels (divisible by four I think) that the scaling to 75% will consistantly look much better than anything else. rather than working this out algorithmically using a factor of sqrt(2) 100% -> 71% -> 50% -> 36% -> 25% 100% -> 141% -> 200% -> 282% -> 400% i would have just specified a list 100% -> 75% -> 50% -> 25% 100% -> 150% -> 200% -> 300% -> 400% which isn't far off the algorithm but I guess others previously complained and wanted 'smoother' zoom factor.
There is a dialog that allows you set a specific zoom ratio and 75% can be nicely expressed as 3:4. I think it would be handy to be able to edit the set of preset zoom ratios that is offered in the Zoom menu. You could then map your preferred zoom ratios to a range of keys.
IMHO this report should be closed again.
Agreed. I vote for closing it again as FIXED. By the way, even if the domain in which this is used is different, I would like to mention that most photocopiers have their zoom ratios based on the area, not on the width or height. As a result, the default factors are multiples of sqrt(2), just like we have now in the GIMP. This is also the same for the paper sizes A4, A5, etc. These comparisons may not be extremely useful, but at least this shows that a factor of sqrt(2) is not so uncommon.
Changing subject to the only part of this bug that hasn't been addressed. A decent set of preset zoom ratios in View->Zoom would close this. IMHO, these presets should be expressed as percentages, and not as ratios. Also, "fit to window" would be a cool addition. Leaving on 2.2 milestone. Cheers, Dave.
> "fit to window" would be a cool addition Huh? This feature is around for quite a while already. There are also presets. Bolsh, what are you trying to say?
OK - I missed "Fit to window". There are presets, but they're currently expressed as ratios. As you can tell from the bug title, that's the only part of the bug that still hasn't been done in code. The presets are open to discussion, as shown by the fact that they're being discussed. Anyway, I guess that has nothing to do with expressing zoom ratios as percentages. Dave.
the Patch attached simplifies the handling of zoom steps in the GIMP. The API of gimpdisplayshell-scale usually expects ratios, encoded in an integer (both nom=i/100 denom=i%100 and nom=i>>8 denom=i&0xff got used). While this might have been useful ages ago (before we introduced non-dot-for-dot scaling) it currently is very confusing, since it is a pain to understand and the ratios get converted to a float pretty soon internally anyway. I went through the code and changed the API to accept floats everywhere. This IMHO simplifies the solution of the problem of this bug report. This patch has open issues, marked with #warnings, where the ratios were exposed to the UI. I right now quickly hacked around that, but these dialogs might need a small review. This patch definitely does more than necessary to fix this problem, but is IMHO the right thing to do. It also implements the lookup-table for zoom steps as discussed on the gimp-devel mailinglist. What exactly is this bug report about? Just the labels of the zoom menu entries or the subset of presets offered there too?
Created attachment 23503 [details] [review] Patch to clean up the gimpdisplayshell-scale API
While I would welcome a change to the gimpdisplayshell-scale API as proposed by nomis above, I think it's too late to introduce a change that big this close to the release. I suggest we decide to either change the zoom factors in the image menu to use percentages instead of ratios (I think that's more intuitive than ratios) - and leave this patch to be applied for 2.2.
Adding the PATCH keyword.
> What exactly is this bug report about? Just the labels of the zoom > menu entries or the subset of presets offered there too? This feature request really addressed my wish to have 75% as one of the preset Zoom levels but - and I apologize in advance - the more important issue is really that I find ratios confusing and that I think percentages are much better. Also if you do choose to use percentages it is easy to choose mnemonics for them than with ratios.
I agree that this bug report is more or less about hiding ratios from the user in the user interface (info dialog and menu entries). I also agree with Brix that the change is best done after 2.0. I also agree with nomis that his patch, although perhaps more pervasive than is needed, is the right thing to do (except, perhaps, for preset ratios - the jury is still out on that one). Cheers, Dave.
I've recosidered. Given that this bug and others based on the zoom tool raised some other issues (namely that we use *both* (r/100, r%100) and (r/128, r%128) to get the numerator/denominator pair), I am now in favour of applying Nomis's patch, and closing this bug and 131964. Changing milestone on this bug to 2.0. Dave.
Ok, I just committed a revised version of my API patch. This should fix the technical issues mentioned in this report. The only thing left is to replace the default labels in the Zoom menu to not expose fractions (matter of taste). 2004-01-29 Simon Budig <simon@gimp.org> * app/display/gimpdisplayshell.[ch]: Store the zoom factor as float, not as a ratio. * app/display/gimpdisplayshell-scale.[ch]: change the API to expose the Float instead a weirdly encoded integer. Implement functions to get a ratio from the scale factor. Implement a set as presets as discussed on the mailinglist. Changed Zoom->Other dialog to enable entering a float. * app/display/gimpdisplayshell-title.c * app/display/gimpnavigationview.c * app/gui/image-menu.c * app/gui/info-window.c * app/tools/gimpmagnifytool.c: changed accordingly. * app/core/gimp.[ch] * app/display/gimpdisplay.[ch] * app/gui/gui-vtable.c * app/widgets/widgets-enums.h: Made the various display-creating functions accept a float for the scale. Introduce a new GimpZoomType: GIMP_ZOOM_TO. Generally adjust the API to use floats instead of weird integers. * app/core/gimp-edit.c * app/core/gimptemplate.c * app/display/gimpdisplayshell-callbacks.c * app/file/file-open.c * app/gui/image-commands.c * app/gui/view-commands.[ch] * tools/pdbgen/pdb/display.pdb * app/widgets/gimpimageview.c * app/widgets/gimptoolbox-dnd.c: changed accordingly * app/pdb/display_cmds.c: regenerated
Fixed this last issue in CVS: 2004-02-04 Sven Neumann <sven@gimp.org> * app/gui/image-menu.c (image_menu_entries): added percentages to the View->Zoom menu entries as suggested in bug #131563.
Verified against gimp 2.3