## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

Donald,

> >  > - Hyphenation patterns are specified in terms of the output encoding.
> >  >   This means that every character appearing in the hyphenation rules
> >  >   must have a physical slot in the selected font.
> >
> > only in the internal storage format for patterns used within TeX. On the
> > abstract level this is not at all true even though the source format of
> > existing patterns tend to be written in this form as well.
>
> Frank also made an earlier comment in this regard, which, while true,
> is of marginal relevance to the discussion of multi-lingual/-encoded
> documents.

Marcel's summary was trying to put forward technical points to be able to
weight them against each other. I was simply trying to put them technicaly
right where i considered them wrong. but i disagree with you when you say that
it has nothing to do with it.

> Yes, it is nice if hyphenation pattern input files use symbolic
> representaions of characters (\ss) rather than hex code values
> so they can be used for different font encodings.  But the font
> encoding must be selected when the format is generated!  This
> doesn't help the user who wants to use various font encodings,
> and it certainly does not facilitate multi-encoded documents.

you are right that the hyphenation patterns have to be selected at format
generation time so that you are unable to actually extend that set for a
single document. however, with "these days" TeX implementations  there is
typically enough room to actually store mutiple patterns and that means that
for typical usages at a site you can combine all the patterns needed (for
several languages and several font encodings)

don't forget that in many cases the largest pattern set can in fact serve for
several font encodings if they (for the character set of the corresponding
language) actually have the same slot positions  in the font encoding.

> For hyphenation purposes, multiple encodings must be treated as
> multiple languages.

technically you are right but you are in fact pointing with your statement at
the basic error Don made with TeX3x: calling something \newlanguage and
\language when in fact it should have been called something very different.
(eg pointer-to-hyphenation-patterns-related-to-some-output-encoding)
a lot of the problems result from using the TeXnical) term.

so no: not multiple encodings have to be treated as multiple languages but
within one language you need to store for each font encoding used which of the
pointer-to-hyphenation-patterns-related-to-some-output-encoding's you have to
apply when typesetting in this encoding.

and given that you (these days) can store a suitable number of such
pointer-to-hyphenation-patterns-related-to-some-output-encoding's you can with
a single format typeset multiscript documents for a number of combinations of
scripts. Clearly you have a limit so if you want to be able to typeset in too
many combinations you need a number of formats but thats in practice not a
real issue.

However, to be able to automatically generate those internal
pointer-to-hyphenation-patterns-related-to-some-output-encoding's you need the
hyphenation patterns externally stored in something which is independed of the
output encoding.

> This again points to the need for babel to
> specify the desired/required font (encoding) when it selects
> a language.

yes. if we take the approach outlined with my xnfss code enabling the the
specification and use of multiple encodings per language then such a list
should be attached to each language. you would then associate with each such
encoding per language a suitable
pointer-to-hyphenation-patterns-related-to-some-output-encoding (in a number
of cases it could be the same one, eg OT1 and T1 for German would share the
same) and if you don't have an appropriate
pointer-to-hyphenation-patterns-related-to-some-output-encoding you could
select the "no-hypenation" one (or raise an error and ask for a different
format)

>
> >  >   However, logically
> >  >   hyphenation should not depend on output encoding, and one should be
> >  >   able to mix fonts with different output encodings without losing
> >  >   correct hyphenation.
> >
> > yes, and it is possible without technical problems (in theory)
>
> Possible in TeX as it stands???  Only by loading the patterns
> resolved for each encoding.

of course, but the resolvement process you be happening abslutely
automatically in the background which why i say possible without technical
problems. and i said "in theory" because that requires hyphenation patterns
externally stored in a way that i can (for any font encoding) generate from
them the appropriate internal
pointer-to-hyphenation-patterns-related-to-some-output-encoding form without
problems.

> Or does "in theory" really mean
> what it says -- not in practice.

no

>
> >  > - It is rather hard to make a new font available under LaTeX.
> >  >   Essentially one must create a virtual font which has all the
> >  >   character slots in the places where hyphenation expects them to be.
> >
> > wrong.
>
> Wrong...I guess.   Maybe Frank runs LaTeX on initex and has patched
> fontenc.sty to load patterns for whatever font encoding is requested.

unfortunately that isn't any longer possible with TeX as the hyphenation tree
is compacted and doesn't allow addition after the first use (ie after a
paragraph started.

frank