GNOME Bugzilla – Bug 660113
hard to use with excessive page "number" length
Last modified: 2012-10-06 09:27:30 UTC
See screenshot. I just downloaded 802.11v-2011 from the getieee 802.11 program, and the cover page has the page "number" listed as "IEEE Std 802.11v-2011 front cover". This makes the TOC really hard to use, and there's no way to indicate that I don't care about truncating page numbers in the TOC. Maybe a good way to solve this would be to right-align the page numbers and allow the section titles to flow over (see attached mockup).
Created attachment 197456 [details] screenshot showing the problem
Created attachment 197457 [details] (bad) mockup of how it would be nicer Ok so I didn't do the alignment completely, but it'd be much more usable this way.
Created attachment 225921 [details] Screenshot to show the bug with long page number in the index
Created attachment 225922 [details] [review] Set a max widht for page number This patch set ellipsize to page numbers in the index and set a max width of 12 characters. 5 characters width should be long enough for numbers between 0 to 99999. However, some documents can have 'cover', 'front', 'back'. 12 is long enough to have a long text and still guess the content. Page numbers are important, but without the text in the TOC they become useless.
Created attachment 225923 [details] Screenshot with the fix proposed This is how it looks after applying the patch.
Nice, thanks. I think it'd be still better if the two columns didn't have to be completely separate like in my mockup, so that in your screenshot "Normative references" could still be spelled out completely since there's plenty of space to the "3". I do understand however that making variable-width columns isn't possible (I think?) with the GTK treeview (?) and to implement it you'd have to render both into a single column which might be tricky with alignment. (Although, maybe you can put an hbox & two labels into each cell? I don't really know the programming model well enough to comment on that...) Anyway, this is a HUGE improvement, in particular for this document, but I suspect it won't be the only one. I haven't run into this bug as much since the -2012 version of the 802.11 spec got rid of the extra long page name, now just calling it "Cover-front". I guess they ran into the same bug in some other viewers :-) Thanks!
(In reply to comment #6) > Nice, thanks. > > I think it'd be still better if the two columns didn't have to be completely > separate like in my mockup, so that in your screenshot "Normative references" > could still be spelled out completely since there's plenty of space to the "3". > > I do understand however that making variable-width columns isn't possible (I > think?) with the GTK treeview (?) and to implement it you'd have to render both > into a single column which might be tricky with alignment. (Although, maybe you > can put an hbox & two labels into each cell? I don't really know the > programming model well enough to comment on that...) I wonder how necessary is the page number after all. In a paper book it makes sense the page number, because the reader has to go manually to the page. However, in a PDF reader it is only necessary to select the topic/index/whatever and the PDF reader go directly to the page.
Review of attachment 225922 [details] [review]: Excellent! thanks.
(In reply to comment #6) > Nice, thanks. > > I think it'd be still better if the two columns didn't have to be completely > separate like in my mockup, so that in your screenshot "Normative references" > could still be spelled out completely since there's plenty of space to the "3". > > I do understand however that making variable-width columns isn't possible (I > think?) with the GTK treeview (?) and to implement it you'd have to render both > into a single column which might be tricky with alignment. (Although, maybe you > can put an hbox & two labels into each cell? I don't really know the > programming model well enough to comment on that...) > Yes, I agree we could try to improve it using a custom cell layout or something. For now, let's commit this patch that already improves the result a lot, and then let's try to make it even better :-)
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.
I forgot to add the commit id: http://git.gnome.org/browse/evince/commit/?id=36d7e9ec3306b48803787d1d1ed79756677b93dd