On Sat, May 22, 2010 at 17:14, Norbert Preining wrote: > On Sa, 22 Mai 2010, Mojca Miklavec wrote: >> This is really ugly to me. > > Umpf. > >> Second: Karl has already objected to that in past, but in case that >> you do generate luatex-specific language.dat.lua, instead of >> luaspecial="disabled:only usable in 8bit engines", I would much prefer >> to have something like >> enable8bit=true,enableutf=false >> and for indic scripts >> enable8bit=false,enableutf=true >> then you could just as well generate two language.dat files: one for >> 8bit engines and one for XeTeX. And even if not: the syntax would be >> much more clean. > > So what are the cases we have to decide? > group 1: > handled with the loader patterns for pdftex and related ones > group 2: > xetex that can only load utf8 patterns > group 3: > luatex, another set > > Is that right? In additon, group 2 is a subset of group 1, right? > And group 3??? > > I would like to see some orthogonality.
My idea in your nomenclature: - group 1: for pdftex and related (language.dat) - group 2: for XeTeX (language.dat in different xetex-specific tree) - group 3: for LuaTeX (using language.dat.lua) - The set of languages is exactly equal for group 2 and 3, it's only that they are loaded in a different way. (Though there might be a slight catch since luatex should be able to use "more advanced patterns", so it may happen that the files won't be equal any more in future; but that doesn't depend on me; an example is Hungarian that uses different patterns for OpenOffice and TeX, generated by the same author) - Group 1 is not a subgroup of 2/3. The majority of languages is the same, but some are only usable in group 2/3 and some are only usable in group 1. - Both 8-bit and XeTeX patterns would still be loaded using the same loadhyph-xx.tex. The answers to other questions later ... Mojca
