Re: Encoding the name in the file contents
Brian Sniffen writes:
> >>>>> On Fri, 26 Jul 2002 20:59:23 +0200, Frank Mittelbach <firstname.lastname@example.org> said:
> > The point is that by distributing it under LPPL it will be the same
> > everywhere (or not on the installation). That work of yours might
> > change/overwrite any part of other code in the ULL. That's fine
> > because that doesn't change the fundamental property of the ULL
> > (identical behaviour as long as you start with a LaTeX kernel at big
> > bang).
> How does that work when an author releases a new version of a package?
> Surely then (since as has been said before any change will change
> output) the output changes.
I should of course have said, "potentially changes the output" since a change
in documentation will change nothing in the output and adding a new feature
might not change many documents (if any). But in most cases a change affects
documents using that work in one way or the other (and usually in subtle ways,
and not necessarily in glaring bugs that stop the processing --- which is
worse as such changes are caught often too late).
But i don't want to chicken out here. changes affects documents so when some
author releases a new version of his/her package that potentially results in
incompatibilities with existing documents (and less often in bugs that need
Now how does that work in the TeX world?
Not perfectly but more or less it does. First of all, true compatibility
backward and forward can only be achived by no change at all, even adding only
features would potentially break existing documents and since there is no
clearly defined boundary between internal and external interfaces and code in
a macro language any code change might trip another package that overwrites
part of the code of one package but uses other parts of it (it is like a CVS
merge from overlapping modifications, only that the conflict isn't noticeable
directly in all cases).
So what happens?
First of all TeX as such together with its "plain" format and its Computer
Modern fonts is an absolute fix point, ie documents running only on top of
this will behave identically and now and in the future. (this is partly due to
the lucky situation that TeX is virtually bug free by now, otherwise even that
statement wouldn't be correct).
For TeX variants that situation is less stable, ie they evolve, so if you use
LaTeX on top of pdftex then already pdftex might change over time, but at a
given point in time you have cross-installation identity.
Now for LaTeX ...
Because for reasons of stability the kernel itself doesn't change much if at
all (these days). As a policy, for example, we don't change article.cls to
improve its layout (even though its layout leaves much room for improvment:-)
Simply because there are several hundred thousands (if not millions) of
documents out there that are based on article.cls either directly or
indirectly by using another class that loads article and modifies it.
So we promote that people provide better classes but keep this as a good
basis to build upon.
We also promote kernel changes being done in this way, ie distributed as
packages. This way improvements, new code different layouts can be applied
for current documents (if desired) but will not affect older documents that
worked around that problem or layout misfeature, or whatever in some way
already and would probably choke on the changed kernel code.
There are a number of packages out these days that extend the kernel with
important features, like hyper-reference support, a better two-column mode,
you name it. If any of such packages would have been added to the kernel it
would break a lot of existing documents but this way it doesn't break
The very major packages often apply a similar attitude, though perhaps less
rigerously, eg the big rewrite of the AMS math support was done my keeping
amstex.sty and providing amsmath.sty instead. Why was it done this way? by
cause AMS has its own commitment to a huge archive of documents and to its
users (the math community)
However, amsmath has undergone revision and bug fixes and probably has
tripped one or the other document this way. But even so, the important point
in all that is that at any given point in time, documents could be exchanged
between authors and other authors as well as between the authors and the
publishers, because the it was part of ULL so everybody with a recent LaTeX
installation had the same amsmath.
Now if you get to the outskirts of the ULL, eg smaller packages, more
specialized packages, as well as "new" packages, then you often find more
drastical changes --- most people welcome this as a means of stablising stuff
and getting better quality, even though it means that documents using such
packages may need minor corrections if you rerun them after a while using new
For example, the geometry package, just went from version 2x to 3y (with the
bug fix number after 3 rapidly changing :-). It actually turned its interface
upside down, though Hideo tried to be as compatible as possible (basically
because his 2x version already had a good number of users). What he did was
to provide one option to version 3 that would make it start with the 2x
defaults. So yes, if you used that package in the past your documents would
now change and to get the old behaviour back you have to add the
compatibility option into your old documents. But the point again is --- the
exchangibility is not affected.
Other package writer work differently, sometimes they fork, sometimes they
just hope that they are doing such a tiny change that clearly nothing could
ever break (and usually they find out that they are wrong :-)
So to summarizes: the more packages (ie independed works within the ULL or
outside ULL but in LL) you use the bigger the chances that your document is
not going to work without some helping and fixing at some point in the future.
So the claim that Boris (or somebody else) made that LPPL is ensuring absolute
backward compatibility is not true. It does help a good deal, by ensuring that
a package if not forked to a different name has a single updating path but
that that in alone is no guarantee. As closer as you get to the required part
of the ULL the better the chances are that you have compatibility over a long
time and in practice it works out well enough.
The main goal of LPPL is to make the ULL a cross platform identity (if you
chose to work with a latex kernel as a starting point!) at a given point in
time (and normally over a longer time range in fact). It helps on the with the
backward compatibilty but that's not its primary purpose.
I recently tried to rerun "The LaTeX Companion" which is using 170 packages
or so (not written by me) and it took me about a day to get that beast
producing more or less decent output again and that as you can imagine is a
rather uncommon testing case.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org