Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #207585 > unrolled thread

is xdvi broken?

Back to article view | Back to linux.debian.user

Contents

  is xdvi broken? rlharris@oplink.net - 2019-04-16 21:10 +0200
    Re: is xdvi broken? Dan Ritter <dsr@randomstring.org> - 2019-04-16 21:30 +0200
      Re: is xdvi broken? rlharris@oplink.net - 2019-04-16 22:30 +0200
        Re: is xdvi broken? Kushal Kumaran <kushal@locationd.net> - 2019-04-17 02:30 +0200
          Re: is xdvi broken? rlharris@oplink.net - 2019-04-17 05:20 +0200
            Re: is xdvi broken? Kushal Kumaran <kushal@locationd.net> - 2019-04-17 19:40 +0200
              Re: is xdvi broken? rlharris@oplink.net - 2019-04-17 20:30 +0200
                Re: is xdvi broken? rlharris@oplink.net - 2019-04-19 23:20 +0200
                  Re: is xdvi broken? Étienne Mollier <etienne.mollier@mailoo.org> - 2019-04-20 00:40 +0200
                    Re: is xdvi broken? rlharris@oplink.net - 2019-04-20 01:20 +0200
                      Re: is xdvi broken? David Wright <deblis@lionunicorn.co.uk> - 2019-04-20 03:30 +0200
                        Re: is xdvi broken? rlharris@oplink.net - 2019-04-20 05:40 +0200
                          Re: is xdvi broken? Curt <curty@free.fr> - 2019-04-20 10:00 +0200
                            Re: is xdvi broken? Étienne Mollier <etienne.mollier@mailoo.org> - 2019-04-20 11:50 +0200
                          Re: is xdvi broken? David Wright <deblis@lionunicorn.co.uk> - 2019-04-21 02:50 +0200
                            Re: is xdvi broken? rlharris@oplink.net - 2019-04-21 09:40 +0200
                              Re: is xdvi broken? rlharris@oplink.net - 2019-04-21 10:00 +0200
                                Re: is xdvi broken? David Wright <deblis@lionunicorn.co.uk> - 2019-04-22 03:50 +0200
                                  Re: is xdvi broken? rlharris@oplink.net - 2019-04-22 07:20 +0200
                                    Re: is xdvi broken? Bill Wood <william.wood3@comcast.net> - 2019-04-22 09:00 +0200
                                      Re: is xdvi broken? rlharris@oplink.net - 2019-04-22 10:10 +0200
                                        Re: is xdvi broken? <tomas@tuxteam.de> - 2019-04-22 10:40 +0200
                                        Re: is xdvi broken? David Wright <deblis@lionunicorn.co.uk> - 2019-04-22 21:00 +0200
                              Re: is xdvi broken? David Wright <deblis@lionunicorn.co.uk> - 2019-04-22 05:20 +0200
                      Re: is xdvi broken? Curt <curty@free.fr> - 2019-04-20 15:00 +0200

Page 1 of 2  [1] 2  Next page →

#207585 — is xdvi broken?

my desktop system:  amd64, Debian 9, xfce, Emacs 24, TeXLive, xdvi

While using xdvi to view a LaTeX document being written with Emacs, the 
display keeps jumping from the Emacs window to the xdvi window.

The behaviour persists even after the xdvi window is closed; while in 
Emacs I suddenly am looking at the document in the xdvi window.

Several xfce launchers (synaptic and midnight commander) never have 
worked, but others work properly.

Once or twice a week it seems that the desktop is not working quite 
right with the workspace switcher, but I have not been able to discern a 
pattern.  When I restart the computer, things appear to work properly 
again.

Is xdvi broken?  Or can it be that there is a failure in the  
motherboard or the memory of this system?  Or can the hard drive be the 
culprit?  The hardware is more than five years old, but the computer is 
the newest machine I have.

[toc] | [next] | [standalone]

#207592

rlharris@oplink.net wrote: 
> my desktop system:  amd64, Debian 9, xfce, Emacs 24, TeXLive, xdvi
> 
> While using xdvi to view a LaTeX document being written with Emacs, the
> display keeps jumping from the Emacs window to the xdvi window.
> 
> The behaviour persists even after the xdvi window is closed; while in Emacs
> I suddenly am looking at the document in the xdvi window.
> 
> Several xfce launchers (synaptic and midnight commander) never have worked,
> but others work properly.
> 
> Once or twice a week it seems that the desktop is not working quite right
> with the workspace switcher, but I have not been able to discern a pattern.
> When I restart the computer, things appear to work properly again.
> 
> Is xdvi broken?  Or can it be that there is a failure in the  motherboard or
> the memory of this system?  Or can the hard drive be the culprit?  The
> hardware is more than five years old, but the computer is the newest machine
> I have.

