Karel Skoupý wrote:
Be careful about the redefinitions of the fonts in the middle of the list. It can be either forbidden or reproduced in the read.
For me the fully restorable read syntax is very important (can I get all [...]
I believe all extra parameters had better be in-line, for optimal flexibility. As much as possible, as least: some information is irretrievably lost in current TeX. Quite a lot can be solved by adding a new read syntax for character and language nodes, one that does not depend on font and language id numbers. It'll be rather verbose and a tad slow, that is the price you pay for extra flexibility.
\hsize=2in \the\list0 \par % typeset the node list
So \the\list0 will expand to tokens (consistent with \write), right? It won't just insert the list on the currently active list (would be inconsistent with \write), right?
Yes. I was aiming to be consistent with other uses of \the (easier that way). For direct insertion, something like \unlist0 would be needed (analogous to hbox operation).
But concerning the metric files, if I want to treat hyphenation locally, then I also need the kerning and ligature programs. In TeX it is done too early (and then it is taken apart and (wrongly) reconstructed during hyphenation pass). I want to do ligatures and kernings on demand, basically after hyphenation (it's not that simple, but anyway).
In current TeX, it is not done too early: ligkerns can influence which line breaks are chosen, so the ligkern programs have to be applied first thing. Only the manner in which it is done is not quite as general as should have been, resulting in the (sometimes) incorrect reconstruction of ligatures.
is hyphenation known at that time (if i got it right, tex only looks at places where breakpoint smake sense, so you don't get all possible
NO. It screws up everything, not only taken or potential breaks, but even the potential hyphenation points which are never considered a break.
It does all potential hyphenation points, but that is still a subset of all hyphenation points: absolutely impossible points are ignored (like in the middle of the first line). At least, that's what Knuth's web comments say, and note rhat is not a feature of the algorithm, only an optimization.
..[]... Taco, is that correct, or am I too TeX unfriendly?
Perhaps just a little, but you have a valid case ;-)
It works for English (does it really always ?), because it is simple,
Considering how strange the code is, it works fairly well for a surprising number of languages.
right? I don't know, whether it is a real problem in any other language in practice. I just know the code and I think that it is incorrect, inconsistent and illogical.
It is also near-impossible to fix while maintaining compatibility, which is probably why no-one has seriously attempted to clean up the code, up-til-now. Greetings, Taco