[luatex] concerning lccodes
bernd at dante.de
Fri Jan 10 11:45:10 CET 2014
On Thursday, 9 January 2014 20:28:06 +0100,
Patrick Gundlach <patrick at gundla.ch> writes:
> > sorry, this a plain TeX question (didn't read the interesting
> > chapters of the TeXbook). Are lccodes language dependent? I can
> > only see a single table tex.lccode in LuaTeX.
> I can't give you an authoritative answer, but no, the lccodes are
> not language dependent.
This is true for Knuthian TeX (described in the TeXbook).
Starting with v2 e-TeX has the feature that the \lccode values used
when reading the hyphenation patterns are stored in the internal
hyphenation pattern trie if \savinghyphcodes is > 0 and these values
are used for hyphenation.
It was IMHo not the best design decision in TeX to intermix the
lowercasing and uppercasing functionality based on the token character
code level with the hyphenation glyph code equivalent class
functionality on the node glyph code level ... because this intermixes
character codes with glyph codes, i.e., it makes life easier if both
coding schemes are more or less the same, i.e., input encoding and
font encoding are more or less the same in TeX. It was reasonable at
the time of TeX(82)'s birth.
For e-TeX the design decision to extend this lccode functionality is
also ok, because e-TeX only adds small things to TeX and keeps
For LuaTeX it will be better to distinguish between the two worlds of
lowercasing/uppercasing entity codes and hyphenation entity codes.
(And for compatibility, just add some defaults to link between
the "old" \lccode<n>+\uchyph dependency to the newly introduced things.)
> > What I want is to get the lccode of characters from glyph nodes,
> > which might be of various languages. I'm currently doing
> > something like
> > lc = tex.getlccode(n.char)
> > but shouldn't n.lang be taken into account in the conversion?
> IMO it should.
Yes! (atleast similar to the e-TeX functionality)
(in the old days I was a member of the e-TeX team ;-)
More information about the luatex