Add this as a pie-in-the-sky future future feature request. It would be nice if the tiles could fade in when they are loaded, rather than just popping in. It should be a very short fade in, 100ms or so, but just enough that it wouldn't be quite as jarring. The jQuery .fadeIn() method looks promising for this.

This would definitely have to be tested for performance impact.

There should be a fullscreen mode feature, either triggered when the user enters native fullscreen mode or something that can be toggled. It should also be possible to specify what, besides the actual document viewer, is included in fullscreen mode. For the next version, or this one if there is time?

Used only in grid view and ignored in document view, but preserved upon returning to grid view (just as the zoom level is). Could be named "r", for row, or "n", for number (because "p" is taken).

Sometimes it skips page 2 (when scrolling down) and sometimes it ignores page 1 (when scrolling up) - why?

Currently there is no way to handle items with varying max_zooms - it's assumed that every pyramidal image file within a document has the same max zoom. However, there are some documents for which this is not the case, resulting in some pages looking like this:

It's probably not reasonable to assume that all images in a document have the same max_zoom, so this should be accommodated somehow, preferably automatically. Some possibilities:

• Force all images to be generated as TIFFs with max_zoom set to the lowest max_zoom among all the images
• Process the images (possibly manually) to ensure that they have the same max_zoom
• Something on the document viewer side?

It would be nice to be able to link to a specific page via URL, e.g.,

http://example.com/diva/32#p=499

When using the zoom slider to leave grid view, the document viewer should scroll to the most recently-viewed page at the desired zoom level. Currently it just shows the first page at the wrong zoom level.

When leaving grid view, the document viewer should jump to the page shown as the current page.

When entering grid view, the document viewer should jump to the row containing the page shown as the current page.

When trying to zoom out through pinch-zoom on the iPad, two gestureend events are fired for some reason, resulting in the user being scrolled to an unexpected place (usually about twice the expected page number). Preventing the event from propagating and returning false did not help. This seems to only occur when zooming out.

There should be the ability to set an "adaptive" padding which depends on the average height and width of the images. The ratio of padding to the dimensions should be adjustable. If set to 0, it should use settings.fixedPadding (also user-adjustable) instead.

Use virtual rendering techniques to load only the tiles that are visible in the viewport. This should speed up loading at the higher zooms.

The page number should update when scrolling while in grid view. Perhaps to the first page in the topmost row.

There should be some feedback that a page image is loading if the user scrolls to a page and the tile server has not yet served the tile.

See here for possible loading indicators. http://www.ajaxload.info/

There should be the ability to extend this plugin via callback functions, most notably for scrolling, but perhaps also for zooming and other events as well.

Shamelessly borrowed from the BookReader project, http://openlibrary.org/dev/docs/bookreader

Contact sheet is all pages arranged in a grid.

Would be nice.

I suppose we should make sure this works on Windows-specific browsers. Let's start with IE7 and work our way up.

When the page is loaded from a new tab/window in Google Chrome, with a page number specified and the grid hash parameter set to true, a horizontal scrollbar unexpectedly appears. Doesn't appear to happen in Firefox or Safari.

If images were loaded when they were 100 or 200 pixels beyond the viewport, then the tiles would come into view more smoothly, at least at lower scrolling speeds.

The code needs a small rewrite to allow for the possibility of instantiating more than one document viewer on a single page. Currently this is not feasible due to the way div IDs are handled, but the original code had a framework for implementing this so fixing this issue simply requires making use of that framework.

Perhaps this is not an issue (I am not sure if this is normal for such an application), but...

If you perform a relatively long scroll (e.g. holding down page-down or dragging a long distance) you can generate a rather large number of unnecessary requests. For example:

1. If I scroll from page 500 to 583 by holding page-down, I generate 969 requests - though I never actually see any pages except the last.
2. If I start from the beginning and drag the scrollbar to page 411 (with pretty good accuracy), I generate 871 requests.

I am running Google Chrome on Windows XP on relatively new hardware on a relative fast internet connection and it performed relatively well, but it may be problematic for others to have hundreds (sometimes thousands) of requests in a matter of a couple seconds.

