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

Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)

Henning Makholm writes:

 > > As I said earlier, I guess we could be persuaded  to provide two
 > > kernels within LaTeX distribution, one as it is now, and one with
 > > the remapping feature already available. If that kernel would be
 > > used then you would perhaps get
 > I'm not keen about a solution which needs two kernels because the
 > regular kernel was considered "not free enough". It would mean the
 > Debian would end up distributing the non-regular kernel in its main
 > section; not a desirable outcome for any of us. 

Just to make one point clear here:

  It wasn't my intention at all to provide two kernel because I thought that
  one of them was not free enough. That interpretation would indeed lead to an
  desirable outcome.

I consider already the normal kernel complient as it allows you to produce
such a second kernel. You can consider such kernels as implementing command
line options if you like (as that is something TeX/LaTeX is doing somewhat

Anyway I agree with you that several kernel's are not necessary.

 > However, what about:
 > A. Distribution terms that say that
 >      "You can redistribute files if one of the following hold:
 >         1) The contents of the file is completely unchanged.
 >         2) Certain file name restrictions are observed .. yadda yadda
 >            yadda.
 >            Also, you must change any human-readable identification
 >            strings in the file to note that you have changed it.
 >            [This is by far the recommended option if you want to
 >            change the behavior of The Program. See xxguide.tex for an
 >            explanation of why we think so.]
 >         3) You make sure that when TeX reads the file, the VERY FIRST
 >            token it finds is "\NotACanonicalSourceFile".
 >            Also, you must change any human-readable identification
 >            strings in the file to note that you have changed it.
 >            [This option is provided because in certain extremely
 >            unlikely situations somebody MAY need it. Please think
 >            at least twice before deciding you're that somebody.]"
 >    Here option (2), while its DFSG-freedom is debatable, will still
 >    be used by the vast majority of sane people who want to change
 >    something. Option (3) is there to make DFSG-freedom undeniable.
 > B. Only one kernel. This kernel will, however, be extended to define
 >    \NotACanonicalSourceFile as a macro that
 >       i) Screams bloody murder on stdout and the log file.
 >          (unless this has already been done once).
 >       ii) Arranges for a similar warning to be emitted at the
 >           \end{document}.
 >       iii) Except for that, _continues processing_ the document.
 > When one combines A(3) and B(iii), it shows that inserting
 > \NotACanonicalSourceFile is only a way to flag the source file as
 > having been changed, in a way that will be obvious to a human user.
 > It is important that the presence of \NotACanonicalSourceFile _does
 > not change the .dvi output_; this means that A(3) does not ask for a
 > _functional_ change as a prerequisite for same-filename changes.
 > I have reason to hope that such a scheme would satisfy all of the
 > interests and principles stated in the discussion so far. 

that seems to be the case as far as I can see. I would however use
\NeedsTeXFormat in place of \NotACanonicalSourceFile as that would be more
flexible and is already available.

 > The only thing that's not completely covered are the integrated
 > environments that Frank speaks about where users do not see any of
 > TeX's output to the terminal at all. Could that be solved by
 > masquerading the warning messages as regular TeX errors/warnings
 > (surely users of such environments get told about overfull/underfull
 > boxes, or what)?

there are probably ways to mend that problem as well


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

Reply to: