[tex-live] Omega and the recent changes in TDS

[Alexej Kryukov]

Dear Karl,

many thanks to you and Thomas for your answers.

On Sunday 21 August 2005 02:09, Karl Berry wrote:
>
> Well, that's a bad situation.
>
> So omega and lambda do not use OTPINPUTS and OCPINPUTS to find
> otp/ocp files?  If not, then why do those variables exist?  I'm
> confused.  (I admit I did not review the sources.)

Well, that was my mistake. Indeed, for OCP files OCPINPUTS is used,
so that they not necessarily should be present in the search path.
BTW, I don't know why the OTPINPUTS variable is needed at all, since
OTP's are just source files, never loaded by any compiler.

Unfortunately, this is not very helpful for me, because Omega seems to
provide no special way to check if a specific translation process really
exists. That's why in antomega I used to apply an \IfFileExists test
before loading any OCP. There are good reasons to do so, because some
translation processes are optional, and, if they are not available on
user's system, this shouldn't cause compilation process to be aborted.

This check was important also because previously antomega depended from 
some standard translation processes supplied with default Omega package,
and, unfortunately, different sets of such files where available in 
different TeX distributions. In the latest release I excluded most such
dependencies, but I still think that removing this test (which requires
the file in question to be present in the search path) would be a
backwards step.

> Right now, there is a tex/lambda/antomega directory, which is (I
> presume) found by lambda.  Is this a problem to use for the location?
> Is antomega tied to lambda, by the way (as opposed to plain omega)?

Antomega requires a latex-based format, and so yes, it is tied with
lambda. Since antomega has its own specific setting which need to
be loaded into format (so that system's default lambda format usually
cannot be used) I considered separating my package into an independent
omega-based format. However, I am unsure if currently there are 
really good reasons to do so (and this would cause additional
problems anyway).

> As for hyphen.cfg, how about giving the file a unique name, like
> antohyphen.cfg?  That would avoid any confusion, either by computers
> or humans.

Well, as I have said, antomega requires a latex based format. I
can't rewrite the whole latex.ltx to make antomega independent from
latex, and this is really not needed. However, loading latex.ltx into
format means that some files related with Babel (and so practically
useless for my purposes) also get loaded. hyphen.cfg is THE place
where I can exclude babel-specific commands and replace them with
my own ones. If I rename the file, how can I manage it to be loaded
into format instead of babel's hyphen.cfg?

> In general, we tried to explain the reason for moving omega/lambda
> input files to the tex/ tree (even though the original tex cannot
> read them) in the tds revision, as below.  I understand that antomega
> is never going to be read by latex, so the first reason doesn't
> apply, but does the location under tex/ hurt?  I don't see why,
> exactly ...

The problem is that omega/lambda is a 2-level engine, like tex/latex.
There is plain omega compiler (with its plain format), and there is a
latex based format for it, called lambda. So previously the omega/
and omega/lambda/ directories tried to mirror the directory structure
of tex/ and tex/latex/, and this was logical. Well, now I can move
lambda-specific stuff to tex/lambda/, but what about files which not
necessarily require a latex-based format, and so may be used by plain
omega as well? This is the case of hyphenation patterns: I probably
have a choice between placing them into tex/lambda/ and tex/generic/,
although both locations are surely wrong.

And that's why I think the new TDS is illogical: it provides engine
specific directories only for latex-based formats, but not for plain
formats they are related with! As a result, some omega-specific
files in teTeX 3.0 are now placed into tex/generic/. For example, 
the whole tex/generic/encodings/ directory is omega-specific, and I
don't understand why it should be in tex search path.

-- 
Regards,
Alexej Kryukov <akrioukov at newmail dot ru>

Moscow State University
Historical Faculty