A possible fix would be to not make the AJAX call immediately, but instead set a timer which will check to see if the page is still in the view and only then make the AJAX call. The actual interval can be relatively small and remain unnoticeable by the user (think 1 / # of page downs per millisecond). In fact, it may speed up performance as the user wouldn't have to handle hundreds simultaneous connections.

For the next version. There should be an option to switch between a vertical (the current default) and a horizontal layout.

settings.totalHeight is somehow not being calculated properly - there is either not enough not padding at the bottom or too much of it (depending on what "fix" is applied)

The Divaserve php script is nowhere near ready for release. It needs a rewrite.

We'll need to create some test sets and ensure diva works with a wide range of images.

It remains the default cursor when hovering over or dragging within the document viewer. Happens in Firefox 3.6.10 (Mac) but not Firefox 3.6.16 (Ubuntu). Also happens in Opera, 11.10 on Ubuntu. (Don't have any other browsers to test at the moment.) Actually, Opera seems to be having larger problems - it's not rendering all the images properly, for one. But that's another issue.

It remains fixed at the padding calculated after the first ajax request.

There should be a sidebar showing the thumbnails of certain pages throughout the document, so that the user can easily visually browse the document.

On the computer I'm using now (lab computer, the one nearest the door), the control key is mapped to right-click or something so that whenever I try to zoom out with ctrl + double click, it just brings up the right-click menu; it doesn't zoom me in or out. I have no such problem on my laptop, however, and I don't know how common this issue is. I had no such issues with the alt key.

I'm not sure what the best solution would be - ignore this case? Allow users to zoom out with either alt or control? Return it to alt? What do you think, @ahankinson?

It just goes straight to the top row.

We should support Djatoka and JPEG2000 in both Djatoka and IIP. This shouldn't be required, due to the lack of free libraries for r/w JPEG 2000, but it should be an option.

The #currentpage div is somewhat hidden behind the document viewer panel when there is no zoom slider to take up space on the left side. A css issue probably.

Currently page output for the div sizing looks like:

"top: 504851.35291595693px; width:622.5px; height: 1022.5px; left:502.75px;"

Since we can't have 352915693ths of a pixel, we should round these to the closest whole value. This might fix the white line issue too.

Zooming in and out on the iPad is a bit difficult. The zoom slider works, although it can be a bit hard to press, but double-click to zoom doesn't work at all (presumably because the iPad fires off double-tap as opposed to double-click events). I'm also not sure how we could implement ctrl + double-click to zoom out on the iPad.

Scrolling actually does work as expected - it has to be done as two-finger scrolling, as is standard. Both horizontal and vertical two-finger scrolling are working.

The goto page input, isn't in a form and only has a click handler:
https://github.com/DDMAL/diva.js/blob/master/js/diva.js#L885

Aside from being invalid html, it'd be a better idea to make a form, not a div, put the input inside it - and attach a submit handler to the form. This would remove the mouse dependency on the goto page input.

To reproduce:

• open http://ddmal.music.mcgill.ca/diva/demo/
• click in the goto-page input
• type a number
• hit enter

Expected result - goto entered page

Actual result - sweet diddly

As you scroll in full-screen, a small translucent dialog should show you which page you're scrolling past. This should fade in / fade out as you scroll so that it doesn't obscure any part of the image.

Some potential jQuery plugins that can offer this type of dialogue are listed here:

http://stackoverflow.com/questions/201684/best-jquery-status-message-plugin

There should be the option to view pages of certain documents side by side (verso, recto). This could either be another view (in addition to grid and document) or could replace the regular document view for applicable documents.

e.g. page up/page down/space (page down).
It acts on the surrounding page, instead of the inner scroll thing.

Especially when using the gotoPage() function. It should always attempt to center the page in the viewport.

The context menu is no longer triggered (commit 921372d) but pressing control and double-clicking doesn't do anything.

Actually, if "Disable or replace context menus" is unchecked in Preferences -> Content -> Advanced Javascript settings, then the context menu is still triggered. This behaviour appears in Google maps as well, but Control + double clicking to zoom out works there.

How should we deal with this? This is Firefox 4.0.1 on Mac OS X Server. Firefox 3.6 on Ubuntu works fine.

When activating fullscreen mode (or when leaving), the document stays on the side is centered in the viewer only after a delay. It happens at least on Firefox 3.6

When in the regular document view, the label should indicate that it is a zoom slider and display the current zoom level; when in grid view, the zoom slider should be replaced by a grid slider, and the label should reflect the change.

Happens in Firefox with Firebug opened and Chrome with the web inspector opened. When entering fullscreen mode with the console/inspector opened, the height of the panel is taken correctly, but if the console is closed while in fullscreen mode, the resized panel height is not taken into account, resulting in pages not appearing when they are supposed to (when scrolling). This also happens when resizing the window within fullscreen mode.

Fixing this would probably require listening to all window resize events while in fullscreen mode and adjusting the stored panel height based on that.

For the next version. There should be an option to switch between a vertical (the current default) and a horizontal layout.

New pages are showing up about 50 pixels of scroll after they are supposed to, and are disappearing too quickly as well. Looks like an issue with nearViewport and/or the way settings.heightAbovePages takes padding into account.

Scrolling can be slow sometimes (although nowhere near as slow as it was before, when all the images were being loaded), particularly on the higher zooms. There should be a way of skipping scroll events or something.

Looks like the row height is not being calculated properly.

in Firefox 3.6, after scrolling to a certain page and entering fullscreen mode, the user is is shown the first page as opposed to the most recently-viewed page. This problem does not seem to occur in Opera (11.10), Chrome, or Safari. In Firefox 4, the problem does not occur when the user enters fullscreen mode, but rather when the user leaves it.

As far as I can tell, this occurs in non-webkit browsers on OS X and all the browsers that I've tested (Opera, Firefox, Chrome) on Ubuntu and Windows. Somehow the right pages aren't being loaded. This may have something to do with the zoom change ratio.