[tex-live] Re: antomega [was: Multilingual LaTeX: Greek, English, and UTF-8]

Alexej Kryukov akrioukov at newmail.ru
Sun Sep 18 22:14:54 CEST 2005

On Sunday 18 September 2005 22:39, you wrote:
> I come to the following conclusions:
>   - antomega provides its own hyphen.cfg, so is classifies as a
> format of its own
>   - ocp / otp files belong to omega/ocp/antomega resp.
> omega/otp/antomega - the package needs some support for finding files
> in omega// (to be able to check for existance of some files)


I am sorry, but this solution just messes things up. Regarding
the hyphen.cfg file, I have already explained that it is needed

-- to prevent loading babel's hyphen.cfg into the lambda/lamed

-- to set \catcode, \lccode and \uccode values for some Unicode

The first task is optional, but desired (because Babel's model
of i18n is quite useless in the context of omega). The second task is
almost mandatory, because loading huge lists of character codes
at the runtime is surely something that should be avoided. However,
the default omega distribution currently doesn't provide any
standard way to do these things (previously omega has its own
hyphen.cfg, which was abandoned for unknown reasons). 

So, by turning antomega into separate format (and leaving lambda/lamed
in their present state) you just encourage lambda/lamed users to always
load useless Babel extensions and to invent some non-standard ways of
loading character codes into format (e. g. by hacking hyphenation
patterns, as Apostolos Syropoulos sometime proposed), while antomega
would provide a standard and elegant (I hope) way to do that.

And of course, if somebody has built his lambda with antomega's
hyphen.cfg, this doesn't necessarily mean (s)he also has to invoke
the antomega.sty package from all his/her lambda documents. In fact, 
(s)he may use any other packages of his/her choice, but still take
advantage of *some* features antomega provides (like lists of
character codes or hyphenation patterns). This is quite similar to
Babel, which has different levels of support for latex and plain
tex. If you create a separate format for antomega, you will
just prohibit access to antomega's capacities to other omega-based
(or aleph-based) formats. 

Regarding the proposed directory structure, I can just repeat some
things I have already stated in my answer to Staszek:

>   doc/antomega/base

Antomega is useless without a 16-bit compiler, so having a top-level
antomega directory (in doc/, source/ or elsewhere) would be a 
nonsense. doc/omega/antomega is the only acceptable location.

>   omega/otp/antomega
>   omega/ocp/antomega

I have explained in my answer to Staszek, why my OCP and OTP files
are separated into 3 groups (uni2char, char2uni, antomega), and should
not be placed together.

>   source/antomega/base

Same as with docs.

>   tex/antomega/unidata

These filed are compiler-specific. Don't prohibit access to
this directory to other omega and aleph-based formats.

>   tex/antomega/base
>   tex/antomega/encodings
>   tex/antomega/hyphen

The hyphenation files are compiler-specific par excellence.
They were written for omega, not for specially for antomega.
and can be used with any omega-based format.

Alexej Kryukov <akrioukov at newmail dot ru>

Moscow State University
Historical Faculty

More information about the tex-live mailing list