Page MenuHomePhabricator

display page count (of the multi-paged media file) in dimensions
Closed, ResolvedPublic


Media handlers can change the content within the dimension field displayed underneath the page.
It would be useful to include page count in this field.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:37 PM
bzimport set Reference to bz28868.
bzimport added a subscriber: Unknown Object (MLST).

Fixed in r87651.

Note that revision won't affect PagedTiffHandler, which does other things with the long description, including showing which page you're currently viewing. I'm unsure if it would look stupid to have:

(page 1, 3,055 × 4,108 pixels, file size: 35.94 MB, MIME type: image/tiff, 42 pages)

Maybe something like:
(page 1, 3,055 × 4,108 pixels, file size: 35.94 MB, MIME type: image/tiff, 42 pages total)

Would look better? Thoughts?

(leaving this bug open for the moment to comment on the tiff handler)

I don't think the dimensions field should change depending on the page you are viewing. The page being viewed is not a dimension. The dimensions are listed underneath the current image, *however* that is in round brackets after "Full resolution‎". When the user clicks on "Full resolution", they don't download only 'page 2' when they are viewing page two - the entire document is downloaded.

The tiff viewer is displaying 'page 1' for single page images (e.g. [[File:D.tiff]]
And I can't find a multipage tiff on commons so I uploaded one
[[File:International Convention for Regulation of Whaling.tiff]]

Did this code apply to djvus and pdfs? (is bug 28869 able to be closed?)

It should apply to PDFHandler extension, DjVu files, and Tiff files if using the built in (Crappy) tiff handler.

The only one it doesn't apply to is tiffs when the wiki is using PagedTiffHandler extension (As opposed to built in tiff support). All Wikimedia wikis use PagedTiffHandler.

The change to make this work for PagedTiffHandler is trivial, just per what I said in comment 1 I'm a little worried it might look stupid ;)

btw, cc'ing Markus Glaser because he is default assignee for PagedTiffHandler, and I've somewhat hijacked this bug to be something about PagedTiffHandler.

@Bawolff, thanks for cc'ing!
In r88006, I removed the page number in longdesc for PagedTiffHandler and put in the total count of pages, which should fix this bug.

However, there are things to consider:

  • I know of multipage tiffs where height and width vary over the pages. At the moment, in the short description, the resolution of the first page is used, and in long description, the resolution of the currently shown page is used. I couldn't think of a better solution, so if you have any thoughts...
  • There is no real indicator any more on which page you are when viewing a multipage image. There is the correct page number next to "Go to page", but, obviously, the label says something different. I suggest we put a text above, saying "Current page" with the page number and set the number next to "go to page" to the next page.

What do you think?

Wow, I guess I'm not good at following up on bugs...

Yes I agree, changing it to be

Currently displaying Page X
Goto page <next page>

Would make sense

Created attachment 12121
patch to add "Current page X"

Hmm, tried it. Not sure if I 100% like the results. Maybe could use some feedback from commons (or UX people?).

Comments? I'll also attach a screenie


Created attachment 12122
screenshot of proposed change to multipage layout

Screenie of proposed changes. Please comment/suggest tweaks


currentpage_on_multipage.png (858×1 px, 275 KB)

I had a similar idea when working on the PagedTiffHandler, but never came to implement it. So a big +1. From a usability perspective, it might be a good idea to have the current page number highlighted somehow. If we use a form element to switch to the next page, that's going to attach readers attention and they might think that's the current page number.


matmarex subscribed.

This looks like it has been resolved back in 2013.