GNOME Bugzilla – Bug 676593
In the index tree, more text could be displayed before ellipsis
Last modified: 2013-02-20 15:36:12 UTC
In a PDF file with a multi-level index, the text will be ellipsisized to fit tree and page number in the available width. The issue is that the maximum width before ellipsis is calculated at leaf level of the tree but applied everywhere leaving the texts near the root cut early with lots of space between ellipsis and page number. Example: long title here abc abc ---- long title here abc abc ---- ---- long title here abc abc If there is space to show "long title here" on the third level, the first "abc" of the second row would also fit (more or less, modulo font), as would both "abc" on the root item, but instead the text is cut at the same point on all levels.
Created attachment 225973 [details] Screenshot with an index wih several levels In the screenshot attached you can see that in the same tree, some leafs are shown properly. For instance, see: 8.4, 8.4.3, 8.7. Maybe number '8' can slightly reproduce the behaviour you describe, but it would be a matter of pixels. Which you also have to consider the padding and spacing for each one. Can you show a test case where the bug is triggered?
Confirming, Germán, please see http://www.dim.uchile.cl/~jaliste/tree_view_problem.png where I put some background colors to the cell renderers.. You can clearly see that the top cells are shrinking, which is a bug... I am not knowledgable enough in GtkTreeView to decide if this is a GtkTreeView bug or an evince bug.
It is an evince bug. I cooked a test case using a GtkTreeView and it works as expected.
Testing a bit more, it is a problem that happens when two columns are packed (title, page), as it happens in: http://git.gnome.org/browse/evince/tree/shell/ev-sidebar-links.c#n420 I think it is related to: https://bugzilla.gnome.org/show_bug.cgi?id=660113 A solution could be to reduce 'max-width-chars' to something like 3 instead of 12.
Created attachment 236230 [details] Different values for max-width-chars The screenshot shows the behaviour with 3 different max-width-chars for the page number column. 3 is definitively to small. 6 is good enough for showing numbers from 0 to 9999. 12 seems a bit high. The drawback of choosing a small max-width-size is the column does not expand wider than that value even if there is enough empty space. José, in the screenshot at the right that you linked, there are 2 separated columns. If the page number is too wide, the first column would have less space. This is tricky in documents (books) with long page numbers (for instance, 'preface' or the one linked in bug 660113. Another alternative is to use a custom cell layout or similar, as suggested by Carlos in https://bugzilla.gnome.org/show_bug.cgi?id=660113#c9. However, I am not sure whether the effort is worth. TL;DR: 6 seems like a good default.
I am not so sure that this is a bug in evince... When everything is not expanded, the Treeview already gave enough space to all the cells on the right. There is no apparent reason why the Treeview is then giving more space to cells that were already being correctly shown before expanding an item. It seems really like a bug in Treeview to me. Other thing would be to put the cells in different columns.
Created attachment 236338 [details] Test case for packed columns in a GtkTreeView FWIW, before checking the packed renderers in a column it seemed to me it was a bug in Evince, maybe triggered by 'max-width-chars' and exacerbated by its default value (12). Also I tried it with the treeview expanded, which was not the best way to reproduce the behaviour. Anyhow, the problem seems to be in how 2 packed text renderers are drawn. It seems the renderer width (text and page number) is calculated with the values to be shown, not the whole model. So, when you expand the one node, the new width of each rendered is recalculated and it considers the wider value needed (or 'max-width-chars' if defined and lower). I think this is the purpose of packing two or more renderers, that is, to be adjusted on demand and as needed. Regardless of the width of the page number, every time a new level is expanded, the higher levels of the treeview get the equivalent of 2 extra characters (for the page number), or in other words, 2 characters less for the title. This sounds like a bug to me, because it takes space out from the first column without requiring extra space. Maybe this bug is related with https://bugzilla.gnome.org/show_bug.cgi?id=168654. Once the width is set, it does not go back. This can make the table of contents unusable (or any GtkTreeView). Using separated columns and setting 'width-chars' in the rendered produced the expected effect. It uses a less space as possible, and it is expanded as needed, but defining width-chars + ellipsis it does continue growing.
Created attachment 236340 [details] [review] [PATCH] shell: Show as much text as possible for index tree This patch makes, what I think, a good compromise between space for index text and page numbers.
Created attachment 236341 [details] [review] [PATCH] shell: Show as much text as possible for index tree I forgot a couple of casting.
Review of attachment 236341 [details] [review]: Pushed to git master, thanks!