I would be looking at the keyboard. Is it possible that you have
some stickiness in your bottom row modifiers? Unintentional
presses and slow releases can cause symptoms like you have
described.

-dsr-

[toc] | [prev] | [next] | [standalone]

#207598

On 2019.04.16 14:20, Dan Ritter wrote:
> I would be looking at the keyboard. Is it possible that you have
> some stickiness in your bottom row modifiers? Unintentional
> presses and slow releases can cause symptoms like you have
> described.

I thank you, kind sir.  I am aware that my expensive and not-very-old 
MX3850USB Cherry keyboard is not well-behaved; I shall return to my old 
$12 keyboard.

However, I still question why the display kept returning to the xdvi 
window after I closed the window and had started no other instance of 
xdvi.  Could the reason be that I started xdvi in the background, using 
& at the end of the command line?

[toc] | [prev] | [next] | [standalone]

#207604

rlharris@oplink.net writes:

> On 2019.04.16 14:20, Dan Ritter wrote:
>> I would be looking at the keyboard. Is it possible that you have
>> some stickiness in your bottom row modifiers? Unintentional
>> presses and slow releases can cause symptoms like you have
>> described.
>
> I thank you, kind sir.  I am aware that my expensive and not-very-old
> MX3850USB Cherry keyboard is not well-behaved; I shall return to my
> old $12 keyboard.
>
> However, I still question why the display kept returning to the xdvi
> window after I closed the window and had started no other instance of
> xdvi.  Could the reason be that I started xdvi in the background,
> using & at the end of the command line?

Do you have some kind of live-preview configuration?  It's been a while
since I did LaTeX, but I remember latex-mode had some configuration that
allows to to continuously run (pdf)latex and keep a previewer running.
I think the latexmk command does something similar.  See if you have an
instance of that running in the background somewhere.

Try with an empty ~/.emacs.d (or start emacs with -Q) and see if the
behaviour persists.  That will eliminate latex-mode configuration as a
potential culprit.

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#207608

On 2019.04.16 19:21, Kushal Kumaran wrote:
> Do you have some kind of live-preview configuration?  It's been a while
> since I did LaTeX, but I remember latex-mode had some configuration 
> that
> allows to to continuously run (pdf)latex and keep a previewer running.
> I think the latexmk command does something similar.  See if you have an
> instance of that running in the background somewhere.

Yes; I was running latexmk.  With the -pvc option the situation was 
intolerable:

latexmk -pvc -dvi -pdf mydocument.tex

That is why I closed the xdvi window, but quickly discovered that the 
process which calls xdvi still was running.  Restarting the computer 
solved the problem.  I did not try simply restarting xfce.

A month ago I was using latexmk with the same options on this machine.  
I seem to recall an occasional jump back to the xdvi window, but not the 
constant jumping back I was seeing today.  So I think that the new 
Cherry keyboard must be the culprit.

[toc] | [prev] | [next] | [standalone]

#207653

rlharris@oplink.net writes:

> <snip>
>
> A month ago I was using latexmk with the same options on this machine.
> I seem to recall an occasional jump back to the xdvi window, but not
> the constant jumping back I was seeing today.  So I think that the new
> Cherry keyboard must be the culprit.

You may be able to configure your window manager to disallow certain
kinds of windows from stealing focus.  KDE/Plasma has something called
"Window Rules" that seems to fit the bill, but that I've never had
occasion to try myself.

Alternatively, if you have a large enough display, you can tile your
windows so that emacs and xdvi are both visible at the same time.  Not
sure whether xdvi will steal focus away from emacs in that case.

Won't help if your keyboard is actually sending unexpected input, of
course.

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#207655

On 2019.04.17 12:38, Kushal Kumaran wrote:
> You may be able to configure your window manager to disallow certain
> kinds of windows from stealing focus.

I had forgotten about the concept of focus; I thank you for reminding 
me, and for pointing me to the window manager.  So many things in Debian 
"just work" without attention that it is easy to lose familiarity with 
the mechanisms involved.

[toc] | [prev] | [next] | [standalone]

#207699

On 2019.04.17 13:20, rlharris@oplink.net wrote:
> I had forgotten about the concept of focus; I thank you for reminding
> me, and for pointing me to the window manager.

After replacing the keyboard, it still appears that either xdvi is 
broken, or that there is a strange interaction between xdvi and xfce, or 
that it is xfce which is broken.

Typical symptoms include:

= Upon executing "latex <filename.tex>" xdvi does not display the 
revised text until a cursor key is pressed.

