> For each line measure the difference between the desired width and the actual width and square the value. Then add these values together.
seems like you could add something to the loss function like sum (over hyphens) k*(1/1+d)^2 where d is the shortest vertical distance to the nearest next hyphen and k is a tunable.
Yikes; the author is simply wrong about TeX in the quote about squaring the width difference (there is some cubing going on, but of space stretch and shrink ratios of the natural space width specified per-font). He also seems to imply that TeX doesn't take care to try to avoid two hyphenated lines in a row, which is also not true ("doublehyphendemerits"). And, finally, he implies that TeX doesn't prune its search tree while looking for a global optimal set of line breaks, when of course it does. So, it's not clear what exactly his algorithmic improvement is supposed to be?
now that i read more carefully, looks like they're just making an attempt at a line breaking algorithm for their own edification and sharing the results.
some parts of it make it sound like they're trying to beat tex, but on second read, nah. should probably be clearer (and maybe more correct) about paraphrasing how tex works though.
seems like you could add something to the loss function like sum (over hyphens) k*(1/1+d)^2 where d is the shortest vertical distance to the nearest next hyphen and k is a tunable.