[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: forwarded message from Jeff Licquia

Scripsit Frank Mittelbach <frank.mittelbach@latex-project.org>
> Henning Makholm writes:

>  > Imagine that I want to create a typesetting system that behaves just
>  > like LaTeX on all input files, except that input files that say
>  > something like

>  >     \documentclass[12pt]{article}

>  > will actually be typeset with a 13-point font (and similarly for the
>  > other standard classes). Note that I have deliberately selected an
>  > extremely silly task, because I already conceded that I can think of
>  > no non-silly reasons to want to fork LaTeX although I do care for the
>  > theoretical ability to fork nevertheless.

> [example of the complex way removed]

I thought I argued in quite a level of detail why it is the *only* way
that is allowed by the renaming rule. If you think my arguments are
wrong, could you please explain why in more detail than just
dismissing them as "the complex way"?

> Do you know about the suggested way of forking given in cfgguide.tex?


There is a texmf/doc/latex/base/cfgguide.dvi on my local machine. It
contains a document with the title "Configuration options for LaTeX2e"
dated 17 October 1998.

As the last section of that file there is a very brief example of
how the last step of the "complex way" I described in my previous
posting - namely how to get the renamed article.cls loaded while
still allowing the user to define his own .cls files - could be
carried out.

> LaTeX only knows about a very small number of file types that are
> "loadable via interfaces and by rewriting that example to cover the
> three missing ones (only deals with .sty and .cls there) you have a
> simple way to fork which consists of making a new kernel by adding
> 20+ lines of code

It's not simply a matter of rewriting the *example*. There is no
\@cloextension hook to use, at least not in article.cls 1999/09/10
v1.4a - the entire construction of the .clo file's name is hardcoded
in the class file, so I'd still have to change the mechanism there,
which cascades my name-change requirements up as I described in my
previous posting.

That is, unless I do something really gross like


which I still think is beyond the capabilities of the hypothetical
forker who knows what he want to change in size12.clo.

> of course that isn't the only way to fork it is one suggested way not a
> requirement or anything.

If there was a *general* way to do this kind of replacements, and
not one that worked only for .cls and .sty files, I'd be inclined to
be statisfied with that as a forking device.

As you've pointed out, there are other and normally more desirable
ways ways to achive modified behavior in "small" cases, but as long as
the possibility to do an all-out fork is present, the rest is just
extra bonus.

> (which is documented and even referred to in the license)

It seems that I'm referring to a wrong licence. I thought we were
talking about the draft that C.M. Connelly posted in
The character combination "cfgguide" does not appear in his posting.
Do you have an URL reference to the license you're talking about?

> it boils down to a simple change of a few numbers in the right file

Yes, ideally. But as I've explained, the need to then change the name
of that file cascades up the file-invocation chain until one reached
the kernel.

Henning Makholm                       "Man vælger jo selv sine forbilleder."

To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: