You need also to post the .eps files. They are not embedded in the .dvi file. So currently I get no figures at all, only white space there.

Terminal shows warnings about missing figures:

till@till:~/ghostscript/testfiles$ xdvi xdvi-test.dvi 
xdvi.bin: Warning: Could not find graphics file "images/uniform/environment_generator_snapshot.eps"
xdvi.bin: Warning: Could not find graphics file "images/uniform/envs/unif_cov_sim_snapshot_84cell.eps"
xdvi.bin: Warning: Could not find graphics file "images/uniform/cell_visit_counter_30_1.00_side_1205733997.out.kl.eps"
xdvi.bin: Warning: Could not find graphics file "images/uniform/cell_visit_counter_30_1.00_side_1205733997.out.kl.eps"
...

Created attachment 7918 [details]
xdvi file WITH necessary image files, all zipped up

Yes, Till. Realized that after I shut down. Rebooted and uploaded info, before I even saw your kind reminder. 5 am and I do need some sleep. My bad. I've double checked this but if I'm STILL messing up let me know. Thanks, Bill

Thank you, now I can reproduce it.

Ghostscript command line is

gs -sDEVICE=x11 -dNOPAUSE -q -dDEVICEWIDTH=640 -dDEVICEHEIGHT=827 -dDEVICEXRESOLUTION=72 -dDEVICEYRESOLUTION=72 -dNOSAFER -dNOEPS -dSAFER -

Problem is that one cannot capture the PostScript input, as it is streamed in and not put in a file in /tmp/.

dvips <dvi file>

produces a PostScript file which renders correctly.

I could capture the input stream for Ghostscript by making a simple wrapper:

# mv /usr/bin/gs /usr/bin/gs.real
# echo 'tee /tmp/input | gs.real $*' > /usr/bin/gs
# chmod +x /usr/bin/gs

Then I got the attached file "input"

Created attachment 7919 [details]
input

Input data stream sent by xdvi to Ghostscript when being on the second page, zooming to level 5, and scrolling to see the figure at the upper right, cropped at the right.

Looking into the file input, one sees that Ghostscript is only used to render the EPS figures. The text is rendered and displayed by xdvi itself. The EPS figure is referenced three times: First for initial display of the figure when opening page 2 for the first time (figure is fully visible), second to display the upper left of page 2 when selecting zoom level 5 (Only left part of the figure is in the window, but this part is completely visible), and third when scrolling from the upper left part to the upper right part of the page (Now only the portion of the figure is shown which was already visible when the upper left part of the page was displayed, before scrolling, rest is white). This looks like that on the scrolling action the bounding box for the figure is not updated.

Created attachment 7925 [details]
Picture of 2nd page, using xdvi, with ghostscript 8.61

Note that the picture and bounding box are correct.

Created attachment 7926 [details]
Picture of 2nd page, using xdvi, with ghostscript 9.04

Note that the bounding box does indeed look correct, although the figure is still chopped.

There are several problems with the Postscript that xdvi appears to be emitting. Firstly, ignoring boolean return values from the "read" operator is a bad idea, and (as a result) relying on a Postscript error to exit a loop is a very bad idea. Also, it uses Ghostscript specific features such as "=string", "flushpage" and "execute" which are really subject to change without notice as they are not parts of the Postscript language.

Finally, the PS draws the diagram EPS multiple times, at different sizes, for no reason I can fathom.

This *may* be a Ghostscript bug, it may be the result of a valid change in behavior (in one of our custom operators), or it could be result of fixing a bug.

I think it would be beneficial if this problem was referred to the xdvi developers for them to either address the problem in their code, or at least to provide us with a more workable example of the failure.

Regardless, it would be nice the xdvi emitted Postscript to be improved.

I suspect the problem might be caused by commit:

5d2d901fd7f831dfd7c17fb89a2b9e0c9def8a54 - "Avoid that the x11 output device can create huge windows which crash the X server. Bug 690444."

I'm guessing that xdvi relies on the EPS being rendered to the X buffer in exactly the correct position, and the above commit seems to clamp the size of the buffer, thus affecting the dimensions and the relative position of elements inside the buffer.

I don't have a suggestion for a fix, except possibly to relax the clamping parameters applied to the buffer.

The input file indeed draws the figure three times, as it is from the whole xdvi session: First I advanced to the first page with a figure, causing the first draw of it, showing the whole page including the whole figure. Second, I zoomed the page to level 5 by choosing level 5 in the zoom menu, causing the second draw, showing only the left half of the figure. Third, I scrolled to the right, to see the whole figure, causing the third draw. The bug occurred only during the third draw: On the screen appeared only the left half of the figure, exactly the piece which was already visible after the second draw. The rest of the space for the figure was completely visible, but white.

Okay, that explains the multiple instances of the image.

