[bug #24069] Table of Contents not displayed for large documents

[gry-3]

URL:
  <http://savannah.gnu.org/bugs/?24069>

                 Summary: Table of Contents not displayed for large documents
                 Project: GNU gv
            Submitted by: psfales
            Submitted on: Thursday 08/14/2008 at 20:02
                Category: Graphical User interface
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None

    _______________________________________________________

Details:

If gv attempts to display a DSC structured PostScript file with more than
about 2000 pages, the table of contents is not displayed correctly.   (The
behavior is hard to describe, but typically only page "1" is shown in the list
until "Next Page" and then "2" is also shown)

I've seen this in the official gv-3.6.3-2.fc8 package provided with  Fedora
8, the gv-3.6.3-3.fc9 provided with Fedora 9,  as well as a privately
built-from-source version of 3.5.8 and 3.6.5.

I'll be happy to provide more details or run tests.  I've poked around a
little with gdb, but since I don't know much about Xaw3d, it's hard to really
understand what's going on.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[gry-3]

Follow-up Comment #1, bug #24069 (project gv):

Thank you for reporting this bug.

THe following text from Bernhard R. Link describes the reason:

--- behin citation ---
I think this is basically a problem with the naive implemenentation variant
of scroll lists in Xt: You create a widget for the full list and just show a
specific part of it depending on some generic scrolling widget. While this
variant [...] is the most easy to implement and has some elgance in design, it
has the serious problem that X window dimensions are 16 bit.
--- end citation ---

In other words: It is an overflow of the coordinates where the page numbers
are displayed. That is easy to describe, but very hard to fix: One would have
to reimplement the whole page number panel.

@everyone: Contributions of a new page panel code are very welcome. Until we
find a contributor, the fix has to be postponed. I am not happy with that
solution, ut I cannot code the code myself as a big knowledge of Xaw(3d) is
required.

BTW: Up to 2184 pages are working for me, while 2185 pages and more are
causing problems.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[gry-3]

Update of bug #24069 (project gv):

                  Status:                    None => Postponed              


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[gry-3]

Follow-up Comment #2, bug #24069 (project gv):

Attached is a patch by Bernhard R. Link

(file #16905)
    _______________________________________________________

Additional Item Attachment:

File name: gv.patch                       Size:18 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

[gry-3]

Follow-up Comment #3, bug #24069 (project gv):

Patch looks good here!   The only thing I noticed was an extraneous (I
assume) debugging printf in Vlist.c



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[gry-3]

Update of bug #24069 (project gv):

                  Status:               Postponed => In Progress            
                 Release:                    None => 3.6.6                  

    _______________________________________________________

Follow-up Comment #4:

Thank you for your feedback.

Well, the patch is work in progress and it still hvae to be debugged. There
are minor bugs in the new code because I noticed the following bug caused by
the patch:

If you are viweing a document with only a few pages (let's say four pages in
order to give an example) and you switch to the last page, the page selection
panel is scrolled down without any need by one element.

But my first impression is still that the patch looks good. Please let me
know if you find other bugs caused by the patch. It will help deciding whether
the patch is fit to be released or needs to be improved before releasing it.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

[gry-3]

Update of bug #24069 (project gv):

                  Status:             In Progress => Fixed                  

    _______________________________________________________

Follow-up Comment #5:

Applied Bernhard's fix to CVS together with a small regression fix. See
Changelog for more details.

In GNU gv 3.6.7 (and all of its prereleases this bug will be fixed.

The debugging output in Vlst.c is changed so it will only be pinted if and
only if the option "--debug" is given at the command line.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[Bernhard R. Link-2]

* Markus Steinborn <INVALID.NOREPLY@...> [090101 20:48]:
> Applied Bernhard's fix to CVS together with a small regression fix. See
> Changelog for more details.

Nice to see this completed.

Testing the File dialog, I sometimes got some hangs and gdb always threw
me in some code that looks like O(n^2) where O(n) should be easily
doable:

Index: src/FileSel.c
===================================================================
RCS file: /sources/gv/gv/src/FileSel.c,v
retrieving revision 1.12
diff -u -r1.12 FileSel.c
--- src/FileSel.c 1 Jan 2009 18:47:17 -0000 1.12
+++ src/FileSel.c 2 Jan 2009 10:50:17 -0000
@@ -1299,7 +1299,7 @@
 {
   int i,e,l;
   USE_Arg(2);
-  char *d,*s;
+  char *d,*s,*p;
 
   BEGINMESSAGE(changeList)
   i=e=l=0;
@@ -1314,12 +1314,17 @@
   d = FS_XtMalloc(e*sizeof(char));
   s[0]='\0';
   i=0;
+  p = s;
   while (i<entries) {
-     strcat(s,list[i]);
-     strcat(s,"\n");
+     size_t len = strlen(list[i]);
+
+     memcpy(p, list[i], len);
+     p += len;
+     *(p++) = '\n';
      d[i]=' ';
-     i++;    
+     i++;
   }
+  *p = '\0';
   d[i]='\0';
 
   RESET_Arg;

The File dialog seems to also need some fine-tuning:

- the scrolling when dragging the window is reversed:
  (when the mouse moves down one, the content scrolls up
   and not down as it did before (though as it is limited
   to whole-item scrolling now it is of course never as
   nice as before)):

Index: src/FileSel.c
===================================================================
RCS file: /sources/gv/gv/src/FileSel.c,v
retrieving revision 1.12
diff -u -r1.12 FileSel.c
--- src/FileSel.c 1 Jan 2009 18:47:17 -0000 1.12
+++ src/FileSel.c 2 Jan 2009 11:00:03 -0000
@@ -1139,7 +1139,7 @@
  if (*nparams>=3) absfactor = atof((char*)(params[2]));
  absfactor = absfactor >= 0 ? (absfactor<=200 ? absfactor : 200) : 0;
  IIMESSAGE1(absfactor,relfactor)
-        if (REVERSE_SCROLLING) { dx = -dx; dy = -dy; }
+        if (REVERSE_SCROLLING) { dx = -dx; } else { dy = -dy; }
  childx = (int) (childx-(dx*absfactor)-(relfactor*childw*dx)/clipw);
  childy = (int) (childy-(dy*absfactor)-(relfactor*childh*dy)/cliph);
  ClipWidgetSetCoordinates(clip,childx,0);

- something in the height computation is flawed. In the font size I have
  here, the last item in the list is only visible by some pixel, but
  seems to be treated as visible. Which means that scrolling by clicking
  in the scroll bar lets the new list start after the no-really-visible
  item (thus effectively hiding every 10th item here. And that scrolling
  to the very end of the list does not shows the very last item (but
  only a few pixel rows not containing a single black pixel). It is
  selectable when clicking there, but when one does not know it is there
  one would not guess so.

- I think there was something else, but I forgot...

Happy new year,
        Bernhard R. Link

[Markus Steinborn-2]

Bernhard R. Link wrote:
> Testing the File dialog, I sometimes got some hangs and gdb always threw
> me in some code that looks like O(n^2) where O(n) should be easily
> doable:
>  
Thanks for this patch. I've apllied it.
> The File dialog seems to also need some fine-tuning:
>
> - the scrolling when dragging the window is reversed:
>   (when the mouse moves down one, the content scrolls up
>    and not down as it did before (though as it is limited
>    to whole-item scrolling now it is of course never as
>    nice as before)):
>  
Thanks for this patch. I've apllied it, too.
> - something in the height computation is flawed. In the font size I have
>   here, the last item in the list is only visible by some pixel, but
>   seems to be treated as visible.
With some window sizes, the same effect can be observed with the page
window.
>  Which means that scrolling by clicking
>   in the scroll bar lets the new list start after the no-really-visible
>   item (thus effectively hiding every 10th item here.
Well, let's try scrolling one item less than the old calculation should
do, but at least one element... Patch for this is checked in.
>  And that scrolling
>   to the very end of the list does not shows the very last item (but
>   only a few pixel rows not containing a single black pixel)
Here again the same is true for the page panel (if you are not using the
arrow to scroll down).
That is because the percent value does not reach 1 (i. e. 100%). This
means that scaling it to a position will not reach the end.
With very long file lists (tested with 4001 items) several items are not
reachable by the scroll bar. I do not know Xaw good enough to calculate
the largest possible percentage in order to rescale the values... I am
trying with debug outputs... May help or not...

I have found another bug. Sometimes the wrong list has been used. The
fix may fix your occasional crashes.

A happy new year

Markus Steinborn

[Bernhard R. Link-2]

* Markus Steinborn <gnugv_maintainer@...> [090102 21:08]:

> > And that scrolling
> >  to the very end of the list does not shows the very last item (but
> >  only a few pixel rows not containing a single black pixel)
> Here again the same is true for the page panel (if you are not using the
> arrow to scroll down).
> That is because the percent value does not reach 1 (i. e. 100%). This
> means that scaling it to a position will not reach the end.
> With very long file lists (tested with 4001 items) several items are not
> reachable by the scroll bar. I do not know Xaw good enough to calculate
> the largest possible percentage in order to rescale the values... I am
> trying with debug outputs... May help or not...

Indeed, the situation is worse than I thought. When I remember correctly
the TOC window case, it is quite of problematic because the situation is
quite messy (the Vlist window being in some layout widget, being in the
scroll widget still doing horizontal scrolls), so getting the actual
visible area reliable is quite hard.

The original code uses the layout widget size (aaa->core.height) and
the clip widget size (clip->core.height).

The following diff changes that to give the core.height to the Vlist
widget so it can say how many fit in there:


Index: src/FileSel.c
===================================================================
RCS file: /sources/gv/gv/src/FileSel.c,v
retrieving revision 1.15
diff -u -r1.15 FileSel.c
--- src/FileSel.c 2 Jan 2009 20:03:50 -0000 1.15
+++ src/FileSel.c 3 Jan 2009 10:21:19 -0000
@@ -1875,13 +1874,12 @@
     else if (s[0] == 's') { clip = FS_SUBCLIP; aaa = FS_SUBAAA; scroll = FS_SUBSCROLL; list = FS_SUBLIST; }
     else style=0;
     if (style == SCROLL_SCROLLPROC || style == SCROLL_JUMPPROC) {
-      int x,y;
+      int x;
       x = (int) aaa->core.x;
       ClipWidgetSetCoordinates(clip, x, 0);
       if (((int)(intptr_t)client_data)==1)
       {
          int dy = (int)(intptr_t)call_data;
-         float h = (float)aaa->core.height;
          int ly = ((VlistWidget)list)->vlist.ydelta;
 
          /* Just scroll one position less... */
@@ -1889,21 +1887,21 @@
          if (dy<-ly) dy+=ly;
 
          VlistMoveFirstVisible(list, VlistGetFirstVisible(list), dy);
-         if (h < 1.0) h = 1.0;
-         XawScrollbarSetThumb(scroll,VlistScrollPosition(list),(float)clip->core.height/h);
+         XawScrollbarSetThumb(scroll,VlistScrollPosition(list),
+      VlistVisibleLength(list,clip->core.height));
       }
       else
       {
          float *percent = (float *) call_data;
-         float h = (float)aaa->core.height*2;
-         if (h < 1.0) h = 1.0;
-            VlistSetFirstVisible(list, (int)(VlistEntries(list)**percent));
+#if 0
+ printf("scrolling to %f\n", *percent);
+#endif
+ VlistSetFirstVisible(list, (int)(VlistEntries(list)**percent));
       }
 
     } else if (style == SCROLL_CLIPREPORT) {
-      float h = (float)aaa->core.height*2;
-      if (h < 1.0) h = 1.0;
-      XawScrollbarSetThumb(scroll,VlistScrollPosition(list),(float)clip->core.height/h);
+      XawScrollbarSetThumb(scroll,VlistScrollPosition(list),
+      VlistVisibleLength(list,clip->core.height));
     }
   }    
   ENDMESSAGE(cb_scroll)
Index: src/Vlist.c
===================================================================
RCS file: /sources/gv/gv/src/Vlist.c,v
retrieving revision 1.9
diff -u -r1.9 Vlist.c
--- src/Vlist.c 1 Jan 2009 11:43:42 -0000 1.9
+++ src/Vlist.c 3 Jan 2009 10:21:19 -0000
@@ -979,5 +979,35 @@
 {
   VlistWidget vw = (VlistWidget)w;
 
+#if 0
+  printf("Scroll position %d/%d=%f\n",
+  vw->vlist.firstVisible,(int)(vw->vlist.entries),
+  vw->vlist.firstVisible/(float)(vw->vlist.entries));
+#endif
   return vw->vlist.firstVisible/(float)vw->vlist.entries;
 }
+
+float VlistVisibleLength(Widget w, unsigned int height)
+{
+  VlistWidget vw = (VlistWidget)w;
+  float percent;
+  int entriesvisible = -1;
+
+  if (vw->vlist.ydelta > 0) {
+    if (height < 0) entriesvisible = -1;
+    else            entriesvisible = height/vw->vlist.ydelta;
+  }
+#if 0
+  printf("fitting %d entries of height %d in %d",
+  entriesvisible, (int)vw->vlist.ydelta, (int)height);
+#endif
+  if (entriesvisible >= vw->vlist.entries)
+  entriesvisible = vw->vlist.entries;
+#if 0
+  printf(", visible percents %d/%d=%f\n",
+  entriesvisible,(int)(vw->vlist.entries),
+  entriesvisible/(float)(vw->vlist.entries));
+#endif
+  percent = entriesvisible/(float)(vw->vlist.entries);
+  return percent;
+}
Index: src/Vlist.h
===================================================================
RCS file: /sources/gv/gv/src/Vlist.h,v
retrieving revision 1.4
diff -u -r1.4 Vlist.h
--- src/Vlist.h 1 Jan 2009 11:42:47 -0000 1.4
+++ src/Vlist.h 3 Jan 2009 10:21:20 -0000
@@ -136,5 +136,6 @@
 extern void VlistSetFirstVisible(Widget, int);
 extern void VlistMoveFirstVisible(Widget, int, int);
 float VlistScrollPosition(Widget);
+float VlistVisibleLength(Widget, unsigned int);
 
 #endif /* _Vlist_h_ */

This already improves the situation a bit (Once it is finished,
it might also be needed for TOC listing).

The remaining issues seem to come from the Scrollbar, I fear.

With --disable-scrollbar-code, the patch leads to file windows that
scroll to the end find, but with really many items, scrolling to the
very first makes problems (with 80000, the first 6 seem to be missing,
looks like scrollbar does not generate scrolls to less then 0.0001).

With --enable-scrollbar-code, the first entries are reachable fine, but
at the end still quite some entries are missing. (and looking at the
values it sends, percent is still lower than (1 - the last visible length
given), so I guess this is in the scroll code)

Hochachtungsvoll,
        Bernhard R. Link

[gry-3]

Update of bug #24069 (project gv):

             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up Comment #6:

Bugfixed version has been released.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24069>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/