Peter Heslin wrote: > Hans Hagen <[EMAIL PROTECTED]> writes: > > >> 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. > let's first look at the logic, i'm sure that Thomas can extend the conversion then (after all, it's logic -)
the dependency on perl is mostly gone and will be completely gone in the future > 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 > sure, but i've been bitten too often; context nowadays comes with a truckload of tools and methods, and if we had to adapt to something else everytime that latex is ready for it we quickly become improductive; keep in mind that in that case we not only had to eal with you, but also with another 20 pattern people; now we can just pick up and rearrange the bits and pieces; (a similar things happens with fonts, context had built in map file support before things like updmap (useless for context anyway) came around, so adapting to yet another method was counterproductive; so, context has its own encoding naming scheme -if only because the number of metrics that really ship is not that large-) [another nice example: context supported lm fonts right from the start, and in the end changes in names of map files took place because of other packages needs; so, again we are forces to ship our own stuff] > 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 > take alone the names ... every package has different preferences, for years i *did* use the (hardly) generic patterns that and each year something else was broken; context is used in production environments and we need stability in those areas > 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 > sure, that's the ideal world, but 25 years have learned that this is near to impossible; actually i tried to start such an effort, starting with the names, but i gave up on it simply because i foresaw waste of time btw, already quite some years ago i published a method for encoding neutral patterns, but i never got any response on that, http://www.pragma-ade.com/general/manuals/mpattern.pdf, also published in tugboat (and i did some presentations about it) > 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. > we will gladly use your stuff but quite probably package in the context way (maybe ctxtools will simply copy the existing utf ones, repackaged in a context way); btw, context uses utf patterns also in non utf mode, i.e. in pdftex etc Hans -- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- _______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context
