Re: is xdvi broken?
rlharris, on 2019-04-20 :
> On 2019.04.19 20:24, David Wright wrote:
> > But it's interesting to see that you're (still) using a DVI workflow:
> > any particular reason for this? I suspect a majority are using one of
> > the direct-to-PDF workflows, like pdflatex or lualatex.
>
> I use this workflow simply because it is the only Linux
> workflow with which I am familiar. Migration to Linux was
> motivated by one of the few genuine Y2K bugs; MS Word 5.0 for
> DOS, which was the last rodent-free version, began writing
> garbage to the document file. I abandoned multiple dozens of
[snipped long, yet interesting and informative, story.]
>
> A few months ago I learned about latexmk, and used it
> successfully with the -pcv option in Debian 8; that worked
> well, providing all the output files I need, in addition to an
> xdvi file which I use as I compose. But when I installed
> Debian 9, this instability problem appeared, making latexmk
> unusable.
Good Day,
Thank you for the history you are sharing! I suppose we could
find alternative worklflows well established in recent Debian
versions.
If you wish to stick to DVI, it would be possible to render
these files directly into emacs apparently, but I don't know if
there is a setup similar to the -pvc option of latexmk; I am not
an Emacs user. Anyway, this functionality is documented here,
if you need more details:
https://www.gnu.org/software/emacs/manual/html_node/emacs/Document-View.html#Document-View
Otherwise, on my side, I'm using a Makefile for my PDF based
workflow. On the PDF viewing side, I use zathura and keep it
open on a side window; when the document updates, zathura
reloads it automatically. I believe viewers such evince will do
this kind of job very well too. Finally the main environment I
use to do such a job is Debian 9, using Xfce, and without much
issue worth nothing for almost two years (well except maybe the
few occasions where zathura got stuck, after redraw attempts on
not well formed PDF documents). I will move this work
environment to Debian 10 once it becomes Stable.
Basically I put a Makefile in the directory in which I typeset
my LaTeX document, and when I want to see changes, I save the
document and run the simple command "make". Knowing Emacs by
reputation, I'm pretty much certain that there is a shortcut for
doing the "save and run `make`" step in one shortcut (M-x
compile perhaps).
Initially, my directory would have the two following files:
$ ls
Makefile my_document.tex
The corresponding Makefile would look like the following one
which you can use as a template. Careful when copy and pasting,
as indentation using <Tab> instead of spaces is important:
# ==================== BEGIN "Makefile" ====================
DOCUMENT = my_document.tex
# Use this variable if the document includes other files
INCLUDES = # ex: chapter1.tex picture.png docs/datasheet.pdf
pdf: $(DOCUMENT:.tex=.pdf) # Swap thes two lines, if you want to
all: pdf ps # build all every time you type make
ps: $(DOCUMENT:.tex=.ps)
%.pdf: %.tex $(INCLUDES)
@ pdflatex -draftmode $< \
&& pdflatex $<
%.ps: %.pdf
@ pdf2ps $<
clean:
@ rm -vf *.log *.aux *.toc
mrproper: clean
@ rm -vf $(DOCUMENT:.tex=.pdf) $(DOCUMENT:.tex=.ps)
.PHONY: all pdf ps clean mrproper
# ==================== END "Makefile" ====================
This Makefile will trigger rebuilds of LaTeX twice, to include
changes to cross references properly. The use of -draftmode
speeds-up the first build, as it does not touch the pdf, only
auxiliary files. If several files are included for producing
the final document, put their names in the INCLUDE variable, so
that their changes are taken in account too. It is not perfect,
but does the job. To trigger said rebuild from the command
line, first save your file, then use:
$ make
Then, pdflatex runs, the PDF is produced, and zathura, or
evince, redraws the document automatically, should no error
occur. Once you are happy with your document, run the following
to produce all your version (here the PS file) of the document,
ready for publication:
$ make all
Once you are done, you can run the following command to clean up
all the LaTeX files left over the place:
$ make clean
removed 'my_document.log'
removed 'my_document.aux'
In case something goes wrong and your document builds are stuck,
you can also take advantage of the mrproper target to start
anew:
$ make mrproper
removed 'my_document.log'
removed 'my_document.aux'
removed 'my_document.pdf'
removed 'my_document.ps'
David Wright, on 2019-04-20:
> On Fri 19 Apr 2019 at 18:10:14 (-0500), rlharris@oplink.net wrote:
> > On 2019.04.19 17:33, Étienne Mollier wrote:
> > > Are you running your Xfce desktop with or without the
> > > compositor ?
> >
> > I found the menu; ENABLE DISPLAY COMPOSITING was checked. I
> > was unaware of the "tweaks" menu.
>
> That's the sort of thing I can't interpret (as a DE non-user),
> but it could be related to the previous paragraph. (That's just
> a guess.)
If you uncheck it, you may discover the xdvi redraw I mentioned,
under the form of a flickering when you hover the DVI document
with a window. The compositor keeps in memory the content of
every window, older behaviour without compositor was to recompute
the content of windows each time they were uncovered. If xdvi
has been programmed initially to work with these X events, then
deactivating the compositor could help perhaps.
> The gnome approach must appeal to the video gamer;
As a, formerly, heavy video gamer, I say: "No". Every CPU cycle
counts. Gnome interferes too much with the OpenGL layer; I lose
a bit more FPS after every releases. My window manager for such
purpose is dwm for a few years. :)
Kind Regards,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Reply to: