Ideally, the zoom level can be specified using a text box as an item under the View menu.  It would be preceded by the caption "Zoom: " that would have the accelerator "Z".  The text box would show the current zoom, as grayed out text.  When the menu item is activated, the text would be highlighted, allowing the user to enter a new zoom level.  Pressing Enter would close change the zoom and close the menu.

If it is not possible to do it using menu items directly, it can be done using a zoom bar or a dialog box.

Wouldn't Zooming to a selection provide a much more useful UI for this?

Entries in menus is hopefully against the HIG...

In some cases yes, because it is more direct -- you don't have to deal with numbers.  

But it is more convenient to specify a number
* if you know what the it is from experience, or
* to zoom out by a lot
* to repeatedly switch between two specific zoom levels while viewing a document.

The selection is laborious and requires dexterity.

I have changed my mind somewhat.  I still believe that there is a need for more precise zooming that does not involve the mouse.  The current zooming is too coarse in some cases, and selecting a region to zoom into can be ergonomically difficult.

But while absolute zoom is discoverable, it hinders direct manipulation.  To specify an absolute zoom, you need to think "what is my current zoom?  OK, now I need to multiply that number by about 1.5.  Let's see how that looks.  No, I guess that was too much -- let's try a slightly smaller number." and so on.

There are better ways to provide precise zooming:
* A finer zoom level, say using the Shift key as a modifier: "=" zooms, "Shift+=" fine-zooms, "-" zooms out, "Shift+-" fine-zooms out.
* Convenient selection for zoom-to-selection.  E.g., constrain the selection to the window's current aspect ratio.
* Zoom centered on the content under the pointer, if the mouse is pressed while zooming.
* Fast, responsive zoom, so that pressing "+" 8 times takes about as long as directly zooming in 8 levels would.
* Undo zoom level changes to a couple of levels.

Should I repost the bug with better wording?

Philip, thanks a lot for your suggestions, some of them are really interesting. For example let's take zoom to selection first, we already have such bug in bugzilla. Are you interested to look into it?

You are referring to bug 324031.  

I've posted the appropriate ideas against bug 324031.  I'd be happy to discuss and post the suggestions in the right places.  But I don't think I will have time to implement it.  I have a lot of time pressure that will prevent me from learning C and the Evince codebase.

In the worst case, I wanted to publish the ideas.

As I understand, the third suggestion above extends bug 315198 and the supposed solution for 300641 and 303884 (which I don't see working in version 0.1.6).

I don't like adding lots of fine controls on the movement system and regretably we've done this a number of times.  They tend to add lots of complexity in a couple of ways.  Either we have to expose them in the UI so that people can find and use the controls in questions, which will make the menus large and cumbersome for most people.  Or we hide them from the UI to avoid clutter and the people who might benefit from their functionality don't ever find them unless they play with Evince a lot.  

Did you know that Alt-Up/Down isn't the same as Up/Down?  
Shift-PageUp/Down traverses 10 pages instead of one.  :)

And it's not that some of these aren't useful and there probably are a number of people who rely on them.  But we're filling up the keybindings with easter eggs.  I worry we're going to have conflicts if / when we want to add new features like better zooming, annotations, and form support (which we can deal with when we get there).  In the simplest argument, all the hidden keybindings end up being the command line interface to evince that only the advanced users get advantage of and I don't like going down that route.  It's often a little harder, but worth it to present the best experience to all the users.

On the bright side!  I think most of your other issues are actually fixed and I think the zoom selection support is something we should have.  I made comments on that bug as well.

Having numerical zoom levels is useful to scale a document to the correct real life size.
Evince appears to display everything at 75 DPI instead of the actual resolution.  So, on my 96 DPI LCD monitor everything appears to be too small at 100% zoom.  Zooming to 128% would give me the right scaling.

(In reply to comment #8)
> Having numerical zoom levels is useful to scale a document to the correct real
> life size.
> Evince appears to display everything at 75 DPI instead of the actual
> resolution.  So, on my 96 DPI LCD monitor everything appears to be too small at
> 100% zoom.  Zooming to 128% would give me the right scaling.
> 

This is already fixed since evince 0.7 (see bug #318285). What evince version do you have? if it's >= 0.7, please reopen that bug again. 

I have 0.5.1 (came with Fedoce Core 5).
Sorry, I did not find the other bug.  I tried searching for evince and zoom since bugzilla does not accept three letter search terms like DPI.

*** Bug 485273 has been marked as a duplicate of this bug. ***

*** Bug 553234 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> (In reply to comment #8)
> > Having numerical zoom levels is useful to scale a document to the correct real
> > life size.
> > Evince appears to display everything at 75 DPI instead of the actual
> > resolution.  So, on my 96 DPI LCD monitor everything appears to be too small at
> > 100% zoom.  Zooming to 128% would give me the right scaling.
> > 
> 
> This is already fixed since evince 0.7 (see bug #318285). What evince version
> do you have? if it's >= 0.7, please reopen that bug again.

Actually the dpi thing seems to be still not fixed. I am on a machine using ubuntu lucid (LTS) right now, that ships evince 2.30.3. I want to work with some lego assembly instructions and a 1:1 display is crucial as it shows parts in original size. On the screen I am not able to get it show things at the correct size (which I would expect at 100% zoom ratio).

My display is an LCD on a lenovo T410. Acording to http://members.ping.de/~sven/dpi.html

Horizontal resolution:  pixels 
Vertical resolution:   pixels 
Diagonal:   inches (35.81cm)
Display size: 11.96" × 7.47" (30.37cm × 18.98cm) = 120.43 PPI, 0.2109mm dot pitch, 14504 PPI²

The only place I find dpi setting is on the Apperance/Font settings and there it says 96. Changing that seems to have no effect on evince though.

Actually it is fixed. Also the font dpi settings are indeed unrelated. What matters are the dpi info in the xserver:

# xdpyinfo | grep resolution:
  resolution:    96x96 dots per inch
# xrandr --dpi 120
# xdpyinfo | grep resolution:
  resolution:    120x120 dots per inch

And then it works fine. Sorry for the noise. Wonder if evince could do anything to bring that to peoples attention.

Unfortunately the presentation mode seems to switch to Best-Fit. Would be nice if the top-toolbar could disappear after a short timeout like in totem.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.