[tex-live] texdoc in luatex

[Florent Rougon]

Hi,

Reinhard Kotucha <reinhard.kotucha at web.de> wrote:

> Frank,
> if Debian needs all PDF files comressed, which tools does Debian
> provide to deal with them?

  1) Debian doesn't provide 'brain', but it has been a standard component
     required on the user side for a lot of years...

  2) see(1)

  3) zxpdf(1)

> And why do you take care about Windows?

I'm not Frank, but I suppose the reason is that he's a nice guy and
takes pity on those poor lost souls (well, to be accurate, sometimes
they are not lost but simply forced by someone higher in the hierarchy
:).

> In TeXLive we cannot have compressed PDF files because this would
> break a lot of things.  There are HTML files with links to PDF files

I think a good combination of web server/web browser should deal with
with gz/bzip2/etc. being an encoding in the HTTP protocol. However, I'm
not sure what to do when browsing local files, i.e. when no HTTP server
can provide the proper encoding metadata. But I'm not an expert in this
area, so I may be missing some way out of the problem.

> and there are links in PDF files to other PDF files.  The doc trees

Unless the PDF specification has forseen the use of compressed files,
this is indeed a real problem. :-/

> should be browsable because not everyone is familiar with commandline
> tools and texdoctk is incomplete and does not support documentation
> written in any other language than English.

FWIW, I'm pondering these days about rewriting texdoctk in Python (and
probably Qt for the GUI toolkit) to deal with the major problems we've
seen in the last years, mainly that:

  - distributors such as Debian want each package to be able to provide
    its own peace of metadata describing the documentation provided by
    the package. This avoids the need of a permanent superman
    maintaining a central database that records all documents in the TeX
    world.

    This would allow separate Debian packages to record their
    documentation in the texdoctk database without any work from the
    Debian TeX maintainers.

    IMHO, this metadata should be part of the LaTeX package on CTAN and
    could be used by the TeX Catalogue to automatically point to the
    various documentation files, the master file (index) if any, deal
    with the various languages, etc.

  - some packages such as hyperref have a documentation that is split
    into several files, and this is a very well known problem for
    texdoc. As said previously, I'd like LaTeX packages to ship metadata
    listing all the documentation files, their languages and tell which
    one is the index, if any (for a given language).

If people are interested, this may motivate me to allocate the needed
time in these holidays.

> Compressed files will cause a lot of problems and people can't use
> programs of their choice to browse documentation.

The main problem I see (as a Debian guy who can polish the simple tools
such as see(1)) is links from PDF files to other PDF files. But I'm
wondering whether these links are really useful because I don't know how
they deal with paths. For instance, suppose that

  texmf/doc/some/document1.pdf

points to:

  texmf/doc/other/document2.pdf

I suppose the link in document1.pdf can be "../other/document2.pdf", but
I'm not sure this would work on Windows. But even this is not robust
enough for Debian. The reason is, in Debian, the TEXMF tree for TL stuff
is

  /usr/share/texmf-texlive

(for teTeX, it was /usr/share/texmf-tetex and both could be combined at
the same time until teTeX got removed from the archive)

but packages that are packaged separately for Debian (which allows us to
update them more frequently than they are in TL), such as lmodern, are
installed into another TEXMF tree (/usr/share/texmf).

Therefore, a link such as ../other/document2.pdf would break as soon as
document1.pdf and document2.pdf are located in different TEXMF trees.

As a consequence, I suppose these links are mostly useful for files that
are supposed to be installed in the same directory, such as, I presume,
the various files comprising the hyperref documentation. But even in
this case, unless the PDF specification allows us to point to a .pdf.gz
*and* $pdf_viewer_in_use is able to cope with that *and* we either don't
change upstream choices (to ship as .pdf or .pdf.gz or .pdf.bz2) or
rebuild the docs for Debian (to ship .pdf.bz2 *and* update the
corresponding internal links in the docs, which would be a PITA), we're
screwed.

That makes a lot of "if's", so I'd tend to say that we're basically
screwed unless we (TL or Debian) give up on either compressed PDF files
or on links from PDF files to other PDF files.

Sorry for the length...

-- 
Florent