Le 30/04/2010 13:22, Mojca Miklavec a écrit :
To answer your question about mongolianlmc: I figured out that I have
language_codes['mn-cyrl'] = 'mn'
language_codes['mn-cyrl-x-lmc'] = nil
in generate-plain-patterns.rb. There's a long story to be told about
that, but some short facts:
> [...]
Considering those facts, I do not think that it's worth to care about
loading mongolianlmc into LuaTeX at this moment. We may consider it
later when its author comes back from a time demanding job, but at
that time we'll have a single version of patterns left anyway
(hopefully).
Ok, thanks a lot for this very detailed explanation. I now tend to agree the we
don't want to support it in LuaTeX, but the decision is arguably not mine to
make. Also, see my other message a few minutes ago (in reply to the first
message in this thread).
At the end you'll probably want to somehow access data about languages
in "lua" form as well, so in the long run it might make sense to have
something like
"arabic" = { ... hyphenate=false, ...}
anyway, but that's up to you.
Agreed. Actually, already implemented :-)
As far as languages.dat is concerned:
1.) I still claim that you don't want to support ibycus
Ok. I'll leave the final decision to you, unless someone else comes with a
strong opinion about that :-)
2.) If the language will not be defined in language.lua.dat, this
means that the language will not be present in hyph-utf8, so that
gives you no warranty that format will compile at all.
Well, this is already a problem, since languages.dat is share between all
engines. So, no new problem here.
On the contrary, we are providing solutions with the new version of the code: it
is enough for us to add an entry in languages.dat.lua with "special =
'disabled:non-utf8'" et voilà, problem solved for LuaTeX. (But not for XeTeX
anyway.)
a) German timestamped patterns (for which it might make sense to get
better support in LuaTeX anyway) - hopefully without compatibility
problems
I tend to trust the german-x team on this point.
b) If some other author creates a non-utf8 compatible patterns and
convinces Karl or Norbert to create a tlpsrc file with AddHyphen entry
Unlikely to happen, and again this problem already existed, and we now provide a
way to solve it for luatex (but the problem remains for XeTeX).
c) If author of some other language decides to do the same as Germans
More on that later.
3.) Keep in mind that MikTeX might have its own way of loading
patterns (I have no idea how it works), but it doesn't support LuaTeX
yet anyway, so you may worry about details later.
I'll check that in due time, but I tend to assume they use a language.dat (resp.
language.def) with the same format, however they maintain/generate it, because
otherwise they would have to patch babel's hyphen.cfg (resp. etex.src) which I
assume they don't want to do.
One more request: I would be really glad if we didn't have to have
en-us-x-knuth in our repository.
1.) The patterns are the same, the ushyphmax only contains a few more
exceptions.
2.) You may load it at format-generation time from hyphen.tex if you
want to load exactly those patterns.
Granted! I don't need it, for reason 2, so it's entirely up to you.
Of course we may leave the proper entry in lua table.
Yeah, we need that one, for the list of synonyms.
Thanks,
Manuel.
