On 5/26/2016 7:05 PM, Élie Roux wrote:
the problem with that is that we get a more and more complex routine
which degrades performance, makes it hard to configure and explain,
even not intuitive
I don't agree but ok
anyway, because in a glyph the left/right fields store the current
values of left and right hyphenmin it's not too hard to run over the
list using a callback and adapt that value (the first one in a word)
- identify start of word
That looks like a huge overhead and a fragile algorithm... But in a
first step it can be done quickly indeed.
the overhead is not that huge and the more advanced typography one
wants, the more overhead there is anyway; also, adding more and more
tricks to the engine (end there is no end to what users want) makes that
code more complex, also consumes memory and eventually also gives overhead
(fyi: context has a pure lua hyphenator and that one is not that much
slower than the built in one)
- look at left value of the first glyph - see if there is a char in
the #left glyphs that you want to count more or less times - and
adapt the left value accordingly
Well, if it's easy to configure and explain, and intuitive (which is not
obvious to me), that looks like a good solution indeed. But if changing
the left value of the glyph node works, I think the manual should be
changed, as it states "the frozen \lefthyphenmnin value" (section
7.1.2.12)... According to what you say, the value is not frozen, is it?
well, it gets frozen (stored) in the glyph node as some more language
specific properties (in a similar fashion a penalty gets stored in a
disc node) ... in traditional tex the values current when the pas gets
built are used (which basically means: not frozen)
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.com | www.pragma-pod.nl
-----------------------------------------------------------------
