When viewing DVI files that contain tikz graphics (which is becoming the standard for graphics in TeX documents), text labels are misplaced. Using the same TeX file to generate a PDF document, the graphics shows properly Reproducible: Always Steps to Reproduce: 1. open the attached DVI file in the okular viewer
Created attachment 73430 [details] sample tex file
Created attachment 73431 [details] DVI file generated out of sample TeX file. Does not show properly.
Created attachment 73433 [details] PDF file generated out of sample TeX file. Does show properly.
I tried both xdvi and evince and both of them show it the same way we do. Maybe it's a bug in tex->dvi generation? Do you have any dvi viewer that shows the file correctly?
For the record, tested also on: - yap 2.9.4206 (from MiKTeX 2.9): wrong rendering, also the curves completely messed up. - kdvi 1.4 from KDE 3.5.10: same rendering, so it's not a regression in the okular dvi generators which inherits that code.
The question rather was, if you know of a DVI viewer, where it is shown _without_ bugs (to prove that the DVI file is correct).
The DVI file that I uploaded can be converted to a correct PS file using the dvips program under Linux. It also shows correctly in TeXShop under MacOS.
Could you please attach such screenshot of such MacOs software?
> Could you please attach such screenshot of such MacOs software? Sure. Please note that TeXShop converts the DVI file to PDF internally (hence the window title). I made absolutely sure the my Mac's harddisk contains only the DVI file. The PDF oder TeX files have never been uploaded to my Mac. You might also be interested to know that DVI file prints file from okular. But this is probably because the printing uses dvips internally, and dvips interprets the DVI file correctly...
Created attachment 73527 [details] Screenshot from my Mac, showing the TeXShop shows the file correctly
To be honest i'm still not convinced the dvi file is correct, since as you say TeXShop is running dvipdf on the file. I'm not a dvi expert either to confirm or reject so i'll leave it as unconfirmed until someone can prove it's wrong or not.
Created attachment 78085 [details] An other dvi file with same problem.
Created attachment 78086 [details] This is how my dvi file is rendered by okular
Created attachment 78087 [details] this is how my dvi file is rendered by okular Sorry, i made something wrong in comentary 13, and dont know how to delete or edit.
The dvi file i attached is correctly displayed by yap, and also after dvips and ps2pdf the result is a correct pdf file. here is a snapshot of yap: https://www.dropbox.com/s/dfkjp86v5azrf4f/SceenShot.PNG I tested this compiling both with texlive and with miktex.
http://tex.stackexchange.com/questions/5826/tikz-with-positioning-does-not-work-with-dvi This is basically not a bug, unless someone wants to include gs parsing on our dvi backend I've been having a look at the file and what happens is draw("G1") somePSCommands draw("G2") it happens that those ps commands move where G2 would end up but since we don't do PS parsing G1 and G2 end of top of eachother Comments?
Now I understand it's not a bug, and can also guess why dvips solves the problem. Including or not ps parsing in dvi frontend is a developers decision. And I'm not a developer. So I'll argue from user point of view. Philosophically, a dvi parser should not parse ps. In the other side, there is an integration issue with kile. tikz is becoming an usual package in latex. Not so long ago, tikz came with a warning telling it should be compiled with pdflatex (I read that in todonotes documentation), and that was a pain in systems which didn't support backward search of pdf. I guess that is why someone implemented that mixture of ps and dvi. One can blame tikz developers, one can go with mixing dvi and ps, or, as kile + okular does manage backward search of pdf, one can try to find a compromise solution. Actually I'm doing that by hand: depending on which machine I'm using, I use kile|pdflatex|okular, or texnikcenter|latex|yap. I wander if it is a good idea or not making kile to detect that tikz issue and warn the user or even change it automatically.
You can create a bug/wish for the kile product in bugs.kde.org about that, i'm sure the kile devels are happy to help. Actually one of my ideas yesterday was to try to detect if the file had been genereated using tikz and offer the user to run dvipdf ourselves, but couln't find a way to distinguish such a file