Re: is xdvi broken?
On Fri 19 Apr 2019 at 22:39:01 (-0500), rlharris@oplink.net wrote:
> 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.
Then it might be worth revisiting your deliverables and seeing whether
a DVI workflow is still worth using after two decades.
> My workflow back then was (1) composition on a DOS machine,
Back in the 1990s with DOS6.22, one could run LaTeX to preview with
DVI and print with PS files by using systems such as emtex.
> The documents I compose range in size from two or three pages to
> roughly a hundred pages. Some are destined for the Web, in which case
> I generate HTML for on-line viewing and PDF for visitors who wish to
> download and print a copy for study or to file. All documents need to
> be available in Postscript, for local printing and distribution by
> mail.
It's too long to remember exactly how I produced output for both
static HTML pages and hardcopy. I still have macros for the hyperlatex
package (CTAN, not .deb), but I also used tex4ht which I see is still
available in texlive-htmlxml.deb. It's 15 years since I retired from
that job.
So you expect that visitors can print from PDFs but you print locally
with PS. Any reason? My (UK) printers were always satisfied with PDFs,
one with camera-ready double pages (in signature order), the other
with straightforward page order. I would proof the layout with
double pages in spread order and, with PDFs, a tool like pdfjam can
shuffle the pages as necessary.
> I employ all manner of LaTeX markup, with sections, subsections,
> subsubsections, and paragraphs, and I use enumerated lists, bulleted
> lists, and footnotes. Keeping everything straight necessitates that I
> constantly switch between the emacs screen and the xdvi screen as I
> compose.
How do you "switch" between them?
> 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.
>
> > How do you deliver this document? As a DVI, PS of PDF? Is it typical,
> > or are your other documents more dependent on particular methods of,
> > say, including graphics?
>
> Graphics (line drawings) are needed only rarely. As I mention above,
> I need to deliver HTML, PDF, and PS, but I utilize DVI to approximate
> WYSIWYG composition.
OK, I was worried that you might be depending on various arcane
features like \specials, or specific graphics formats like
Encapsulated PS, to insert your graphics rather than just using
PDFs, PNGs and JPEGs as is normal nowadays.
Of course, a PDF preview will give a preview as close to WYSIWYG as
a DVI one, if that's what you like. (I prefer typing content into
a context that doesn't keep shifting around, and leave the layout
to a later phase when I'm not preoccupied with content.)
> > But looking at just emacs, xdvi, and xterm running in separate
> > windows, I can't see any difference in their behaviour from what I
> > remember in the dim and distant past. The one unusual (for me)
> > property of xdvi is that it rereads the input file whenever its window
> > is exposed, without needing a ^R keystroke. I have no idea whether
> > this might interact with certain sorts of window manager.
>
> Sadly, that property is not working on my Debian 9 system, and it is
> needed.
That's why I asked how you "switch" between them, above, in order to
find out what shortcut you're using that makes hitting "R" in the
preview window too onerous. I find a major advantage in not having
the viewer update itself automatically.
My own workflow has the PDF document displayed in two instances of
xpdf, running on two adjacent fvwm viewports. A single Win-L/R-arrow
keystroke (Win≡Super_L) switches rapidly between them. If I want to
see the effect of a small change in the source file, I make the
change and run latex to enact it, then I tap "R" in the first xpdf
window which updates it. Now I can flick back and forth between this
window and the other (un-updated) window and see the effect in the
output. (This is analogous to the technique used by astronomers to
find objects that move in the night sky, like Pluto's discovery.)
But for documents of your size (a hundred pages), you might be
interested in reverse workflows too, ie being able to Ctrl-Lclick
on the PDF file and have emacs move to the point in the source
that corresponds to it. I've used this in zathura and it just
requires three lines adding to the zathurarc file:
set dbus-service true
set synctex true
set synctex-editor-command "emacsclient +%{line} %{input}"
#set synctex-editor-command "gvim --servername GVIM --remote +%{line} %{input}"
gvim will start automatically, but with emacs you have to have a
server instance running, by typing emacs and then ESC-x server-start.
I've read that you can set things up to do the opposite, but I've
not tried that.
> Again, things were running properly with Debian 8. Something changed
> when I installed Debian 9. While typing this reply, I just now
> realize that I installed Debian 9 on a different machine (this box),
> so the machine with the Debian 8 installation is still intact. Could
> there be something pathological in this hardware, such as memory going
> bad?
It wouldn't strike me as a hardware error, but I don't understand your
description of the symptoms well enough to make any other suggestions.
DEs are a mystery to me.
Cheers,
David.
Reply to: