GNU bug report logs - #79052
epsf.tex: New file

Previous Next

To reply to this bug, email your comments to 79052 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Josefsson <simon <at> josefsson.org>
To: Bruno Haible via Gnulib discussion list <bug-gnulib <at> gnu.org>
Cc: bug-automake <at> gnu.org, Bruno Haible <bruno <at> clisp.org>,
 Karl Berry <karl <at> freefriends.org>
Subject: Re: epsf.tex: New file
Date: Sat, 19 Jul 2025 21:28:03 +0200

[Message part 1 (text/plain, inline)]

Bruno Haible via Gnulib discussion list <bug-gnulib <at> gnu.org> writes:

> Having said that, I would be in favour of retiring the DVI format from
> the GNU Coding Standards. The DVI format was commonplace in the 1990ies,
> but lost popularity to the PDF format starting 2008 (when PDF became an
> open standard). Nowadays, even the math arXiv does not offer DVI as a
> download format any more [1]. But this needs to be done through the
> proper channels: first the GNU standards, then GNU Autoconf and Automake.

Right.  I would say that the days of the DVI and PS formats are probably
long gone, and definitely as a default format.  PDF has won.

I tried to find any strong recommendation about DVI in the "standards"
and "maintain" manuals, but couldn't find anything.  There are some
references to DVI that may better be to PDF but as far as I could tell,
everything about documentation formats beyond *.info files are optional:

https://www.gnu.org/prep/standards/standards.html
https://www.gnu.org/prep/maintain/maintain.html

So is this about changing automake/autoconf then?

I suppose one change is to make autoconf/automake try to build the PDF
manual at 'distcheck' instead of DVI, but I think that is a more
difficult change: 1) it requires additional tools not otherwise
mentioned in the documents or are normally installed on people's
machines, and 2) the above manuals say special things about 'texi2dvi'
but nothing about the same tools for PDF.  Do we really want to add new
requirements for PDF that haven't been part of these documents, at this
point in time?

Maybe it is sufficient for 'make distcheck' to attempt to build the Info
manual, which I think is already the case?  And then simply drop the
attempt to build *.dvi by default like the attached (untested) patch?

What kind of problems would attempting to build the DVI or PDF manual
really catch these days, which aren't already triggered by attempting to
make the *.info manual?

What is there in autoconf to change?  I couldn't find anything obvious
related to DVI.

/Simon

diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index e21c5a7cc..04113bf25 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -439,7 +439,8 @@ AM_RECURSIVE_TARGETS += distcheck
 endif %?SUBDIRS%
 
 # Exists only to be overridden by the user if desired.
-AM_DISTCHECK_DVI_TARGET = dvi
+# Used to be 'dvi'.
+AM_DISTCHECK_DVI_TARGET =
 
 # This target untars the dist file and tries a VPATH configuration.  Then
 # it guarantees that the distribution is self-contained by making another

[signature.asc (application/pgp-signature, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org, Simon Josefsson <simon <at> josefsson.org>
Cc: bug-automake <at> gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: epsf.tex: New file
Date: Sat, 19 Jul 2025 21:48:29 +0200

Simon Josefsson wrote:
> Right.  I would say that the days of the DVI and PS formats are probably
> long gone, and definitely as a default format.  PDF has won.

DVI yes. PS has its use
  1. as alternate format, at least in arXiv.org,
  2. as easy-to-create vector graphics format.

> I tried to find any strong recommendation about DVI in the "standards"
> and "maintain" manuals, but couldn't find anything.

The Standards reference
  - Makefile targets 'dvi' and 'install-dvi',
  - a variable 'dvidir',
  - a configure option --dvidir.
All of these would have to be removed.

> So is this about changing automake/autoconf then?

I wouldn't suggest to change Automake or Autoconf before the Standards
have been changed.

Bruno

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: simon <at> josefsson.org
Cc: bruno <at> clisp.org, bug-automake <at> gnu.org, bug-gnulib <at> gnu.org
Subject: Re: epsf.tex: New file
Date: Sat, 19 Jul 2025 15:15:57 -0600

    What kind of problems would attempting to build the DVI or PDF manual
    really catch these days, which aren't already triggered by attempting to
    make the *.info manual?

Building dvi/pdf definitely has a chance of catching errors,
since it's a complete different Texinfo implementation (texinfo.tex
vs. makeinfo). Also there's the question of ensuring that images are
included in the distribution, which is what brought up this whole
question.

However, I don't think these rather minor benefits outweigh the pain for
maintainers of building dvi (or pdf) by default, so changing automake to
not build dvi as part of distcheck seems good to me.

For GNU packages, dvi and pdf will normally be tested anyway as part of
a release, due to the need to upload the new manuals to www.gnu.org.
Perhaps we should remove dvi from there ... -k

Message #18 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Josefsson <simon <at> josefsson.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: bruno <at> clisp.org, bug-automake <at> gnu.org, bug-gnulib <at> gnu.org
Subject: Re: epsf.tex: New file
Date: Sat, 19 Jul 2025 23:45:21 +0200

[Message part 1 (text/plain, inline)]

Karl Berry <karl <at> freefriends.org> writes:

> For GNU packages, dvi and pdf will normally be tested anyway as part of
> a release, due to the need to upload the new manuals to www.gnu.org.
> Perhaps we should remove dvi from there ... -k

Yes, as a start, could we drop linking to DVI manuals from gnulib's
gendocs_template*?  That ought to (gradually) at least remove them from
users eyes.  The next step may be to stop generating the files, but that
is a bigger change and maybe the discussion needs to come to a still
before doing that is the right thing.

/Simon

[gnulib-gendocs.patch (text/x-diff, inline)]

diff --git a/doc/gendocs_template b/doc/gendocs_template
index 9069a54787..f342613739 100644
--- a/doc/gendocs_template
+++ b/doc/gendocs_template
@@ -58,8 +58,6 @@ without any warranty.
     (%%ASCII_SIZE%%K bytes)</a>.</li>
 <li><a href="%%PACKAGE%%.txt.gz">ASCII text compressed
     (%%ASCII_GZ_SIZE%%K bytes gzipped)</a>.</li>
-<li><a href="%%PACKAGE%%.dvi.gz">TeX dvi file
-    (%%DVI_GZ_SIZE%%K bytes gzipped)</a>.</li>
 <li><a href="%%PACKAGE%%.pdf">PDF file
     (%%PDF_SIZE%%K bytes)</a>.</li>
 <li><a href="%%PACKAGE%%.texi.tar.gz">Texinfo source
diff --git a/doc/gendocs_template_min b/doc/gendocs_template_min
index d4968a249a..fb58adffae 100644
--- a/doc/gendocs_template_min
+++ b/doc/gendocs_template_min
@@ -69,8 +69,6 @@ without any warranty.
     (%%ASCII_SIZE%%K bytes)</a>.</li>
 <li><a href="%%PACKAGE%%.txt.gz">ASCII text compressed
     (%%ASCII_GZ_SIZE%%K bytes gzipped)</a>.</li>
-<li><a href="%%PACKAGE%%.dvi.gz">TeX dvi file
-    (%%DVI_GZ_SIZE%%K bytes gzipped)</a>.</li>
 <li><a href="%%PACKAGE%%.pdf">PDF file
     (%%PDF_SIZE%%K bytes)</a>.</li>
 <li><a href="%%PACKAGE%%.texi.tar.gz">Texinfo source

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.