= Sometimes the xdvi display shows a double image or a portion of one 
page written over an existing page.  At that point, I have found no 
method of recovery other than to restart the computer.

= If Firefox is running, a second instance of Firefox is opened in a new 
window, and the new window is moved to a different workspace in which 
Emacs and xdvi are running, Emacs and xdvi both disappear.

I now am wondering if the ultimate culprit is xorg, and that the 
ultimate answer is wayland.

I am perplexed.  Perhaps I should install Debian 8 on an older 
(non-uefi-bios) machine; I need a stable work environment.

[toc] | [prev] | [next] | [standalone]

#207700

Good Day,

Lurking at this thread, I discovered xdvi was installed on my
machine, probably pulled by some texlive dependencies.  I even
discovered a few old .dvi of mine, so give it a go out of
curiosity.  It has this look and feel typical from monochrome X
graphical interfaces released in the 80's.  Tasty !  :)

I havent had the occasion to have much issues with it, but I
didn't push testing up to run emacs, and produce documentation.

rlharris, on 2019-04-19 :
> After replacing the keyboard, it still appears that either
> xdvi is broken, or that there is a strange interaction between
> xdvi and xfce, or that it is xfce which is broken.

Perhaps you can check this by running your programs under
another desktop environment.  LXDE may, or may not, be to your
taste.  It is as light in weight as Xfce.  You can install the
package task-lxde-desktop to give it a go.

> Typical symptoms include:
>
> = Upon executing "latex <filename.tex>" xdvi does not display
> the revised text until a cursor key is pressed.
>
> = Sometimes the xdvi display shows a double image or a portion
> of one page written over an existing page.  At that point, I
> have found no method of recovery other than to restart the
> computer.