I still feel that the commit I mentioned in comment #12 is the likely catalyst for the issue.

Unfortunately, one cannot simply remove the patch from comment #12 for a quick test. The place where it was originally applied has changed too much.

I used git bisect, and it showed that the commit in question caused the position of the diagram image (especially the larger zoom level) to move considerably in the window for x11alpha/x11 device.

I would suggest you build with the source from the parent commit (so that would be commit: c8baf695338d51f71654ea3a91511d281ac0f4ac), and test that it works. Then build with source from the 5d2d901fd7f831dfd7c17fb89a2b9e0c9def8a54 commit, and retest.

Built this stone-old version of GS now (it is somewhere in the middle of the 9.00 development cycle) and after getting it finally built and used under Oneiric, I tried it and the snapshot just before the patch in question already showed the bug. So this patch (5d2d901f) is not the culprit.

Drat! Okay, I'll spend some time tomorrow doing a bit more experimenting, and update here.

After a bit more digging, I think the cause is commit:

fdc70f473c99438e47d4f0607fb5fc8733e337ca :
"

    Use the page parameters set on the X11 device when called by Ghostview.
    
    This patch allows gv to control the output page parameters, overriding
    document and gs default settings. Since it has been tested in the
    Debian distribution and is contingent on being wrapped by the viewer,
    I consider it low risk.
    
    Original patch by William Bader. Bug 688943.
"

Unfortunately, removing that patch isn't really an option, at this stage (it dates from pre-8.64 Ghostscript). It seems that it clamps the page dimensions to those specific on the command line - this is obviously desirable for Ghostview, but not for xdvi(k).


There is a simple, quick'n'dirty change in the xdvik source which solves the problem: at line 855 in xdvik-22.84.16/texk/xdvik/psgs.c changing the conditional from:

    if ((GS_old && (globals.page.w > GS_page_w || globals.page.h > GS_page_h))
	|| GS_alpha != resource.gs_alpha)
	destroy_gs();

to

    if (((globals.page.w > GS_page_w || globals.page.h > GS_page_h))
	|| GS_alpha != resource.gs_alpha)
	destroy_gs();

Allows the zoom to work correctly. It does mean a slight loss of performance, as it means restarting Ghostscript each time the EPS needs displayed.

Currently, I can't see an alternative that doesn't involved a *lot* more work and, by implication, risk.

Chris, I tried to build the GS right before that patch, but I did not get it to build, probably much too old for the Oneiric environment. So I cannot check whether this patch is actually the culprit.

But as you have found a solution based on the XDVI code, I will stop searching in GS here.

William, can you report a bug to the XDVI developers citing Chris' comment #19? I think this would be the best solution.

I did test it with xdvi(k), and yes, it was a bit of a challenge to get that old version to build - I wouldn't blame Oneiric for that.

If you do want to confirm my findings, the patch is self contained and easy to remove in the 9.04 code. If you look in base/gdevxini.c at line 841, there is a comment and a conditional:

    /* Restore the original page size if it was set by Ghostview */
    /* This gives the Ghostview user control over the /setpage entry */
    if (xdev->is_open && xdev->ghostview) {
       dev->width = values.width;
       dev->height = values.height;
       dev->x_pixels_per_inch = values.x_pixels_per_inch;
       dev->y_pixels_per_inch = values.y_pixels_per_inch;
       dev->HWResolution[0] = values.HWResolution[0];
       dev->HWResolution[1] = values.HWResolution[1];
       dev->MediaSize[0] = values.MediaSize[0];
       dev->MediaSize[1] = values.MediaSize[1];
    }


That is the entirety of the patch, so simply removing/commenting out that block reverts the patch in question. With that done, xdvi(k) will work as expected, (but Ghostview won't).

We could provide an extra device parameter settable on the command line to prevent that conditional being entered - whatever we do will need changes to xdvi and xdvik.

Chris, tried your xdvi fix from comment #19 in Ubuntu's texlive package and it works. Thank you very much.

Great!

As I said, there would be scope for adding a device specific option to x11(alpha) that xdvi(k) could set on the command line so it would be able to resize the canvas . If you or the xdvi devs can let me know if that's wanted, I can make that happen.

Chris, William, the corrected XDVI is uploaded to Ubuntu Oneiric. So there the zoom works correctly now. See

https://bugs.launchpad.net/ubuntu/+source/texlive-bin/+bug/862536

I'm still using Natty. Is there some way for me to grab the new xdvi? I grabbed all the files from http://packages.ubuntu.com/oneiric/texlive-binaries and extracted xdvi but that didn't work for me... (same problem).

I'm still using Natty. Is there some way for me to grab the new xdvi? I grabbed all the files from http://packages.ubuntu.com/oneiric/texlive-binaries and extracted xdvi but that didn't work for me... (same problem).