<div dir="ltr">A minor correction:  characters *can* have zero width.  A character<div>with a zero *index* to the width table does not exist, but one of the</div><div>other entries in the width table can certainly be zero.</div><div><br></div><div>(I don't know if any such characters exist, off-hand.)</div><div><br></div><div>-tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019 at 5:22 PM Doug McKenna <<a href="mailto:doug@mathemaesthetics.com">doug@mathemaesthetics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Karl, Didier -<br>
<br>
My code faithfully duplicates DEK's algorithm, which his famous comment about "premature optimization" does not apply to, because his code for appending characters to the layout was turned into "post-matured" spaghetti.  I never tried to rewind its clock, so my C code is functionally the same pasta also, though it is easier to read IMNSHO.<br>
<br>
Looking at my comments and code, written a few years back during my Vulcan mind-meld with the WEB source, it seems that a boundary character is used to prevent ligatures and kerns from occurring when two or more adjacent characters are in different fonts.<br>
<br>
The thing is, there's only one boundary character per TFM font.  Therefore, it kind of by definition has to serve as some kind of generic flag in multiple situations.  There's no express metrics stored for a boundary character per se in the TFM, but if it's a legal character code (between 0 and 255 for TFM), then presumably that character in the font can have metrics, usually of zero width, but not precluded from having non-zero width.<br>
<br>
Unfortunately, a character with zero width is formally considered missing from the TFM font, in order to save space by not storing some other bit somewhere in the font data that would declare a character code between |bc| and |ec| as missing (see the char_exists() macro in the WEB source; it tests for positive width).<br>
<br>
Because of that little non-orthogonal problem, there's the TFM font's so-called "false" boundary character, which is synthesized when the TFM file is read in.  The false boundary character is the boundary character, unless the boundary character's width is non-zero, in which case the false boundary character is set to a not-a-character value.  The comment in WEB source says it's to prevent "spurious ligatures".  This smells like a hack to me, but perhaps it's elegant.  Again, the problem being solved (I think) is how to introduce a character of zero width into the layout to break a kern or ligature, rather than having it flagged during input as missing from the font before any attempt to append.<br>
<br>
DEK uses the phrase "pseudo-ligatures" in a comment, but he never defines the term, and the phrase is not used anywhere else in the TeX code that I can find, so that's not much help.<br>
<br>
Anyway, FWIW after a quick flyby of the code.  Because of the complicated nature of the ligature stack and the ligature/kern "program" in the TFM file, I'm probably not explaining stuff going on there very well.  Indeed, the above may be quite wrong.<br>
<br>
It seems post-mature optimization is kind of evil too. :-)<br>
<br>
<br>
Doug McKenna<br>
<br>
<br>
<br>
----- Original Message -----<br>
From: "Karl Berry" <<a href="mailto:karl@freefriends.org" target="_blank">karl@freefriends.org</a>><br>
To: "Didier Verna" <<a href="mailto:didier@didierverna.net" target="_blank">didier@didierverna.net</a>><br>
Cc: "texhax" <<a href="mailto:texhax@tug.org" target="_blank">texhax@tug.org</a>><br>
Sent: Wednesday, September 18, 2019 4:42:24 PM<br>
Subject: Re: About boundary characters<br>
<br>
Hi Didier,<br>
<br>
    I have several questions about boundary characters in the TFM format.<br>
<br>
I surmise experimentation is necessary. The "specifications", such as<br>
they are, are insufficient, so far as I can tell. (Since they were added<br>
in the 1989 update, Don had only a tiny amount of space in which to<br>
describe them.)<br>
<br>
It's never been clear to me what TeX actually does with boundary<br>
characters (so maybe their metrics do not matter?). I believe that they<br>
are only relevant in the ligkern table, but that's about all I know.<br>
I read the descriptions in the {mf,tex}{book,.web}, as I suppose you<br>
have also, but clarity is not forthcoming. As far as I know there is no<br>
other significant source of information.<br>
<br>
Doug, I surmise you may have more knowledge than anyone? But maybe your<br>
re-implementation was too long ago now :).<br>
<br>
It would be nice to have a thorough article for TUGboat on boundary<br>
characters.<br>
<br>
As for what existing fonts may or may not do with them, (1) it's hard to<br>
say anything without knowing what fonts you are talking about, and (2) I<br>
wouldn't take it too seriously. Maybe the font creators did lots of<br>
experiments and created boundary chars the way they did for specific<br>
reason, but IMHO it's equally likely that they simply followed some<br>
examples, tried to do what they thought made sense, and whatever<br>
happened, happened. --best, karl.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--  <a href="http://cube20.org/" target="_blank">http://cube20.org/</a>  --  <a href="http://golly.sf.net/" target="_blank">http://golly.sf.net/</a>  --</div></div></div></div></div>