Viewers for PDF, PS, and DVI ⇒ Alternative DVI Viewers
Alternative DVI Viewers
Using TeXnicCenter and MiKTeX with Yap viewer for DVI output currently. Yap doesn't have options I want in a DVI viewer (easy zooming to 100% or fit, etc...), so I'm trying to find something else to use. Any suggestions for other DVI viewers?
I like the TeXworks viewer that comes with MiKTeX, but unfortunately it doesn't seem to handle DVI files.
I like the TeXworks viewer that comes with MiKTeX, but unfortunately it doesn't seem to handle DVI files.
- localghost
- Site Moderator
- Posts: 9201
- Joined: Fri Feb 02, 2007 12:06 pm
Re: Alternative DVI Viewers
Why do want to look at the DVI output at all? DVI is only an intermediate format and not intended to show the final output. Most viewers have difficulties in rendering postscript stuff correctly. Furthermore this format doesn't embed external graphics.
LaTeX aims more and more for PDF as final output format, be it by compiling directly with PDFLaTeX or indirectly with LaTeX to DVI with subsequent conversion via PS to PDF. And TeXworks accommodates to that with its internal PDF viewer and its settings for PDF producing compiler engines.
Best regards and welcome to the board
Thorsten
LaTeX aims more and more for PDF as final output format, be it by compiling directly with PDFLaTeX or indirectly with LaTeX to DVI with subsequent conversion via PS to PDF. And TeXworks accommodates to that with its internal PDF viewer and its settings for PDF producing compiler engines.
Best regards and welcome to the board
Thorsten
How to make a "Minimal Example"
Board Rules
Avoidable Mistakes[/size]
¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1
Board Rules
Avoidable Mistakes[/size]
¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1
Re: Alternative DVI Viewers
I would like to use pdf as the output, but my compile times increase quickly when I include only a few images. For example, my current document contains about 10 pages of text and 10 diagrams, and the compile time is ~6 seconds. The diagrams are relatively simple, mostly .eps format or .png.
Including just one of the eps files which contains 100 circles increases the compile time by ~1 second, and I can't figure out why. I am using the epstopdf package which converts the eps files during compile, but watching the console output during compile shows this is almost instantaneous.
Not embedding the images by using dvi output means that I can reliably compile in about 1 second, and is the only way I've found to speed up the compile process.
I've tried compiling with/without text and images and achieved the following times:
pdf:
no text, no images: 1 second
text, no images: 1 second
text, images: 6 seconds
dvi(no raster images):
no text, no images: 1 second
text, no images: 1 second
text, images: 1 second
Including just one of the eps files which contains 100 circles increases the compile time by ~1 second, and I can't figure out why. I am using the epstopdf package which converts the eps files during compile, but watching the console output during compile shows this is almost instantaneous.
Not embedding the images by using dvi output means that I can reliably compile in about 1 second, and is the only way I've found to speed up the compile process.
I've tried compiling with/without text and images and achieved the following times:
pdf:
no text, no images: 1 second
text, no images: 1 second
text, images: 6 seconds
dvi(no raster images):
no text, no images: 1 second
text, no images: 1 second
text, images: 1 second
- localghost
- Site Moderator
- Posts: 9201
- Joined: Fri Feb 02, 2007 12:06 pm
Alternative DVI Viewers
It will make almost no difference if you compile directly to PDF or via conversion. The compilation to DVI seems fast, but you didn't take the time for the subsequent conversion for the whole document into account. And of course the conversion needs time.
As far as I know, using the epstopdf package only converts the images once, hence following compilation processes should go faster. On modern TeX distributions (TeX Live 2010 and newer, MiKTeX 2.9) this package is not necessary any more. I still think that you are better with direct compilation by PDFLaTeX.
As far as I know, using the epstopdf package only converts the images once, hence following compilation processes should go faster. On modern TeX distributions (TeX Live 2010 and newer, MiKTeX 2.9) this package is not necessary any more. I still think that you are better with direct compilation by PDFLaTeX.
How to make a "Minimal Example"
Board Rules
Avoidable Mistakes[/size]
¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1
Board Rules
Avoidable Mistakes[/size]
¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1
Re: Alternative DVI Viewers
I'm trying to view the dvi directly so I don't need to perform the dvi->pdf conversion. The final paper will be output in pdf, but for local editing and viewing I don't care what format it's in(as long as I can see the formatted document with images).
I am using the Miktex texify command if that makes a difference (it can output pdf or dvi).
The epstopdf package seems to perform the conversion on every compile, and there are no converted pdf files remaining after the compilation process completes. I am using Miktex 2.9, so is there a better way to include eps files?
Thanks for your you help btw.
I am using the Miktex texify command if that makes a difference (it can output pdf or dvi).
The epstopdf package seems to perform the conversion on every compile, and there are no converted pdf files remaining after the compilation process completes. I am using Miktex 2.9, so is there a better way to include eps files?
Thanks for your you help btw.
- localghost
- Site Moderator
- Posts: 9201
- Joined: Fri Feb 02, 2007 12:06 pm
Re: Alternative DVI Viewers
As far as I know there is a Wind0ws port for Evince available. It is a multi-format viewer not only for DVI. So I suggest to give this a try.
How to make a "Minimal Example"
Board Rules
Avoidable Mistakes[/size]
¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1
Board Rules
Avoidable Mistakes[/size]
¹ System: openSUSE 42.2 (Linux 4.4.52), TeX Live 2016 (vanilla), TeXworks 0.6.1
Re: Alternative DVI Viewers
Evince looks like it might be ok, unfortunately it seems working dvi support never made it into the windows version since it crashes when trying to open one. I'm trying to install and configure some supporting libraries, but no luck yet.
Re: Alternative DVI Viewers
Found part of the reason for slow pdf compilation: using -c option for texify. The documentation states this "removes all auxiliary files", but apparently old versions of the files can be used to speed up the next compilation.
Removing the -c option and adding -q (hide text output) brings the compilation down to 2-3 seconds for pdf. This also has the side effect of allowing pdfs created by epstopdf to remain after compilation, though this does clutter the folders somewhat.
It's still not as fast as dvi, but is a little more usable for me now.
Removing the -c option and adding -q (hide text output) brings the compilation down to 2-3 seconds for pdf. This also has the side effect of allowing pdfs created by epstopdf to remain after compilation, though this does clutter the folders somewhat.
It's still not as fast as dvi, but is a little more usable for me now.
Alternative DVI Viewers
I have yet another reason for using YAP.
IT gives me (used to) an "Inverse DVI search" (from DVI to the Editor).
That is certainly not possible in pdf/texworks
IT gives me (used to) an "Inverse DVI search" (from DVI to the Editor).
That is certainly not possible in pdf/texworks
Alternative DVI Viewers
You are wrong. Almost all LaTeX editors with build in PDF viewers do support forward and inverse search. Usually to do a forward search, right-click on text in the source window and choose the optionjaslam810 wrote:I have yet another reason for using YAP.
IT gives me (used to) an "Inverse DVI search" (from DVI to the Editor).
That is certainly not possible in pdf/texworks
Jump to PDF
. To do an inverse search, right-click in the output window and choose Jump to Source
. Mostly these even work using an external PDF viewer, but surely not with every PDF viewer.My main topics are KOMA-Script and other questions related to my packages. If I reply to any other topic or if you've not yet added a minimal working example, please do not expect any further response. And please don't forget to tag examples as code.