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

[Alexej Kryukov]

On Monday 29 August 2005 05:04, you wrote:
> Back on this thread from a week ago (sorry).  I'm afraid I am quite
> lost.

Thank you for returning to this thread! I've also delayed my answer,
but that's because some time was required to study things
carefully.

> In the original mail, I see Alexej proposing that
> tex/generic/encodings should be moved since it is Omega-specific.  I
> guess
> tex/omega/encodings?  tex/omega/generic/encodings?
> tex/omega/plain/encodings?  I don't know enough to say what's best.

Well, previous location for this directory was omega/encodings,
which means it was considered compiler-specific rather than
format-specific. So it should go to whichever directory you
select for storing files specific for the omega compiler.
I. e. tex/omega/ and tex/omega/generic look like right places,
while tex/omega/plain doesn't.

> What else, if anything, is omega-specific in the same way?

Browsing an old teTeX 2.0 rpm shows that there were some files in
the omega/plain directory, namely grlccodes.tex, omega.tex and
omega.ini. First 2 files now reside in tex/plain/omega, while the
last one in tex/plain/config.

Note that this directory now contains a bunch of other engine-specific
INI files, which previously resided in their own directories. For me,
this looks like one more disadvantage of the new TDS: may be, placing
various INI files into the same location has nothing wrong by itself,
but I don't think the tex/plain tree (which normally should contain 
only files, compatible with standard plain tex and thus with ALL plain
based formats) is the right place for this purpose.

> As explained in the rationale I sent earlier, the main issue is that
> engines aren't really a good distinction, because they are so
> similar. tex, etex, pdftex, pdfetex are all "almost" the same, and
> ditto omega and aleph.  Most packages need no changes to run under
> any of the above, and of the rest, most adapt themselves to whatever
> is running.  So trying to put files under an engine-specific
> directory usually turned out to be wrong; they actually ran under
> other engines.

But in teTeX 2.0 most engine specific directories were almost empty
and contained only configuration files, because all packages compatible
with several engines could be placed into tex/plain or tex/latex
anyway. So I don't see why the new scheme is better and which problems
it resolves.

And even if most engines are really so similar that specific 
directories are not needed, this assumption surely would be wrong
for omega, because omega not only introduces its own primitives, but
also accepts 16-bit characters in its input. That's why most
omega-specific files cannot be processed by other compilers, even if
they look as having a TeX syntax. So, if the initial task was to unify
really similar engines, omega could be unified with aleph/lamed, but
not with tex.

Our previous discussion already allowed to figure out the fact that
we really need a compiler-specific directory for omega and a 
format-specific directory for plain omega. The problem is, that, to
my mind, it would be really difficult to find a logical place for
such directories in terms of TDS 1.1. Really, let's examine, how the
possible solutions can look like:

-- it is possible to create 2 separate directories under texmf/tex,
e. g. tex/omega (compiler-specific) and tex/omegaplain
(format-specific). Note that both directories should be searchable for
omega and lambda. Looks too complex, isn't it?

-- it is also possible to create only one engine-specific
directory (e. g. tex/omega) and put all plain omega specific stuff
into a subdirectory (say, tex/omega/plain). In this case it would
be difficult to understand why there is a separate tree under
texmf/tex for another omega-specific format (i. e. lambda);

-- and, finally, it is also possible to move the whole tex/lambda 
tree into tex/omega, so that the new tex/omega directory will contain
exactly the same files as texmf/omega in previous versions, except
OCP/OTP. This solution would look acceptable for me, but it seems
to break the TDS 1.1 model anyway, and so it might be really easier 
to restore the old texmf/omega directory with all its contents.

> No.  As far as lambda is concerned, the search path looks like this:
> TEXINPUTS.lambda = $TEXMF/tex/{lambda,latex,generic,}//

I understand :) I gave this example just to show that
format-specific packages should go into a format-specific directory just
because they are format-specific rather than because they may contain
any conflicting files. There is no difference between lambda and
plain omega at this point. So, plain omega needs its own format-specific
directory, separate from plain tex.

> texmf/tex/lambda/antomega certainly seems like the right location for
> your package.  Is there a problem with that?  I am confused about
> what you need.  If you put your hyphen.cfg there, it will get read
> before any hyphen.cfg under latex.

Well, currently there are no problems with this file, because for
historical reasons it resides in lambda/antomega/ (although
something like omega/generic might be a better location). Currently
antomega contains 2 groups of compiler-specific files which are
placed outside of the lambda directory: hyphenation patterns
and lists of lccode/uccode values for various Unicode characters.

> For reference, you can see all the current search path definitions at
> http://tug.org/texlive/devsrc/Master/texmf/web2c/texmf.cnf
> It's nearly the same as TL 2004.  And all the formats do have their
> own directories.

But plain omega doesn't (its search path is exactly the same, as for
plain tex).

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

Moscow State University
Historical Faculty