Can doc/ contain documentation independently of source/
joseph.wright at morningstar2.co.uk
Tue Feb 4 10:16:26 CET 2020
On 03/02/2020 23:29, Karl Berry wrote:
> As far as I'm concerned, the difference between doc/ and source/ is
> essentially meaningless. The vast number of files in the gray area
> between might be assigned to either one. (I long ago suggested simply
> merging source/ into doc/ and getting rid of source/, but other people
> did not like that idea. So fine.)
For l3build, the logic we've gone for is
- source/ is for material which contains lines that go into tex/, etc.
- doc/ is for PDFs and material that is used to produce them, but where
no lines go directly into tex/ (plus .txt files, etc.)
An alternative logic would be
- doc/ is purely PDFs and text files
- source/ is all the sources
Perhaps the latter is actually clearer, as it means that the doc/
subtree is 'things to read' only ...
> As for recreating in general: it's supposed to be possible, with the
> exception that if the original doc uses some weird (e.g., system) font
> purely for aesthetic purposes, it's ok to require changing the source to
> use a free font. Not that it's anything I ever recommend or suggest or
> like, but that decision was made long ago.
> Since we don't, in fact, try to recreate pdfs (or whatever) from
> sources, I have no doubt that the sources are insufficient in some
> cases. All I can suggest is contacting the package author. There is no
> requirement that it be easy to remake.
> The primary purpose of requiring sources is not about recreating the
> pdfs as distributing, but for the general reason for free software in
> the first place: so that if someone enhances the package, they can also
> update the documentation. In principle.
Indeed. The build scripts or whatever are nice but not essential: one
can find a way to build a .dtx or whatever to a PDF. But without the
source files you can't do that even by hand.
More information about the tex-live