[NTG-context] Greek hyphenation patterns

[Hans Hagen]

Peter Heslin wrote:
> Hans Hagen <pragma at wxs.nl> 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
-----------------------------------------------------------------