When compiling a latex file containing a postscript figure, viewing the dvi file afterwards with xdvi does not render the postscript figure. That used to be fine with mga6 and our previous version of texlive. Files attached for checking. Compile with: latex test.tex this produces the file test.dvi. Open the file with: xdvi test.dvi enjoy the missing figure. You can check that the dvi file is correct, if you open it with, for instance "emacs", the figure is properly rendered. Cheers, Chris.
Created attachment 11078 [details] source latex file The file to compile with "latex"
Created attachment 11079 [details] A postscript figure that is included. Postscript figure that should be in the same directory as the test.tex file before compiling with "latex test.tex"
Assigning to our registered texlive maintainer.
Assignee: bugsquad => mageiaCC: (none) => marja11
It looks like this is a ghostscript problem: https://bugs.archlinux.org/task/56284 1) requirement to ghostscript-module-x is added for the future 2) made a few tests, looks like ghostscript is to blame, using ghostscript from mga6, xdvi works as expected. So as stated by arch linux there is a API change, we use texlive 2018 and gs 9.27, so both should work with the new API. I know xdvi is a small and handy tool, but maybe some of the desktop tools like evince kdvi, ... are working better.
Nope, that does not seem to be the cause of the bug, ghostscript-module-X is installed, it is indeed 9.27.1mga7 together with texlive 2018. The bug is opened for mga7 only, I had no issue with mga6 in the past, so there is a breakage with 9.27 and 2018. cheers, chris.
as said, xdvi works with "old" ghostscript but not with the newer one. So I guess ghostscript has done some more api changes which not have been adapted to xdvi (2018). I'll have a look, if a newer version of xdvi fixes this issue.
Severity: normal => minor
Ok, I understand what you say. So report it upstream,that's clearly a texlive bug, they do maintain xdvi!
@Chris: for testing purpose, I've built the latest 2019 package, bit still not image in xdvi. E.g. atril (with atril-xdvi) works as expected.
Thanks for the suggestion of alternatives. I've also tried okular and evince. It is amazing that none of this new dvi readers are actually as good as xdvi!!! atril and evince do not support hyperlink...okular does, but it takes like more than 5 secs on my super fast machine (xeon 2 cpu 3.1GHz, 48 cores, 132Gb of RAM) to open a dvi file... no comment :)
did you report this issue upstream? any feedback yet?
Nope, I thought you did... ;) I will then!
Finally, this bug has been fixed upstream, xdvi works again in mga8. Let's close as wontfix for mga7.
Resolution: (none) => WONTFIXStatus: NEW => RESOLVED
This bug is back again on Cauldron :(
Status: RESOLVED => REOPENEDResolution: WONTFIX => (none)Version: 7 => Cauldron
Just a comment: I am working with a book of 700 pages, none of the modern tools open the output file in a fraction of a second. Making a pdf takes a minute. xdvi is a must.
I assume ps takes as long as generating pdf output? I must admit I always worked with ps/pdf output, because it is not the first time dvi output was incorrect. Do u know, what has been fixed upstream, as you mentioned this in Comment 12?
I'll try to dig upstream, but, each time, it seems to be an API change in ghostscript not propagated to xdvi. As a matter of fact, "gv" (I am the maintainer of) is broken as well, it does not open ps figures anymore. I suspect that this is the same API change in ghostscript breaking it.
ok, great. We can add a patch, and/or push it updstream, if we know where/why.
Usally api changes should break compilation. So changes can be made to applications using the api. Looks like they don't do it here :(
Pff, I don't understand anything, on Cauldron, xdvi is again able to read the figures. Did you change something? I'm closing again :)
Resolution: (none) => WORKSFORMEStatus: REOPENED => RESOLVED
Oh, Ghibo pushed a new version of ghostscript, that explains! Mon Oct 17 2022 ghibo <ghibo> 10.00.0-4.mga9 + Revision: 1897255 - Fix more upstream bugs Adding her/him in CC.
CC: (none) => ghibomgx
This new version of ghostscript is also fixing gv. Thanks Ghibo.
Great
Thanks. As for gv since you are the maintainer (I forgot to notify you before, sorry), I've also refreshed gv (a little tool of great use) with a couple of extra security patches/segfault fixes too. It's a little bit improved: now supports also the wheel mouse, you can go up/down to scroll and then shifting automatically to the next/previous page that in previous couldn't. For gs, it was pretty a sneaky bug on the X plugin introduced in gs -> 10.0 upgrade (it mainly only affected our gs). yes. xdvi render faster, and consumes tiny memory (because when it was designed you can't keep the whole render of a page in memory at 600dpi), at least text. For figures it uses ghostscript (or gs libs, don't remember exactly). If gs breaks then it breaks too (at least the PS figures rendering). Of course it's good for plain PS pictures (e.g. those produced by \includegraphics). For more complex graphics, e.g. those produced by pstricks (which collects the PS commands across many \special(ps:...) render may get faulty or having wrong positioning. Ditto if having graphics produced by pgf/tikz which (mainly) requires pdf. For speeding building of books it may be worththile to consider to use the \includeonly macro for including only the chapter(s) you are working on, without loosing the crossrefs of others.