LATEX-L Archives

Mailing list for the LaTeX3 project


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 >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Frank Mittelbach <[log in to unmask]>
Fri, 9 Feb 2001 16:38:29 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (110 lines)
I've just looked again at the hyphenation patterns available for TeX and every
time I do that again I'm shocked what I find (in several respects).

one of the big problems that i see is that for most patterns out there it is
absolutely not clear for what kind of font encoding they have been produced.

With very few notable exceptions all of them are encoded using some sort of
hard code table, ie ^^ notation so that they are valid only for a single font

This seems very unfortunate since if they would be stored in a different
format it would be possible to apply them to different font encodings.

Take, for example, T1 and LY1 both of which do contain all the glyphs needed
for a number of languages. Therefore a pattern set for French, or German, or
Polish, or ...  should be usable with any fonts in either encoding. But
unfortunately they are not because they refer to things like ^^b9 meaning \'z
(this is an example from the plhyph.tex file).

if we would replace such patterns by patterns looking like .\'c\'z8 we would
be able to reuse the patterns for several font encodings provided the internal
latex representations \'c etc are doing the right thing within the \patterns

Analysing the behaviour of the fontencoding specific commands we can see the

 \DeclareTextComposite \DeclareTextSymbol are fine as they expand in the mouth
 (using old TeX terminology) to a font position which is what we want

 But toplevel \DeclareTextCommand (such as \L in OT1) are likely a problem
 and so is most likely anything done via \DeclareTextCompositeCommand.

 Finally we do have \DeclareTextAccent which is also not suitable by default
 in a \patterns declaration since it results in a call to the \accent

So before discussion what could be done here let me first explain what is
currently being done with some of the hyphenation files.

A concept found in several files is to surround potentially problematic
patterns by a command \n which is, depending on the encoding used, either
defined to be \def\n#1{} (ie ignore) or \def\n#1{#1} use.

In other words you have a hyphenation file, say for German, which can be used
with T1 encoding but also with OT1 encoding by simply removing all patterns
which contain references to umlauts or sharp s. I'm not sure if the resulting
pattern file is the optimum possible for an encoding like OT1 (actually i
doubt that) but it is certainly sufficently accurate enough to be usable.
Perhaps Bernd Raichle can comment on this.

The problem in my eyes with this approach is that you have to know beforehand
which of the patterns are impossible to use in a certain encoding. Which is is
trivial if you design the file for a fixed (peferably small) number of
encodings it is in practice impossible if you do not know the encodings it
should be applied to.

so what would be the alternatives?


here is my idea which most likely would need some further refinement.

suppose we have the pattern \patterns{.r\"u8stet} (which is taken from the
German hyphenation file).

suppose further that for each encoding we have defined a code point which is
not a letter, say, the position of `!' (the latter might be a bad choice i
don't know). For encodings which do encode not 256 characters we should be
able to chose a code point outside the encoding itself. Let's call this
character X

during pattern reading we then map the \add@accent command (which is what
finally is used in case of an internal representation for an accent which is
not also a composite) to


so what we get is the pattern \patterns{.rX8stet} which is an impossible
combination (especially if X lies outside the encoding range)

\DeclareTextCommand and \DeclareTextCompositeCommand would need to be handled
in a similar fashion (which would require some small changes to the internals
of nfss since at the moment \DeclareTextSymbol is internally calling
\DeclareTextCommand etc which would then not appropriate.

The downside of this approach is that for  encodings which would make a large
number of patterns invalid this way we unnecessarily store spurious patterns.

On the positive side is that i can go and say

\input german-hyphenation-patterns

and automatically get the a set of patterns suitable for LY1

the reason i bring this up is that if one extends the notion of "current
encoding" to something like "current encodings suitable for a language" then
one needs to have hyphenation patterns for all language/font combintions (at
least that would be desirable)

the technical support for this approach doesn't seem to be very difficult to
provide, but i don't know if there would be enough people willing to actually
look at the hyphenation files out there bring them into a suitable source
form. The latter would be necessary in my opinion to some extend anyway, there
are a number of such files which would result in very strangly behaving LaTeX
format if one actually adds them