Hans Hagen
i prefer the rules, so if you can sort that out with peter
In that case, you can examine the internals of my Perl script elhyph-utf8 and translate its logic to Ruby in ctxtools. But that is a non-trivial effort, and I cannot do it. A better alternative may be to have ctxtools simply call elhyph-utf8 as an external script. Does Context still have a dependency on Perl? If so, it would be much easier just to call the Perl script. I would be happy to ensure that elhyph-utf8 remains format-neutral. [A footnote: the original patterns are not Latex-specific, as you said, but are specific to the LGR encoding, which Latex Babel happens to use; but that Greek encoding is older than Babel, I think, and is also used elsewhere in the TeX world.]
since there is no infrastructure for patterns, and since i want to independent of anything happening in that area (keep in mind that we've been bitten by that too often: renaming, disappearing, funny internals, latex specific, limited encodings, etc)
I can appreciate your pain, but I'm sure that you are aware that there is also a danger in having Context fork its own patterns: that you may introduce bugs (as happened in this case), or that you may not pick up on upstream bug-fixes. Jonathan Kew has suggested that it might be desirable to have a set of general-purpose utf-8 hyphenation patterns in the texmf tree, which could be used by various TeX applications. From your comments it is clear that, in order for the Context community to buy into such a scheme, it would be necessary for this collection of patterns to be managed carefully, by consensus, and in a format-neutral manner, with good advance communication of any changes. If this were to happen, the advantage for Context is that the dangers I mentioned above could be minimized. But it is up to you to balance the potential risks and benefits for Context. -- Peter Heslin (http://www.dur.ac.uk/p.j.heslin)