The program may become heavy on CPU due to necessary redraws
each time a window covers it.  Are you running your Xfce desktop
with or without the compositor ?  You should see this somewhere
around:

	System settings
	`-> Window manager tweaks
	    `-> Compositor (tab)
	        `-> Enable display compositing (checkbox)

I have no idea what changes this parameter will do to the
behaviour of discrepancies you observed, but I bet there will be
a change in the general feeling of the program.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>

[toc] | [prev] | [next] | [standalone]

#207701

On 2019.04.19 17:33, Étienne Mollier wrote:
...
> It has this look and feel typical from monochrome X
> graphical interfaces released in the 80's.  Tasty !  :)

At least for diagnosing this problem, I would be interested in an 
alternative to xdvi.



> another desktop environment.  LXDE may, or may not, be to your
> taste.  It is as light in weight as Xfce.

I think my machine is sufficiently fast that "lightweight" is not a 
concern.  I simply cannot find my way around the gnome desktop -- I wish 
to see launchers for everything all the time, and not just when I run 
the cursor over the correct portion of the screen.  The gnome approach 
must appeal to the video gamer; but I use the computer for serious work. 
  With Debian releases 7 and 8, I have been running xfce.



> The program may become heavy on CPU due to necessary redraws
> each time a window covers it.

In the workspace I have Emacs, two instances of xdvi, xfce-4-terminal, 
and xfce-dictionary.  I am working on a ten-page text-only document with 
LaTeX markup.  I did not experience this problem with Debian 8.



> 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.

[toc] | [prev] | [next] | [standalone]

#207702

On Fri 19 Apr 2019 at 18:10:14 (-0500), rlharris@oplink.net wrote:
> On 2019.04.19 17:33, Étienne Mollier wrote:
> ...
> > It has this look and feel typical from monochrome X
> > graphical interfaces released in the 80's.  Tasty !  :)
> 
> At least for diagnosing this problem, I would be interested in an
> alternative to xdvi.

There are many. I see a2ps, advi, apsfilter, atril, dvi2ps, evince and
okular. Not all these are viewers: eg, dvips converts to a PostScript
file for other viewers to use, and I think evince runs a converter
itself automatically.

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.

> > another desktop environment.  LXDE may, or may not, be to your
> > taste.  It is as light in weight as Xfce.
> 
> I think my machine is sufficiently fast that "lightweight" is not a
> concern.  I simply cannot find my way around the gnome desktop -- I
> wish to see launchers for everything all the time, and not just when I
> run the cursor over the correct portion of the screen.  The gnome
> approach must appeal to the video gamer; but I use the computer for
> serious work.  With Debian releases 7 and 8, I have been running xfce.

I can't help you there, as a DE non-user.

> > The program may become heavy on CPU due to necessary redraws
> > each time a window covers it.
> 
> In the workspace I have Emacs, two instances of xdvi, xfce-4-terminal,
> and xfce-dictionary.  I am working on a ten-page text-only document
> with LaTeX markup.  I did not experience this problem with Debian 8.

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?

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.

> > 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.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#207703

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 document files after searching without success for a 
means of exporting a document such that character-level attributes such 
as italic and boldface were preserved.  The cost of editing and 
proofreading to manually restore character-level attributes made 
recovery impractical.

My workflow back then was (1) composition on a DOS machine, (2) floppy 
transfer via sneakernet to a Windows machine, (3) typesetting in Aldus 
Pagemaker, (4) hardcopy with a dot-matrix printer, (5) proofreading, (6) 
revision on the DOS machine.

I began with Debian Potato.  That necessitated transporting the computer 
system to a beginning-of-semester Installfest at a local university.  
There a kindly soul showed me the rudiments of running Emacs and LaTeX, 
together with magic of using xdvi to view the typeset document as 
composition progressed, without the necessity of hardcopy.

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.

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.

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.



> 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.

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?

[toc] | [prev] | [next] | [standalone]

#207707

On 2019-04-20, rlharris@oplink.net <rlharris@oplink.net> wrote:
>
>> 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.

There's an old bug about xdvi autofresh not working with the XFCE
"compositing manager."

https://sourceforge.net/p/xdvi/bugs/354/

According to the xdvi man page, the default is not to refresh ('-watchfile n'
must be set to a value larger than 0, zero being the default).

You probably know this already (as you had it all working before
upgrading to number 9).

> 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?
>

[toc] | [prev] | [next] | [standalone]

#207710

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>

[toc] | [prev] | [next] | [standalone]

#207724

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.

[toc] | [prev] | [next] | [standalone]

#207726

On 2019.04.20 19:42, David Wright wrote:
> Then it might be worth revisiting your deliverables and seeing whether
> a DVI workflow is still worth using after two decades.
...
> 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 ...

I once used hyperlatex to maintain a web site with documents in both 
HTML and PDF.  Execution of a single makefile regenerated the entire 
website from the LaTeX source documents; that took about ten minutes.  
But then HTML5 came along, and hyperlatex was not renovated to generate 
HTML5.

Since that time I have used tex4ht and at least one other Debian package 
for direct conversion of a LaTeX document to HTML.  But I recently 
discovered an advanced debian package "latex2html" which came out about 
a year ago and is designed to build an entire web site directly from 
LaTeX document files.

> So you expect that visitors can print from PDFs but you print locally
> with PS. Any reason?

Mine is a one-horse outfit.  I cannot afford to publish by printing and 
mailing material.  But I can afford to publish by posting documents in 
HTML and PDF on a web site.  HTML accommodates the visually-impaired.  
On occasion, however, there is need print and mail out a document to 
someone.  And I like to keep a paper copy for myself; I do not enjoy 
reading a long document displayed on a computer screen.  Whenever I 
read, I keep close at hand a red pen and a yellow high-lighter.

>> I constantly switch between the emacs screen and the xdvi screen as
>> I compose.
> How do you "switch" between them?

Alt-TAB, multiple times if necessary.  I switch back and forth between 
four or five windows: Emacs, dictionary, xdvi, terminal, and sometimes a 
reference document on a web page.  Running latexmk, I hardly ever needed 
to switch to the terminal window.

To print a copy for proofreading, I execute dvips, then lpr.


> 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.)

Understood; I agree.  I should not have said WYSIWYG.  I am very 
comfortable with the LaTeX markup on the Emacs screen, so I do not look 
at the xdvi screen all that often.  But viewing the typeset document 
does display the table of contents; also, it facilitates decisions on 
structure (such as bulleted list vs. enumerated list, and list vs. 
subsections), and it helps me produce a document which is attractive and 
reader-friendly.



> 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.

I agree; so just before switching to the viewer, I save the document 
(Ctr-x s) in Emacs and then switch; but if I wish to look again at the 
old version, I switch without saving.

[toc] | [prev] | [next] | [standalone]

#207727

On 2019.04.21 02:31, rlharris@oplink.net wrote:
> On 2019.04.20 19:42, David Wright wrote:
>> So you expect that visitors can print from PDFs but you print locally
>> with PS. Any reason?

Kindly forgive my deficiency in the field of reading comprehension.  I 
finally understand your question.

I expect visitors to print from PDF.  I think few of them would know 
what to do with a DVI file, and I think few have a Postscript printer.

However, my laser printers always have been Postscript, and someone long 
ago introduced me to the "dvips" utility.

Inasmuch as I print many things, and I need PDF documents only for 
publication, I normally execute dvips and lpr, unless the document needs 
to be PDF.

That seems to me more simple and more direct than routinely to produce 
PDF and then routinely to convert PDF to Postscript for printing.  Am I 
misunderstanding something?

[toc] | [prev] | [next] | [standalone]

#207754

On Sun 21 Apr 2019 at 02:54:05 (-0500), rlharris@oplink.net wrote:
> On 2019.04.21 02:31, rlharris@oplink.net wrote:
> > On 2019.04.20 19:42, David Wright wrote:
> > > So you expect that visitors can print from PDFs but you print locally
> > > with PS. Any reason?
> 
> Kindly forgive my deficiency in the field of reading comprehension.  I
> finally understand your question.
> 
> I expect visitors to print from PDF.  I think few of them would know
> what to do with a DVI file, and I think few have a Postscript printer.

Agreed, and my apologies if the sentence above made it seem that
it was an unreasonable expectation.

> However, my laser printers always have been Postscript, and someone
> long ago introduced me to the "dvips" utility.
> 
> Inasmuch as I print many things, and I need PDF documents only for
> publication, I normally execute dvips and lpr, unless the document
> needs to be PDF.
> 
> That seems to me more simple and more direct than routinely to produce
> PDF and then routinely to convert PDF to Postscript for printing.  Am
> I misunderstanding something?

I don't think so. In general, most people will be receiving a good
proportion of documents as PDF files, and so will have their printing
system (like CUPS) set up to handle them. Since there are now LaTeX
systems like pdflatex and lualatex that produce PDF documents
directly, they have likely moved on to these systems rather than the
previously conventional .tex→DVI→PS→PDF workflow.

Do you convert PDF documents from elsewhere to PS yourself, before you
print them? For most people, this kind of function is handled
automatically by CUPS, and it will convert many other types of file as
well. So my workflow is .tex→PDF→CUPS when I bother to print it myself.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#207759

On 2019.04.22 01:43, David Wright wrote:

> ... most people will be receiving a good proportion of documents as
> PDF files, and so will have their printing system (like CUPS) set up
> to handle them ... rather than the previously conventional
> .tex→DVI→PS→PDF workflow.

On the average, I print only one PDF document a day.

I remember the struggles of getting printing running back in the old 
days, the joy when LPRng was introduced, and my initial reluctance to 
abandon a proven system (LPRng) for unknown waters when, later on, CUPS 
was introduced.  But I did make the switch to CUPS.



> Do you convert PDF documents from elsewhere to PS yourself, before you
> print them? For most people, this kind of function is handled
> automatically by CUPS, and it will convert many other types of file as
> well. So my workflow is .tex→PDF→CUPS when I bother to print it myself.

No, the only time I explicitly convert a document to PS is when I am 
composing in LaTeX and execute dvips to get hardcopy to proofread.

I print some PDF documents after downloading from web pages; these 
generally are things such as an instruction manual, or an invoice 
received as an e-mail attachment.

I open such documents with whatever PDF viewer happens to be available 
in the APPLICATIONS MENU of the desktop; under Debian 7 or 8 I think the 
viewer was Evince.  If I need a paper copy, I select PRINT from the menu 
of the PDF viewer, and the viewer hands off the document to CUPS.

-------

If I understand correctly, you are suggesting that I run latexmk with 
the option to create a PDF, so that, when I wish to print a copy of the 
document-in-progress to proofread, the procedure is:

     = In Emacs, save the document
     = Switch to a virtual terminal
     = Execute "lpr mydocument.pdf"
     = Switch back to Emacs
     = Continue work on the document

That saves three steps over my current procedure:

     = In Emacs, save the document
     = Switch to a virtual terminal
     = Execute "latex mydocument.tex"
     = Execute "latex mydocument.tex"
     = Execute "dvips mydocument.dvi"
     = Execute "lpr mydocument.ps"
     = Switch back to Emacs
     = Continue work on the document

[toc] | [prev] | [next] | [standalone]

#207760

On Mon, 2019-04-22 at 05:17 +0000, rlharris@oplink.net wrote:
   . . .
> That saves three steps over my current procedure:
> 
>      = In Emacs, save the document
>      = Switch to a virtual terminal
>      = Execute "latex mydocument.tex"
>      = Execute "latex mydocument.tex"
>      = Execute "dvips mydocument.dvi"
>      = Execute "lpr mydocument.ps"
>      = Switch back to Emacs
>      = Continue work on the document
> 
Is there a reason not to use pdflatex?  My workflow then is

= In emacs, save the doc foo.tex
= switch to a virtual terminal
= execute "pdflatex foo.tex" (as many times as needed)
= execute "evince foo.pdf"
= when desired, select "Print" from the "File options" menu of evince
= switch back to emacs

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web