hours, from 40 to 32, this sen ator says,
Bad ness 0
(Knuth’s version)
Dr. Tom Mur phy VII, Ph.D.
March 2024
It has become clear to me that many peo ple w alk
this Earth com pletely un both ered by incor rect de -
tails. For exam ple, they are un con cerned when a
hy per link includes a sur round ing space char ac-
ter. It doesn’t up set them when the screw heads
on a light switch w all plate are not all lined up.
They didn’t no tice that the rules of Wordle’s “hard
mode” are sim ply wrong. They care as much as the
phone’s au tocor rect (none) about the dif ference be-
tw een “its” and “it’s.” When some one asks, “W ill
you marry me?” and they think “Oh my god!” it’s
not because the pro poser prob ably should hav e
used the sub junc tiv e would.
I am... not like this. If a char acter in a TV com mer -
cial is han dling a coffee cup but I can infer from
its mo ment of inertia that the cup does not con -
tain any liquid, I im me di ately lose sus pen sion of
dis belief and will not pur chase the prod uct fea-
tured in the com mer cial. I literally pro jectile vomit
if Auto-Motion Plus is en abled on a tele vision
in the ho tel I’m stay ing in, even if the TV is not
turned on, or if some one mis uses the word “lit er-
ally.” If I see a para graph miss ing a pe riod at its
end on Wikipedia, I will spend dozens of hours
writ ing soft w are to or ga nize and semi-automate
a dis trib uted effort to fix all the miss ing pe riods
on Wikipedia. [2] And worse, each time I learn of a
new type of mis take, I am for ever cursed to no tice
that mis take
Seriously: One time I found my self spell-correcting
some one else’s lorem ipsum text in a slide. It said
“lorem ep som,” which is funny. I think about that
incident all the time. The per son that wrote the
slide prob ably thinks about things like lev erag ing
syn ergy, gen erativ e AI, meta verses, blockchain 3.0,
snack able con tent, being eco-green, and so on, with -
out it occur ring to him that these things could hav e
nu ance and mean ing sep arate from their names.
He has prob ably nev er even read the Wikipedia ar -
ticle on Lorem Ip sum. He is suc cess ful and rich.
An other suc cess ful per son is the con gressper son
Bill Cas sidy. Crit icizing a pro posed bill that would
reduce the stan dard work w eek in the US by 8
Sen. Bill Cassidy of Louisiana, representing the
______ party, said paying workers the same
wages for fewer hours would force employers
to pass the cost of hiring more workers along to
consumers.
“It would threaten millions of small businesses
operating on a razor-thin margin because they’re
unable to find enough workers," said Cassidy.
"Now they’ve got the same workers, but only for
three-quarters of the time. And they have to hire
more.”
Actu ally, that’s not exactly the quote, but I needed
to make it look nice. [3] And this is not a pa per about
pol itics, but let’s just say you can guess what word
goes in the blank.
Any w ay, OKAY, first of all, ra zors famously hav e
high mar gins. It’s like the worst pos sible metaphor
here.
For an other thing: This guy mixes fancy ty po -
graphic quotes and ASCII ones.
But the main thing I w ant to talk about is: What?
No! 32/40 is four fifths, not three quar ters. This is
not, like, com pli cated math. It uses some of the
world’s small est integers. Every body knows that
the work w eek is 40 hours, and that a work day
is 8 hours, and that the pro posed bill reduces it
by one day, giv ing four of five days. I don’t really
mind if some one makes an error in calcu lation
(w ell, I do mind, but I am certainly prone to do ing
it). The infu riat ing realiza tion here is that this per -
son does not even think of “three-quarters” as a
kind of thing that can be right or wrong. He says
three quar ters because it makes smaller num ber
feelings. You could imag ine him hav ing the con ver-
sation (with me, per haps): “You say four-fifths, I
say three-quarters.” Me: “But it is four fifths. And
why are you alw ays hy phen at ing it?” Him (smil -
ing pa tron izingly): “I guess w e just hav e to agree
to dis agree.”
The op po site of this per son is the hero called Don -
ald Knuth.
I’m not say ing that Don ald Knuth isn’t suc cess ful
and rich. Accord ing to the w ebsite “Fa mous Birth -
days,” [4] which is prob ably gen erated by AI or at
least by peo ple whose economic out put is mea -
sured in a count of words, and words whose value
is com puted by their abil ity to driv e ad clicks, Don -
ald Knuth is “is one of the most pop u lar and rich -
est Math emati cian who w as born on Janu ary 10,
1938 in Wiscon sin, Wiscon sin, United States. Math -
emati cian and en gineer who w as ar guably most
recog nized as the Pro fessor Emer itus at Stan ford in
Palo Alto, Cal ifor nia.” As one of the rich est Math -
emati cian from United States, accord ing to the
analy sis of Famous Birth days, Wikipedia, Forbes
& Business Insider, “Don ald Knuth’s net worth
$3--5 Million. *”
I sup pose it is ar guable that he is the Pro fessor
Emer itus. And it is very likely true that he is
the only pop u lar and rich math emati cian born
on that spe cific day in Wiscon sin, mak ing the
sin gu lar “Math emati cian” per haps a tech nical
master-stroke. But more likely this is just an amus -
ingly dense series of im pre cisions. The aster isk of
course does not hav e any referent on the page.
What I mean when I say that Don ald Knuth is the
op po site of this per son is that Knuth is inter ested
in un pack ing a sin gle un nec essary de tail, recur -
siv ely, un til it is com pletely solv ed. Accord ing to
the w ebsite Famous Bibliophiles, one day Don ald
Knuth set out to write down the en tire sub ject of
com puter science in a sin gle book called The Art
of Com puter Pro gram ming. As he w as do ing so,
he realized that de scrib ing com puter algo rithms in
a last ing form would require a pro gram ming lan -
guage that w as not sub ject to con stant revision, so
he invented the MIX instruc tion set for an ide alized
com puter. After writ ing some 3000 pages out in
long hand, he found that it w as im prac tical to print
them all in one book, so the plan expanded to be
mul tiple vol umes. Then when he got a draft of one
of the books back from the type set ter, he w as un -
happy with the de tails of the ty pog ra phy, and so
he paused his work writ ing down all of com puter
science to create some new com puter science: First
an algo rithm for de ter min ing where to place line
breaks in or der to make text op timally beau tiful,
then algo rithms for hy phen at ing words, then gen -
eraliza tions of these for type set ting math emat ics,
and then a full com puter type set ting sys tem that is
still in wide use today, called TeX. Along the w ay
he w as un sat isfied with the spe cific type faces that
existed in the world, and un sat isfied with the w ay
that type faces w ere de scribed at only one w eight,
and so he created the pa ra me ter ized METAFONT
sys tem and sev eral new type faces. Un de terred by
these excur sions, he returned to his orig inal task
of writ ing down the en tirety of com puter science,
us ing all the tech nol ogy he had built. By the time
he finished this, much more com puter science had
been invented, includ ing by his own hand, and so
he needed to rework MIX for the next vol ume, and
up date the first. The revised plan of eight vol umes
remains the inten tion in 2024. How ever, he found
that the vol umes w ere get ting rather long, and be-
gan releas ing por tions of vol umes (“fas cicles”).
So far, Volume 4 has been par tially pub lished as
books 4A [5] (fascicles 0–4; 912 pages) and 4B[6] (fas-
cicles 5–6; 736 pages). It is un known how many
more episodes remain in Volume 4. I expect that
every con versation that Knuth has with his ed itor
goes like this. Ed itor: “Hey, Don ald, I hope you’ re
w ell. Just won der ing if you hav e an up date on
when 4C will be ready? Or any more icicles?” Don -
ald E. Knuth: “I am work ing dili gently on fascicles
for Volume 4C. As I’ve men tioned in the past, it’s
im pos sible to tell how long it will be, since math e-
mat ics does not obey the rules of project man age -
ment.” Ed itor: “I just need a date to tell the pub lish -
ers.” Don ald E. Knuth: “Like I’ve said, any date
would be very low con fidence, other than the fact
that it will be in the fu ture.” Ed itor: “I just need a
date.” Don ald E. Knuth: “Would you like me to
say a date, know ing that it’s a very low con fidence
guess, and that I would be extremely likely to miss
that date, or even de liver early?” Ed itor: “Early!
Now w e’re talk ing.” Don ald E. Knuth: “What use
is the date if you’ re excited about the pos sibility
of it being early, rel ativ e to some un known date?”
Ed itor: “I just need a date for the pub lish ers.” Don -
ald E. Knuth: “2030.” Ed itor: “Thanks Don ald,
you’ re the best!”
Volume 5 is estimated to be ready in 2030, when
Knuth will be 92.
That’s a large amount of lan guage!
Night mare on LLM street
Then w e hav e Large Lan guage Mod els. [7] One of
the irritat ing things about LLMs is that they are so
buzz wordy, but un like most buzz wordy trends,
they are actu ally sub stan tiv e. They pro duce re-
mark ably flu ent text. With no ad di tional train ing
they frequently beat purpose-built mod els that
hav e been in de velop ment for decades. They gen -
eralize to com pletely new situ ations.
So many things about “AI” dis tress me. Dolor sit
amet! I worry about the de valu ation of hu man cre-
ativ ity, about large-scale dis infor ma tion and spam
ru ining the beau tiful library of know ledge that hu -
mans hav e created, about extreme con cen tra tion
of w ealth. And yes, I worry about com pet ing with
AI. Being able to work tire lessly and thou sands of
times faster than hu mans is a huge com pet itiv e ad -
van tage. Of course, I find some solace in the sig nif-
icant pos sible up sides. It might help us solv e hard
prob lems like climate change and AI. But even in
the best scenar ios w e will not be able to ignore it:
Even if it nev er gets as smart and pre cise as Knuth,
it’s already too econom ically use ful in its Lorem
Ep som state (just like Lorem Ep som him self).
On the other hand, the tech nol ogy is pretty neat
and lends itself to some nice ab strac tions. I lov e
play ing with words. So one of my side quests is
to mas ticate this whole scenario by exper iment -
ing with LLMs in prac tical and im prac tical ap pli -
cations, and to try to make it fun (for me) to pro -
gram with them.
Many things irritate me, so this is some thing I
hav e am ple expe rience with. I hav e a myr iad of
strate gies for di ges tion of them. For this work I’m
inspired by the “Hurry-Cow ard So-so-morphism,”
where I make con nec tions betw een top ics based
solely on con fu sion of su per ficial lexical sim ilar i-
ties with out regard to their un der lying mean ing.
So for exam ple w e hav e “ML ” mean ing both “Ma -
chine Learn ing” and “Meta Lan guage”, as w ell as
“type” both as in “type face” and as in “type sys -
tems for pro gram ming lan guages.” [8] And because
ma chine learn ing has claimed so many words,
there are a great many shared with ty pog ra phy
as w ell:
+----------+
|typography|
+----------+
/ \ “baseline”
“fixed point” / \ “floating point”
/ \ “weight” “vector”
“type” / \ “descent”
/ \ “kerning trick”
/ \ “dingbats”
/ \ “gradient”
+-----------+ +--------+
| functional|---------|machine |
|programming| |learning|
+-----------+ “ML” +--------+
“lambda” “generalization”
“parameter” “tensor”
By no coincidence, I already spent a lengthy in-
tro duc tion talk ing about Don ald Knuth’s work in
com puter ty pog ra phy. So now I can tell you what
this pa per is about. If in our near AI fu ture w e are
giv ing up on pre cision, per haps at least w e can
hav e some thing that w e w ant: Perfect ty pog ra phy?
This pa per is about a new type set ting sys tem, Bo-
VeX, which allows for the con trolled exchange of
pre cision for beauty. It essen tially giv es us a dial
betw een Lorem Ep som and Don ald Knuth. To il-
lus trate, w e’ll first look at a sim pler case by inspect -
ing one of my other inter ests: Super Metroid.
The scientists’ findings were astounding! They
discovered that the powers of the Metroid might
be harnessed for the good of civilization!
Metroid is a video game series about a brain that
has been en slav ed inside a jar in an un der ground
dat acen ter on the planet Zebes. This brain is called
Mother Brain and its goal is to con trol the hy per cap i-
tal ists called Space Pirates to increase their “score”
as high as pos sible by con quer ing plan ets through -
out the galaxy. Mother Brain w as invented by the
Space Pirates, although it is not clear whether the
cur rent situ ation w as actu ally intended by the
Space Pirates. The most su per version of Metroid
is Super Metroid.
In the 1990s the w ebsite gamefaqs.com collected
plain text “FAQs” for clas sic video games, then
just known as video games. On this site an other
hero w as born. They w ere writ ing the de finitiv e
guide to speedrun ning the SNES game Super
Metroid when they saw that some of their ASCII
lines ended up exactly the same length, and that it
looked good:
Once you save the game at your ship (about 1 hour 15 minutes is good), go
down to Tourian. Do not save your game in Tourian if you have intentions of
returning to any previously explored section on Planet Zebes. There will be
a few Metroids to kill before you reach Mother Brain, and they must all die
in order to continue to Mother Brain. Read the boss guide for more details.
Once Mother Brain is defeated, you will need to hurry back to your ship. By
now you will already have the HYPER BEAM. From Mother Brain’s room, go west
and then south. Take the blue door at the bottom and speed dash east. Super
jump up, and continue north. Once you land up top and are running east, aim
diagonally down to the right and shoot an unseen door. Eventually, you will
get to this door since lava will start to rise from the floor in this area.
Speed dash through the door you preopened, and charge for a super jump. Hug
either the left or right wall in the Craterian shaft and super jump up. Now
quickly get to your ship before the planet explodes. There should be almost
a minute left on the timer. Sit back and watch the ending! Did you beat the
game within 1 hour and 20 minutes?
and so they wisely de cided to word smith the en -
tire 28-page guide so that every line w as exactly
the same length, with no extra spaces or other
cheat ing, just because it could be done. [9]
Doing this man u ally is a chore, and I do like to au -
tomate the chores of Speedrun ners. [10] I got this
work ing in an after noon. It’s, like, easy mode. For
a para graph of text and a tar get line length, I ask
the LLM to remem ber the para graph and recite it.
The prompt looks like this:
 Exercise in rephrasing text. The following para-
graph needs to be rephrased so that it retains its
precise meaning, but with minor variations in the
specific choice of words, punctuation, and so on.
No new facts should be introduced or removed,
but it is good to use synonyms and change the
word order and phrasing.
After this I insert some thing like Orig i nal text: fol-
low ed by the orig inal para graph, then Rephrased
text: . The model is ready to gen erate tokens.
I then sam ple text a word at a time to con tinue this
prompt. If a line ends exactly on the num ber of
char acters that I w ant (and the next char acter is a
space or other char acter that is ap pro pri ate to end
a line) then I accept the stream so far and con tinue.
If I exceed the line length, I back up to the state at
the begin ning of the line and try again with new
ran dom sam ples. I just keep do ing that un til the
para graph is com plete, and w e hav e beau tifully
justified mono space text that resem bles the orig i-
nal. Here is an exam ple of this para graph ren dered
in mono space:
I sample text a word at a time to continue
this prompt. If a line ends exactly on the
number of characters I want, I accept that
text so far, and continue. If I exceed the
line length, I back up to the beginning of
the line and try again with new samples. I
keep repeating this until I get text I can
render in monospaced font, and that is how
we can get beautifully justified monospace
text. Here is an example of this paragraph
rendered in monospace:
You could ar gue that this is im prov ed, even, by
mak ing the text shorter. It does use “mono space”
and “mono spaced” incon sistently. The most up -
set ting thing here is that it ends with a colon like
there’s go ing to be an other exam ple of the para -
graph, but that’s what I asked it to do.
The ap proach de scribed works rea son ably w ell,
but it has sev eral de ficien cies (such as: it only took
an after noon) that w e’ll ad dress for the real BoVeX
sys tem. But it is a good exam ple to explain some
con cepts that will be use ful later.
¿Como te LLama?
Llama is Facebook’s Large Lan guage
Model, [11] which they nicely share with any one
who agrees not to use it to de stroy the world.
Wouldn’t it be funny if the world is de stroy ed by
some thing called “Llama”? That’s some Stay-Puft
Marsh mal low Man stuff. Actu ally I hear that lla-
mas are pretty mean, and if you are think ing
about hug ging a cute long-neck, you are prob a-
bly think ing about an alpaca. But that’s prob ably
a version of the lin ear algebra pack age LAPACK.
Llama-v2-70b is a good LLM which can do some
im pres siv e things, but when I say de stroy the
world I mean stuff like filling the inter net with in-
finite spam, or build ing crit ical infra struc ture on
it in or der to cut costs, where most of our “safety”
mea sures con sist of ask ing the model po litely to
recite its daily affirma tions before per form ing its
tasks. That kind of thing. It’ll be at least months be-
fore w e really hav e to worry.
Any w ay, the nor mal w ay to pro gram with Llama
is to use Python, and a moun tain of things that you
are not sup posed to un der stand and can not un der -
stand, mostly by past ing exam ples from oth ers and
then tw eak ing pa ra me ters and prompts. I don’t
care for it. For tu nately, hu man geniuses [12] hav e im -
ple mented the inference code for llama-like mod els
in a nice, portable C++ library called “llama.cpp”
(checks out).
With llama.cpp, I can load a quan tized version of
the model into RAM. Actu ally there are two dif -
ferent mod els, the 7b and the 70b, referring to the
num ber of billions of pa ra me ters, which must be a
mul tiple of VII “for per for mance rea sons.” The pa -
ra me ters are the w eights on the lay ers of the net -
work. At na tiv e 16-bit floats, the 70b model will fit
in about 130 GB of RAM, just slightly more than
a nice round 128 GB, mak ing one won der what
per for mance rea sons they had in mind. But any -
w ay, ear lier this year I (phys ically) broke my com -
puter try ing to put the world’s (phys ically) largest
video card into it, the GeForce 4090, and so I en -
dow ed the replace ment com puter with 256 GB of
RAM. If you are ever look ing at spec ifications for a
high-end desk top com puter, by the w ay, and won -
der ing “who the heck buys these things and what
do they do with them?” one an sw er is “me,” and
the other an sw er is “this.”
Quan tiza tion means us ing few er bits to rep resent
the float ing point w eights. [13] This sav es mem ory,
but it also speeds up inference, which needs to
read pretty much the en tire model for every pre -
dicted token. I got rea son able qual ity and good
per for mance from LLama-v2-7b with 16-bit floats.
This one fits com pletely on my world’s (phys ically)
largest GPU. In or der to tune various set tings, I
ran thou sands of tri als for the dif ferent mod els,
and made some nice cus tom graphs:

Tun ing results for Llama-v2-7b with 16-bit floats.
The x axis is the num ber of CPU threads and the
y axis is the num ber of model lay ers that hav e
been loaded onto the GPU. As expected, increas -
ing the num ber of threads and lay ers on the GPU
im prov es per for mance, since this whole model
fits on the GPU. For the 70b mod els (not pic tured)
there is an abrupt drop-off in through put before
w e load all the lay ers, and also my com puter gets
very slug gish if I exceed the GPU mem ory. We see
that if w e use more than the num ber of phys ical
cores (32) w e do not see any ben efit, which is not
sur pris ing because hy per thread ing ba sically nev er
helps any thing. The best through put actu ally uses
a mod est num ber of cores (about 12). Mostly I’m
just includ ing the graph to demon strate that Bo-
VeX has sup port for includ ing PNG files.
Where w as I? Right. Fun da men tally, LLMs are
trained to pre dict a token (like a word or part of a
word) giv en some sequence of tokens that pre cedes
them. There’s a fixed set of tokens for the model,
and rather than pre dict a sin gle token, they actu -
ally giv e a score for every pos sible token. These
scores are typ ically nor mal ized into a prob ability
dis tri bu tion. So for exam ple if w e hav e the text
SIGBOVIK is an
then the prob ability dis tri bu tion (Llama-v2-70b)
begins as
( annual) 69.8010%
( April) 3.8023%
( ac) 3.2456%
( academic) 2.9374%
( artificial) 2.0857%
( open) 1.7993%
( under) 1.2331%
( international) 1.1032%
...
with the thou sands of other tokens follow ing. So
three-quarters of the time the next token should
be " annual" but there are many other rea son able
pos sibilities. We can pick one of these tokens how -
ever w e like, ap pend it to the sequence, and run
the model again. This giv es us a new prob ability
dis tri bu tion. By do ing this ov er and ov er w e can
gen erate a likely piece of text. This is what Lorem
Ep som means when he says “Gen erativ e AI.”
Rather, what he means is “the new thing that is
cool,” but what he is un know ingly referring to is
that you can sam ple a prob ability dis tri bu tion. He
has prob ably nev er even read the wikipedia ar ticle
on Markov chains.
If I alw ays sam ple the most likely token, I alw ays
get the most likely text. It is good to be likely; this
is why the model is use ful. How ever, you might
not w ant exactly the same result each time, and in
many situ ations if you only sam ple the most likely
token, you get very bor ing, repet itiv e text. Pseudo -
ran dom num ber gen eration is the spice of life!
We also need not use the prob ability dis tri bu tion
to sam ple at all. We can just pick the token that w e
w ant. This is how the ini tial “prompt” works; w e
just run the inference process one token at a time
but alw ays select the next token in the prompt, ig-
nor ing the prob abilities. So at each mo ment, the
text w e’ve gen erated so far (more or less) com -
pletely char acter izes the state of the LLM. This
means that w e can eas ily go back to ear lier mo -
ments and sam ple a dif ferent con tin u ation of the
text, by just replay ing tokens. We also hav e the op -
tion of stor ing the LLM state (giga bytes) in RAM,
which allows us to return to a pre vious state in
con stant time.
For gen erat ing mono spaced lines of the same
length, I use a prompt that asks the model to
rephrase the input para graph. Here, greed ily sam -
pling the dis tri bu tion typ ically results in a copy
of the input para graph, which is fine for our pur -
poses. (If the lines already hap pen to be the right
length, w e need not change them!) But when a line
comes out the wrong length, I w ant to try again. So
I sav e the model state when ever I begin a line. To
pro duce a vari ant of the line, I sam ple tokens pro -
por tional to the prob ability dis tri bu tion. When the
set of prob able lines is small (this is com mon), the
process will keep gen erat ing the same lines and
failing because they are not the right length. To pre -
vent bore dom, when ever the process repeats a line
that’s already been seen, I increase the “tem per a-
ture” mod ifier to the prob ability dis tri bu tion. This
is an expo nen tial factor that (when higher ) flat tens
out the prob ability dis tri bu tion, mak ing pre viously
un likely tokens more likely. You can think of this
like the model get ting a little hot-headed as it frus -
trat edly does the same thing ov er and ov er. This
causes the can di date lines to be more varied, but
less prob able (accord ing to the orig inal prob ability
dis tri bu tion). I can reset the tem per ature when it
suc ceeds, since w e pre fer to hav e more likely lines.
This is all there is to the monospac ing version. It’s
just 300 lines of code, includ ing boil erplate and
commented-out de bug ging code and false starts.
Great !! You fulfiled your mission. It will revive
peace in space. But,it may be invaded by the
other Metroid. Pray for a true peace in space!
Now, look ing at the out put text, w e feel sat isfied
that every thing lines up exactly. How ever, w e can’t
help but feel un sat isfied at the same time: Now
w e’re look ing at a mono spaced font. Good for pro -
gram ming. Bad for pub lish ing. Can w e instead
hav e excellent justified text with all the perks of
pro por tional fonts and a pro gram ma ble doc u ment
prepa ra tion sys tem? And can w e hav e it by the es-
timated SIGBOVIK dead line so that it can be used
to pre pare the pa per that I’m now writ ing? Maybe!
This is the Don ald Knuth Any% speedrun.
The boxes-and-glue al go rithm
When justifying mono spaced text, it looks quite
bad [14] to insert more than one space betw een
words, so w e hav e a sim ple w ay to tell if text is
suit able for some width. We just add up the code -
points. For the full-on ty pog ra phy case with pro -
por tional fonts, there are many more de grees of
free dom. For one thing, it looks fine to expand or
con tract the space betw een words a little bit, even
if it varies from line to line. It is also pos sible to
make fine ad just ments in letter spac ing (kern ing)
to squeeze or air out text. We can also hy phen ate
words.
Around the time I w as being born, and prob ably
being very up set about it, Knuth w as hav ing sim -
ilar feelings about the w ay his computer-typeset
doc u ments looked. He dis cov ered a nice ab strac -
tion that gen eralizes most of these ty po graphic de -
grees of free dom, and de vised an algo rithm for
pro duc ing op timal text lay out giv en some pa ra -
me ters. [15] The idea is to con sider the text of a para -
graph as con sist ing of rigid “boxes” (say, words)
and stretchy “glue” (say, space) betw een them.
Both boxes and glue hav e various de tail (and can
be extended to sup port all sorts of quirks) but the
ba sic algo rithm can be un der stood with just those
pieces. So, let’s do that.
Knuth’s pa per (as usual) is great, but I started hav -
ing spoiler feelings when read ing it, so I figured
out my own algo rithm, which is more fun than
read ing. No doubt the key insight is the same:
Although there are expo nen tially many pos si-
ble break points, you do not need to try them all.
When ever w e break after a word, the prob lem is
now the same for the rest of the text (fit the rest of
the text op timally onto lines, start ing at the begin -
ning of a line) no mat ter how w e got there. This
lends itself to a dy namic pro gram ming algo rithm.
Dy namic pro gram ming is a pro gram ming tech -
nique for white board inter view prob lems at tech
com pa nies. I found it mys terious when I w as
young, per haps because of its strange name. Here
is how I think about it. Imag ine you hav e a recur -
siv e pro cedure that solv es the prob lem. In this
case, the pseudocode is some thing like
pair<int, string> Split(string line,
string text) {
if (text.empty()) return {0, ""};
auto [word, rest] = GetFirstWord(text);
// try splitting
auto [penalty1, rest1] = Split(word, rest);
penalty1 += badness from leftover space;
// try not splitting
auto [penalty2, rest2] =
Split(line + " " + word, rest);
penalty2 += badness from line too long;
if (penalty1 < penalty2) {
return {penalty1, word + "\n" + rest1};
} else {
return {penalty2, word + " " + rest2};
}
}
Split takes the line so far and the text that re-
mains to be split. In the nor mal case that there is a
word left, it will try two pos sibilities: Either split -
ting after the first word, or not split ting. This is ex-
po nen tial time because each call makes two recur -
siv e calls, to try each of the two op tions. But deep
recur siv e calls will be made with the same ar gu -
ments many times. So, add some mem oiza tion: If
the func tion is called for the same line and text a
second time, just return the same an sw er as before
with out do ing any work (espe cially not mak ing re-
cur siv e calls again). This lim its the func tion to be
called at most once for each pos sible ar gu ment; w e
can then see that line is no longer than the input
(so it is size O(n)) and text is alw ays some suf fix
of the input (so it is size O(n)), giv ing O(n 2) calls.
Dy namic pro gram ming is just mem oiza tion
inside-out: We create the values for all the recur -
siv e calls before w e will need them, store them in a
ta ble, and then look them up. For this prob lem, the
ta ble is indexed by the two pa ra me ters, the cur rent
line and the remain ing text. Note that these two
can be rep resented as integers. The line is just the
num ber of words before the cur rent word that are
included on the line, and the text is just the po si-
tion in the string where w e’ll next look for a word.
That’s all there is to it; the base cases of empty text
are used to start the ta ble, and then you just write
the loop to fill out cells in the right or der.
Knuth’s boxes-and-glue algo rithm con tains many
exten sions, and so does mine. For exam ple, later
w e’ll talk about how you can adapt the algo rithm
to per form hy phen ation and kern ing. There are
many rab bit holes to go down, and I explored the
ones that at tracted my at ten tion. There is plenty
of time to add more features later, since of course
I hav e now cursed my self to use BoVeX for my fu -
ture SIGBOVIK pa pers.
But here’s where I di verge from Knuth some what.
Knuth w as reluc tant to add a pro gram ming lan -
guage to TeX,[16] but I spent the ma jority of my
time on this project im ple ment ing a full-fledged
lan guage. BoVeX is about 33,000 lines of code, the
ma jority of which is the im ple men ta tion of the
lan guage itself. That’s 110× as long as the orig inal
mono space proof of con cept, and 30× the length of
this doc u ment!
The BoVeX lan guage
This section de scribes the BoVeX pro gram ming lan -
guage and its im ple men ta tion. If you are just in it
for the jokes, you can skip this section, which is ba -
sically serious and loaded with pro gram ming lan -
guage the ory jargon.
BoVeX is a typed func tional pro gram ming lan -
guage in the ML fam ily. Its syn tax closely resem -
bles Stan dard ML. Here’s an exam ple piece of code
from the source code of this doc u ment:
datatype (a) option = SOME of a | NONE
fun consume-outer-span f s =
case layoutcase s of
Node (SPAN, attrs, children) =>
let
val (ropt, rchildren) =
case children of
one :: nil => consume-outer-span f one
| _ => (NONE, layout-concat children)
in
case (f attrs, ropt) of
(NONE, _) => (ropt, span attrs rchildren)
| (SOME vouter, inner as SOME _) =>
(inner, rchildren)
| (outer, NONE) => (outer, rchildren)
end
| _ => (NONE, s)
You don’t need to un der stand it. I just w ant to
show you that it is a full-fledged pro gram ming
lan guage. It sup ports higher or der func tions, poly -
mor phism, algebraic datatypes, pat tern match ing,
Hindley-Milner type inference, and so on. It is ba si-
cally core (no mod ules) Stan dard ML, [17] although
I left out some w arts (op erator ov erload ing, eq-
types, ab stype, non-uniform datatypes and poly -
mor phic recur sion) and added some new w arts.
For exam ple, as allow pat terns on both sides, since
Stan dard ML has alw ays seemed back w ards to
me and it works per fectly fine to just make it sym -
met ric. Any w ay, a full de scrip tion of the lan guage
would be bor ing and take too much time as the
SIGBOVIK dead line draws closer.
Im ple men ta tion
I hav e im ple mented many sim ilar lan guages in
the past, includ ing for my dis ser ta tion. [18] It would
hav e been expe di ent to start from one of my exist-
ing im ple men ta tions, but they are mostly writ ten
in Stan dard ML and I couldn’t get MLton to work
on my Windows com puter in 2024. So I started
ov er from scratch in C++, which at least does work
on my com puter. (I also w ant to be able to inter -
face with GPU inference code for run ning the
LLM, which will be eas iest from C++). C++ is not a
good lan guage for writ ing lan guage im ple men ta -
tions, but it has got ten bet ter.
The BoVeX im ple men ta tion is a “com piler”
in the sense that it trans forms the source lan -
guage through mul tiple inter me di ate lan guages
into a low-lev el byte code. This byte code is just
straight-line code on an ab stract ma chine with infi-
nite reg isters and op erations like al loc (allocate a
new “ob ject”) and set field (set a fixed field of the
“ob ject” to a value from a reg ister ). It does not pro -
duce ma chine code, and although this would be
pretty feasible, it would not be the first thing to do
to make BoVeX faster.
First it con cate nates the source files (han dling im-
port and keep ing track of where each byte orig i-
nated, for error mes sages) and lexes them into to-
kens. Then it parses those tokens into the Exter -
nal Lan guage (EL), which is just the BoVeX gram -
mar with a few pieces of syn tac tic sugar com piled
aw ay. It does syn tac tic trans for ma tions on the EL
AST to remov e some cur ry ing syn tax and trans -
form nullary datatypes (nil becomes nil of unit ).
Then it elab orates EL into a sim pler and more ex-
plicit Inter nal Lan guage (IL). Elab ora tion does type
inference (Hindley-Milner ) includ ing poly mor phic
gen eraliza tion and so on, com piles pat tern match -
ing into an efficient series of sim pler con structs,
and de com poses heavy w eight stuff (e.g. datatype )
into its con stituent type-theoretic pieces (e.g. a poly -
mor phic recur siv e sum). The IL is nice and clean,
so it is a good place to per form op timiza tions. I
lov e writ ing op timiza tions but I had to keep my -
self out of there, or else this would be a 2025 SIG-
BOVIK pa per. There are just enough to make the
code rea son able to de bug if I need to look at it. Af-
ter op timiza tion, I per form closure con version,
sim plify again, and gen erate the final “byte code”
form. This en tire process hap pens when ever you
gen erate a BoVeX doc u ment; the only out put from
run ning bovex.exe is the PDF doc u ment.
I w ant you to know that I did not cut cor ners on
the lan guage im ple men ta tion. For exam ple, com pil -
ing mutually-recusiv e poly mor phic func tions is re-
ally obnox ious (AFAIK it requires either monomor -
phiza tion or first-class poly mor phism when you
do closure con version) but I did do it, even though
none of the BoVeX code I used for this pa per ever
needed this feature. Follow ing are some of the im -
ple men ta tion de tails; for the full story you’ ll need
to check the source code. [19]
AST pools . One of the main things I need to do is
create tree-structured data to rep resent the ab stract
syn tax tree of the various lan guages involv ed.
This is very nice in ML (it is what the datatype de -
clara tion is for ) and an noy ing in C++. I con tin ued
to exper iment with dif ferent w ays to do this. I use
arena-sty le allocation for the syn tax nodes (alw ays
const after creation), so that they can be created
and reused at will. My cur rent favorite ap proach to
ma nip u lat ing the nodes is to write “in” and “out”
func tions (tedious, man ual) for each con struct in
the lan guage. The syn tax nodes can then be im ple -
mented how ever I like (for exam ple, a flat struct
or std::variant<> ) with the free dom to change. I
get the compiler ’s help when ever I change the lan -
guage (which is often!) since each in/out func tion
is explicit about its con stituents.
Passes and guesses . Many trans for ma tions in a
com piler rewrite a lan guage to itself; for exam ple
each IL op timiza tion is a func tion from IL to IL.
These can be tedious to write and up date, espe -
cially since a giv en op timiza tion usu ally only cares
about one or two con structs in the lan guage. I use
the “pass” id iom to write these. This is ba sically an
iden tity func tion on the AST that pulls apart each
node, calls a vir tual func tion for that node, and
then rebuilds the node. To write a pass that only
cares about one type of node, you inherit from this
class and then just ov erride that one node’s func -
tion. One issue with this is that each time you re-
build the en tire tree you create a lot of un nec es-
sary node copies. So exchang ing tedium (mine)
for efficiency (my computer ’s?), every node type’s
“in” func tion also takes a “guess” node pointer. If
the node being con structed is exactly equal to the
guess, then w e return the guess and avoid creat ing a
copy. Then the base pass is actu ally the iden tity (it
returns the same pointer ) and does no long-liv ed
allocations. This seems to be a good com pro mise
betw een the tra di tional garbage-fountain ap proach
and hash con sing, which sounds like it would be
a good idea but is usu ally just a lot slow er. [20] For
type-directed trans for ma tions, there is also a typed
IL pass class, which recur siv ely passes a con text
and does bidi rectional type check ing of the inter me -
di ate code. Clo sure con version is a type-directed
pass and is im ple mented this w ay.
Pars ing . I hav e this av ersion to parser gen erators,
prob ably because one time I tried to get some one
else’s code to com pile and it com plained about hav -
ing the wrong bovines on my com puter and ru ined
my w eek end. After try ing some other people’s C++
pars ing libraries and being dis ap pointed by them,
I did what Knuth would do: I wrote my own. It is
a parser com bina tor [21] library which actu ally de -
scends di rectly from Okasaki’s SML code. [22] I w as
proud of my self for get ting this to work in C++,
since C++’s insane type sys tem is im pos sible to un -
der stand and its error mes sages are even worse.
(BoVeX’s error mes sages are extremely spar tan, of-
ten sim ply de clar ing Parse er ror at paper.bovex
line 1, but in many w ays this is more use ful than
C++’s mile-long SFINAE vom itus.) It sup ports
mutually-recursiv e parsers, res olu tion of dy namic
infix op erators, and all that. My template-heavy
parser com bina tors take clang about a minute to
com pile, which is accept able. Less accept able, but
some thing I only learned after us ing this to write
a 16–page-long pa per, is that the parsers are very
slow. Putting aside LLM inference, this pa per
takes 13 seconds to ren der into a PDF, 11 seconds
of which is pars ing! There must be some bug, but I
don’t know if it’s in my gram mar (it is easy to acci-
den tally write an expo nen tial time parser, but this
one should not be) or the parser com bina tor library
(also my fault) or clang pro duc ing bad code (it
may be giv ing up on op timiza tions, since it is tak -
ing so long to com pile; the .o file is 41 megabytes).
But these are de tails to be im prov ed in the fu ture.
Garbage col lec tion . Garbage collection is so easy,
OMG. I keep track of all the point ers that are allo-
cated dur ing execu tion. Then it is just a mat ter of
pe riod ically w alking through the stack and mark -
ing the allocations that are still reach able, then
delet ing any thing in the heap that isn’t. It’s so
easy that I didn’t even im ple ment it! I hav e 256 gi-
ga bytes of RAM. Even with a 70-billion pa ra me -
ter, 128-gigabyte LLM in RAM, there’s still plenty
of space to just keep allocat ing. In fact, LLM infer-
ence acts as a use ful “per for mance reg u lator” to
make sure that w e don’t allocate mem ory too fast.
Ob jects
As the SIGBOVIK dead line grew near, I reluc tantly
added “ob jects” to the BoVeX lan guage. Ob jects
are no stranger to ML; for exam ple the O’Caml Lan -
guage [23] (pro nounced “OK ML”) has them. [24] But
the com mu nity of func tional pro gram mers I w as
raised in has a revul sion to things Ob ject Ori ented,
just like how a wood worker will im me di ately pro -
jectile vomit if they see a piece of Ori ented Strand
Board, even though it is a fine tool for many ap pli -
cations. I still hav e this dis gust reflex. I imag ine my
Ph.D. ad visors, should they read this, are con tem -
plat ing whether and how a Ph.D. can be revoked.
Any w ay, I de liberately kept objects low-tech so
that noth ing could get too Ori ented.
There is one object type obj in BoVeX. A value of
this type has an ar bitrary set of named fields whose
types are known; they can only be the base types
int , float , string , bool , lay out , or obj . Fields are
dis tinct if they hav e dif ferent types. An object can
be intro duced with an expres sion like {() field1 =
exp1, field2 = exp2}, pro vided that each field’s
type can be syn the sized from the expres sion itself
(in the bidi rectional type-checking sense). Alter na -
tiv ely, the pro gram can de clare an object name O:
object O of { field1 : type1, field2 : type2 }
and then use this in an expres sion like {(O) field1
= exp1}. These object names do not hav e any
run-time mean ing; they are just a collection of field
types that are com monly used together. It giv es a
good place to doc u ment what they mean and some
op por tu nity for bet ter error mes sages, but fun da -
men tally an object is just a collection of named
data. Think like “JSON” object. It is pos sible to add
and remov e fields from objects (func tion ally) with
expres sions like exp1 with (O)field2 = exp2.
There are a few rea sons for objects in BoVeX. One
is the bib liog ra phy for mat, which con sists of de cla-
ra tions like this
val knuth1981breaking =
bib-article {(Article)
title = "Breaking paragraphs into lines",
author = "Knuth, Donald E. and Plass, Michael F.",
journal = "Software: Practice and Experience",
page-start = 1119,
page-end = 1184,
year = 1981,
month = NOVEMBER,
publisher = "Wiley Online Library",
}
where each de clares a reference made up of a
bunch of op tional fields. It is just too irritat ing to
make each one explic itly op tional, and since the
data hav e het ero geneous types, ma nip u lat ing some
string-indexed data struc ture would hav e worse
sta tic check ing and be more syn tac tically cum ber -
some. The bib liog ra phy ren der ing code case an a-
lyzes ov er the pres ence of fields to ren der cita tions
that hav e dif ferent sub sets of data.
An other use is in the lay out type. This is a prim -
itiv e type that most of a document’s text is writ -
ten in. It is a tree struc ture with op tional at trib utes
on each node, which are rep resented with an ob-
ject. For exam ple, this para graph is writ ten in the
paper.bovex source file as:
Another use is in the [tt[layout]] type.
This is a primitive type that most of a
document’s text is written in. It is a
tree structure with optional attributes
on each node, which are represented with
an object. For example, this paragraph is
written in the [tt[paper.bovex]] source
file as:
The square brack ets are used to write a lay out lit-
eral (the main body of the doc u ment is inside one
large literal). Lay out literals can also em bed expres -
sions (of type lay out) with nested square brack ets.
Here the func tion tt is ap plied to a lay out literal
that con tains text like paper.bovex . The tt func -
tion just adds the font-family at tribute with value
"Fixed er SysLight" to the lay out node. This is a
cus tom mono spaced bitmap font that I made for
this pa per us ing soft w are I wrote. It is part of th
Fixed erSys fam ily. [25] Func tions like b and it ap -
ply bold and italic text sty les, but func tions can do
any thing that you can do in a general-purpose pro -
gram ming lan guage.
Pri mops
The other thing that objects are used for is inter -
facing with the run time that is execut ing the Bo-
VeX byte code. There are about 50 dif ferent builtin
pri mops that can be used by the BoVeX pro gram.
This includes sim ple things like integer and float -
ing point ad di tion, but also heavy w eight op era-
tions like “load and reg ister this collection of True -
Type font files as a font fam ily” or “in voke the
boxes-and-glue pack ing algo rithm with these pa ra -
me ters.” The pri mops in the for mer cat egory work
nat u rally on sim ple base types, but the heavy -
w eight ones need to be able to pass com pli cated
tree-structured het ero geneous data betw een the Bo-
VeX byte code execu tor and the run time. It would
be pos sible for the run time to con sume and create
BoVeX values like tu ples and lists, but this has two
prob lems: One, many types like list are de clared as
user code (in the BoVeX stan dard library); they are
not spe cial, and w e don’t w ant to make them spe -
cial by inform ing the run time of them. Two, requir -
ing spe cific rep resen ta tions at the run time bound -
ary inhibits op timiza tion; for exam ple w e can nor -
mally an alyze the whole pro gram to flat ten data
struc tures or remov e record fields that are nev er
used. The run time typ ically uses obj to com mu ni-
cate struc tured data.
For exam ple, the internal-pack-boxes prim itiv e
runs the boxes-and-glue algo rithm. It takes some
lay out (which is expected to be a series of box
nodes, with at trib utes giv ing their size, glue prop -
erties, and so on) and con figu ra tion pa ra me ters
like the type of justification and algo rithm to use.
It returns an object with a new lay out (the boxes
grouped into lines, with new glued up widths)
as w ell as the total bad ness. Inside the BoVeX
lay out sup port code, this primop is wrapped as
pack-boxes with a na tiv e, typed inter face, so pro -
gram mers do not need to think about that im ple -
men ta tion de tail. Other ty po graphic features that
ben efit from run time sup port are im ple mented
this w ay as w ell.
Ty po graphic fea tures
BoVeX offers the pack-boxes algo rithm, which can
be used to nicely justify text. It can also be used
to dis trib ute para graphs into columns, by think -
ing of the para graphs as “words” (accept able to
break at any line, but bad to break near the start
or end of a para graph) and the columns as “lines.”
It could be used by the doc u ment au thor for other
pur poses, I guess. There are other ty po graphic fea-
tures av ailable.
Most of the lay out of the doc u ment itself is by Bo-
VeX code, which is either part of the stan dard li-
brary or part of your doc u ment, de pend ing on how
am bitious you feel. The func tion main-text parses
the doc u ment lay out into para graphs and remov es
white space that is not really part of the text. It nor -
mal izes text prop erties across those para graphs
so that they can be ma nip u lated indi vid u ally. For
each para graph it uses the built-in get-boxes to
break the words into fixed-size boxes with ap pro -
pri ate glue and hy phen ation (see the next two sec-
tions), and then uses the pack-boxes rou tine to op ti-
mize their lay out. The height of result ing lines are
mea sured, and spaced accord ing to the line spac -
ing, then packed into columns. Once their final
place ment is known, boxes become stick ers, which
are size less elements that only know their po sition
and con tents. In this w ay, the BoVeX ren der ing
pipeline is itself a bit like a com piler: It trans forms
programmer-written source lay out into for mat ted
para graphs, then into boxes of known size, then
into stick ers of known po sition. At the end, it out -
puts the doc u ment as a PDF.
Any part of the ren der ing process can report
“bad ness,” by calling the emit-badness primop.
Nom inally, bad ness is mea sured in square
points of area that is out side of its con tainer.
Worse situations—such as text ov erlap ping
other text—hav e their bad ness scaled up per the
same area of ty po graphic hor ror. Less serious
infractions—such as a little too much space be-
tw een words—hav e bad ness scaled down. You
hav e to use your heart to tell you what these scal -
ing factors should be.
Fonts
BoVeX can ren der your doc u ment in plain Times
Roman if you don’t care about any thing, or access
13 other bor ing built-in PDF fonts, or it can load
any True Type font from font files. (They do not
need to be “in stalled,” and it won’t help to install
them. You just put them in the di rectory with your
doc u ment.) It loads their kern ing ta bles and ap -
plies kern ing prop erly, by gen erat ing rigid boxes
at the sub-word lev el with un break able glue. I w as
dis ap pointed to find that most fonts include only
a few dozen kern ing pairs. They do this in or der
to “sav e space” in the font file, which is ut terly
rich com ing from some one that would try to sav e
space inside of words by squeez ing letters together!
In the cur rent font Palatino, the word “BoVeX” is
not kerned cor rectly because the rare bigraph “oV”
does not hav e a kern ing pair. I hope to im prov e
this de tail in a fu ture version (per haps for the pre -
sum ably forth com ing video version of this pa per ).
Hy phen ation
Johannes Guten berg invented the hy phen in A.D.
1455 for his Guten berg Bible, then just known as
Bible. [26] His print ing process actu ally required the
lines to all be the same length, so he had to stick
these little guys all ov er the place. His hy phens
looked like this: . Later on w e straight ened these
out and de cided w e only needed one at a time,
and today w e use them not because w e require our
lines to all be the same length, but because w e like
the cog nitiv e chal lenge of remem ber ing the begin -
ning of the word while w e mov e our eyes to the be-
gin ning of the next line while read ing.
BoVeX sup ports hy phen ation us ing the same ap -
proach as TeX: We break each word into boxes at
legal hy phen ation points, and mark these points as
sort-of-bad to break, and that if you do, you need
to insert the hy phen char acter and use a little more
space. By de fault in BoVeX, the hy phen sticks out
of the end of the line a little bit. This is actu ally a
bug but I like it.
I use the same hy phen dic tio nary as TeX, which is
clev erly rep resented as a pri or itized set of pat terns
in or der to fit com pactly in mem ory. [27] Again,
you hav e to respect Knuth and crew’s at ten tion
to de tail, although to be fair this algo rithm also
dates to a time when stor ing a spell check dic -
tio nary in a computer ’s mem ory w as de scribed
as “not feasible.” So some of this w as out of ne -
cessity. One of the nice things about the rep -
resen ta tion is that it gen eralizes to words that
w ere not in the 1974 Merriam-W ebster Pocket
Dictio nary. For exam ple it hy phen ates SIG-
BOVIK cor rectly.
The de tails really keep go ing, too. The hy phen ation
dic tio nary is stored in a file called hyph-en-us.tex .
“hyph” here of course stands for hy phens, and
“en-us” means “Eng lish (United States).” In fact it
is the stan dard lan guage code for US Eng lish in the
Small Lan guage Model called IETF BCP 47.[28] But
then w e hav e “hyph-en”, which is a plau sible hy -
phen ation of “hy phen”! You could even read it as
“hy phen us, tex”, as a request for TeX to hy phen -
ate the words in this file. This is the kind of de tail
I’m talk ing about! (There is also hyph-uk, which
for once sounds a little less dig nified than the US
accent.)
Rephras ing
And of course, BoVeX includes a facility for us ing
the LLM to rephrase text so that it ren ders more
beau tifully.
In con trast to the algo rithm I de scribed for mono -
spaced text, it is not straight for w ard to know
whether a pre fix of some text will pack neatly
with a pro por tional font. It de pends on all sorts
of con tin gen cies, like kern ing, whether w e will
split mid-word and hy phen ate, or change fonts
mid-sentence, or include an in-line im age, and so
on. Un like mono spaced text, a line of pro por tional
text ba sically nev er fits exactly (bad ness 0); w e need
to ap ply some glue to make it fit, which gen erally
has some small cost even when the text looks great.
One of the fid dliest parts of this is that w e can’t
just work with plain text, which is what the LLM
en joys best. Me too. This is because the para graph
being rephrased is some lay out value, which con -
tains some struc ture. Send ing the orig inal BoVeX
code for the para graph would maybe be pos sible
in prin ciple, although it would require very inva-
siv e changes to the com piler, and for bid den ob-
scen ities like “ev al” to run the code it gen erated,
and much bet ter error recov ery for the pre sum ably
vig or ous stream of bro ken BoVeX code gen erated
by the LLM. So I didn’t try that. Instead, I gen er-
ate a textual rep resen ta tion for the para graph to be
rephrased, and feed that to the LLM. The prompt
looks like this:
 Exercise in rephrasing text. The following para-
graph, which appears between <P> and </P>
tags, needs to be rephrased so that it retains its
precise meaning, but with minor variations in the
specific choice of words, punctuation, and so on.
No new facts should be introduced or removed,
and all the ideas from the original paragraph
should appear. However, it is good to use syn-
onyms and change the word order and phrasing.
The text contains markup as well. There are two
types: <span class="c0">text goes here</span>
and <img src="image.png">. These should be
preserved in the rephrased text. <img> tags
absolutely need to be retained and should not
change their sources, although it is permissible
to move them around in the text. <span> should
generally be retained, but the contents could
change. The classes of spans may not change,
and only the classes that appear in the original
text may be used.
The first part is ba sically the same as what I used
for the mono spaced version, except that I ask the
LLM to de limit the para graph. This is im por tant
so that I know when it thinks it’s done, and seems
to work bet ter than look ing for new lines or the
end-of-stream token. The second part is new. I trans -
late the lay out into plain text where un inter preted
sub trees are replaced with <img src="img1.png"> .
These are gen erally boxes whose con tents are not
text. This could be an actual inline im age or lay -
out used to con trol ren der ing, like some bit of hor -
izon tal space. Nodes that are used to set text prop -
erties of the sub trees with at trib utes (like fonts, col-
ors , sizes , etc.) are trans lated into dis tinct classes and
marked up with <span class="c0">...</span>
The LLM has seen plenty of HTML, so it’s able to
use these rea son ably w ell.
After gen erat ing a rephras ing, I parse the out put
HTML and match it up with the orig inal lay out.
If I find any bro ken HTML, it is rejected. If I find
any <img> tag referenc ing a src not in the orig inal,
it is rejected. If I find any <span> tag referenc ing a
class not in the orig inal, it is rejected. The more
com plex ity that the orig inal lay out has, the higher
the chance of a rejection, but rephras ing gen erally
suc ceeds. But rejecting sam ples slows us down, so I
leav e off the second part of the prompt in the com -
mon case that the input para graph is plain text.
That w ay the LLM doesn’t even try us ing markup.
With the HTML and orig inal lay out matched up,
BoVeX can recon situte the lay out with the new
rephrased text. This pre serv es any nested lay out
and at trib utes. It then con tin ues with the ren der -
ing process.
But, how do w e know whether w e hav e a good
rephras ing? When w e run the boxes-and-glue algo -
rithm, w e get a “bad ness” score for the paragraph’s
line breaks, which tells us how bad the paragraph’s
line breaks are. When w e run the rephras ing algo -
rithm, the prob ability of the text w e gen erated tells
us how seman tically good it is, and so w e can call
1 - p the seman tic loss. Com bin ing those two some -
how tells us how bad this is ov erall, and of course
w e w ant to find a rephras ing that min imizes the
ov erall bad ness.
I wish that I could tell you that I solv ed this one
with a beau tiful algo rithm! But so far I just hav e
some thing rea son able that works. I gen erate many
dif ferent rephras ings (with their seman tic loss),
and run each of them through the boxes-and-glue
algo rithm (to get the ty po graphic bad ness). I
choose the one that op timizes the pre ferred trade -
off betw een seman tic loss and ty po graphic bad -
ness. This process is con trolled by BoVeX code (i.e.
it is in the source code of this very pa per ) and so
it can be mod ified by the doc u ment au thor. Knuth
has a very low tol erance for seman tic loss, and
knows that his algo rithms pro duce good results
with out rephras ing. Lorem Ep som just w ants it to
look good and sound good. Both hav e pub lished
in SIGBOVIK 2024.
How to gen erate many dif ferent rephras ings? The
sim plest thing would be to sam ple ran domly, like
w e did for the mono spaced version. But since w e
pre fer rephras ings that max imize prob ability, it
. is bet ter to explore them sys tem at ically. Con sider
the model at the end of the prompt to be the root
of an infinite tree. Each node in the tree rep resents
an LLM state (sequence of pre vious tokens) and its
chil dren are the pos sible next tokens. Each of these
tokens has a prob ability. All the model does is al-
low us to access that prob ability dis tri bu tion for
a node. Each pos sible rephras ing is a path in this
tree that ends with </P>. We begin by sam pling the
most likely (as far as w e know) path: At each node
w e see, w e take the first (most prob able) token.
This is our first rephras ing, and it usu ally matches
the orig inal text exactly. Say that w e “skipped”
prob ability mass if w e sam pled a token that is less
prob able than it. We com pute the seman tic loss as
the av erage prob ability mass skipped ov er all the
tokens in the path. For this first path, w e alw ays
took the most prob able token, so this is 0.0 by de -
finition.
The next path w e explore will di verge from this
path at some node (maybe the root). We pick a
node that is likely to result in a good final loss, by
scor ing each node in the tree. The score is the av er-
age prob ability of all an cestor nodes times the prob -
ability of the next highest-probability token that
w e hav e not yet explored. The node with the high -
est ov erall score is the one w e expand, by choos ing
that next highest-probability token. We are now in
an un explored part of the tree, and so w e sam ple
the most prob able nodes repeat edly un til w e reach
</P>. Speak ing of which, BoVeX has a heck of a
time try ing to rephrase these last few para graphs
because they literally con tain the text </P> in them.
The scores should be seen as heuris tic; w e would
get dif ferent results by choos ing dif ferent w ays
of com put ing the score. This is an exam ple of a
“beam search” algo rithm, which is good because
it con nects this project again to Super Metroid. As
de scribed in the ear lier excerpt from the speedrun
doc u ment that inspired this work, one of the final
things you do in that game is acquire the “hy per
beam” to de feat Mother Brain.
Since w e will run the boxes and glue algo rithm
on mul tiple related texts, I gen eralized that algo -
rithm to work on tree-structured input. This is
clean; the memo ta ble keeps the same di men sions,
but records an ad di tional fact. Now w e store the
penalty, whether to break after this token, and
what the best sub tree is. We hav e to con sult each
sub tree when com put ing the score for a node, but
this does not affect the asymp totic run time. The ta -
ble size is still at most O(n 2), and although w e ex-
plore more chil dren per node, branches in the tree
reduce the max imum depth to the root, which ac-
tu ally reduces one of the factors of n to log( n) as
the tree becomes com plete. How ever, as the SIG-
BOVIK dead line crept upon us, I nev er actu ally
hooked this func tion ality up. It would require ad -
di tional (pro gram ming) work to merge the trees,
and the lay out process is so fast that it doesn’t mat -
ter; I can eas ily run the full lay out algo rithm on
hun dreds of rephras ings per para graph.
I would like to im prov e the algo rithm, because it
does seem like there should be a w ay to integrate
the boxes-and-glue dy namic pro gram ming algo -
rithm with the path exten sion algo rithm so that
w e pri or itize explor ing nodes that are likely to gen -
erate the best bal ance of ty po graphic and seman -
tic qual ity. It won’t be as sat isfyingly op timal as
boxes-and-glue itself because w e hav e incom plete
infor ma tion (w e nev er know whether one of the
expo nen tially many paths starts out with im prob -
able tokens but then ends with a mir acle streak of
prob able tokens). But it can certainly be more sat -
sifying. Knuth would not stop here (but this is an
Any% Knuth speedrun).
Instead I spent my time im ple ment ing an achiev e-
ment sys tem in BoVeX. The first time certain con di -
tions are met, the sys tem per ma nently aw ards you
an achiev ement and prints a nice color tro phy on
your ter mi nal. For exam ple, you can get the “Not
bad” achiev ement for gen erat ing a doc u ment that
is at least 5 pages and has less than 1000 bad ness
per page.
Ad van tages of rephras ing
An other nice thing is that the man ual rephras ing
that con sumes valu able brain sug ars when writ ing
can become op tional. For exam ple, when I wrote
the open ing para graph of this pa per and listed a
variety of triv ial de tails, I might not need to think
of dif ferent w ays to say “un con cerned.” I could
just write “un con cerned” each time and let the ty -
po graphic con sid erations de ter mine which syn -
onym to use each time.
Con clu sion
In this paper—and with this paper—I pre sented Bo-
VeX,a new com puter type set ting sys tem. It follows
the tra di tion TeX, but with mod ern ameni ties such
as requir ing ov er 128 giga bytes of RAM. Though
some may con sider the ad di tion of AI features to
TeX to be an un nec essary per version, I find this
use of LLMs to be fully justified.
Fu ture work
Ty po graphic fea tures . Many more ty po graphic
features are de sir able. Foot notes! It is so hard to
write a pa per with out foot notes. Where am I sup -
posed to put the bonus di gres sions? The lay out
of foot notes is tricky and should be part of a gen -
eral float ing figure im ple men ta tion. End notes are
actu ally easy, but I don’t w ant end notes. I w ant
them to be little foot notes so that you can’t help
but read them.
BoVeX does not sup port page num bers, which is
good because they are for bid den by the SIGBOVIK
pro gram com mit tee.
TeX is famous for its math emat ical type set ting
as w ell. It would fit neatly into BoVeX in the
same w ay, since both use the same fun da men -
tal boxes-and-glue en gine. BoVeX does not hav e
“macros” or “modes” like TeX, but it would work
cleanly to write a BoVeX func tion math (or, if you
like, $) that parses a cus tom syn tax. In fact it would
be nat ural to hav e dif ferent parsers for dif ferent
maths, so that you don’t need to parse -> as minus
greater than in math emat ical con texts that don’t use
mi nus or greater than at all.
Op ti miza tion . There are many op por tu nities to
make BoVeX code faster. This is mostly im por tant
for when it is being run in a loop in or der to try
out many dif ferent rephrased texts. (That said, I
do not wish to pre clude what could be done with
BoVeX by assum ing its execu tion is do ing only
type set ting tasks. For exam ple, shouldn’t you be
able to chal lenge your paper ’s review ers to a game
of chess against a strong en gine em bed ded within
your doc u ment?) The first thing to fix is that it ma -
nip u lates too many strings at run time (e.g. the
code, record labels, object fields, and “reg isters”).
This is easy to fix since these are all known at com -
pile time. There are lots of high-lev el op timiza tions
left to do for the IL code (com mon subex pres sion
elim ina tion, con stant ar gu ment remov al, un cur ry -
ing, etc.) and lots of peep hole and control-flow op -
timiza tions left to do for the byte code (cur rently
no op timiza tions are per formed at all). All of this
becomes more im por tant if I add an other planned
feature, which is the abil ity for the doc u ment to
be glob ally op timized by ap ply ing a black-box op -
timizer to a set of user-specified pa ra me ters. For
exam ple, the column width, line spac ing, or font
size could be tw eaked to make the doc u ment fit
bet ter. This feature is “Auto-Margin Plus.” Things
are already set up to do this pretty straight for -
w ardly; w e would sim ply gen erate the doc u ment
ov er and ov er while search ing ov er the pa ra me ter
space, and choose the one with the least bad ness.
This may also affect which rephras ings look best.
But instead I spent my pre cious time im ple ment -
ing 3D text .[29]
3D text
Re pro ducibil ity . The algo rithm for reprhas ing
text tries to find the best place to explore the next
most likely token from the prob ability dis tri bu tion.
This expects the gen eration of these dis tri bu tions
to be de ter min istic. Math emat ically, inference is
de ter min istic (it is just a bunch of ma trix mul tipli -
cations), so this “should work.” But in prac tice the
enor mous calcu lation is per formed in an un pre -
dictable or der as it is executed in par allel (in mul -
tiple CPU and GPU cores). Because float ing point
arith metic is not associativ e (or dis trib u tiv e, com -
mu ta tiv e, or other prop erties you’ d like), inference
can some times gen erate dif ferent an sw ers due to
float ing point round-off error. [30] Alas, these are
not even nec essar ily related to the final prob abil-
ities in the model, as billions of non-linear op era-
tions hap pen within the hid den lay ers of the net -
work. The effect is not par ticu larly grav e; w e might
miss out on a highly likely path because the prob -
ability dis tri bu tion w as dif ferent the second time
w e looked at it. There are already lots of w ays w e
might fail to find highly likely paths, so this is not
some kind of repro ducibil ity crisis. It is mostly just
a bit un sat isfying.
Uni code sup port . This would hav e been help ful
when abov e I de cided to show you Gutenberg’s
funny hy phen, , for which I had to set tle for em -
bed ding a crappy hand-drawn PNG file. Instead
I could hav e used U+2E17, which since this exotic
code point it is not present in the font Palatino, you
could hav e expe rienced as . BoVeX is wit ten with
some Uni code sup port, with the main excep tion
being that the PDF out put code only sup ports the
em bar rass ingly diminu tiv e WinAn siEn cod ing. [31]
Dead lines . Although BoVeX itself is very fast,
rephras ing is very slow. This presents a prob lem
for the typ ical w ay that aca d emic pa pers are writ -
ten, which is to do all the work in a coffee-fueled
fugue in the last few days before the dead line, then
stay up all night writ ing the pa per and find ing ci-
ta tions for the pro-forma “re lated work” section
which you did last but you know that the review -
ers will insist upon, and tw eak ing \vspace and
\begin{figure}[h!] un til it fits within the page
limit. On the one hand, BoVeXdoes po ten tially free
the au thor from the visual tw eak ing process. But on
the other hand, the LLM inference for the rephras -
ing process can be quite slow, and it can take many
hours or days to fully bake a long pa per! For this
rea son, it may be bet ter to change con ference dead -
lines to a sys tem where the pre-rephrasing text is
sub mit ted. The pub lish ers (what do they even do?)
can be the ones to execute the rephras ing in the
cloud as they pro duce the “camera-ready copy.”
With straight for w ard exten sions, this would also al-
low the rephras ing to adapt to changes in the ov er-
all vol ume sty le, or to ad just to avoid em bar rass -
ing ty po graphic con cidences with other ar ticles in
the same vol ume (such as us ing the same no ta tion
with a dif ferent mean ing). In prin ciple, the pa per
could edit itself to respond to feed back from re-
view ers, in a w ay that min imizes the seman tic dis -
tance from the orig inal. This rapid feed back loop
could reduce the time to pub lication, per haps to
mere months, or even w eeks!
Other w ays to min imize bad ness . The BoVeX
sys tem allows the doc u ment au thor to exchange se-
man tic con sistency for higher qual ity ty pog ra phy.
Although w e achiev e state-of-the-art results, there
are likely points that are more Pareto-efficient
than what BoVeX can reach. BoVeX uses one of
the most pow erful pub licly av ailable LLMs, but
that model is lim ited to rewrit ing the text within
nar row con straints. Irrespon sible research has
demon strated that lan guage mod els are capa ble
of vo lition, tak ing actions and us ing tools to ac-
com plish goals. With mi nor mod ifications, it is
likely pos sible to expand the Pareto fron tier of the
semantic/typographic trade off. For exam ple, some -
times w e could im prov e the ty po graphic qual ity
of the text with out any seman tic loss, by act ing on
the world to make the reworded text true . Hu man au -
thors do this already: Ear lier when I w as de scrib -
ing internal-pack-boxes , rather than explain the
some what awk w ard im ple men ta tion, I w ent back
and changed the already-working code so that
it would serv e as a sim pler exam ple of how pri -
mops use obj , but still be truth ful. Now imag ine
the dif ficulty in type set ting a state ment like “The
uni verse con tains ap prox imately 1,000,000,000
pa per clips,” and how much more beau tiful
the text could be if that num ber w ere instead
10,000,000,000,000,000,000,000,000,000,000,000,000!
In the mean time there is an eas ier w ay to get zero
bad ness: Delete the whole doc u ment! As a wise
per son once said, “If you can’t say some thing with
nonzero ty po graphic or seman tic loss, don’t say
any thing at all.”
Acknow ledge ments . Sup pos ing his name sur -
viv es rephras ing, I’d like to shout out to one of
my ad visors, Karl Crary. 20 years ago, he set out
with me on an ill-advised and ill-fated at tempt to
replace LaTeX with an SML-like lan guage mT eX,
which com piled into TeX macros. The nest ing
square brack ets syn tax w as Karl’s idea, and BoVeX
shares genetic ma terial with mT eX for sure.
See you next mis sion,
Tom 7
Bib li og ra phy
[31] Adobe . "PDF reference: Sixth edi tion ". Octo-
ber 2006.
[7] You can just go to arxiv.org and click on any
ran dom ar ticle these days .
[16] N Bijlage . "Knuth meets NTG mem bers ". NTG:
MAPS , 16. March 1996. pp. 38–49.
[3] Russ Bynum . "Bernie Sanders w ants the US to
adopt a 32-hour work w eek. Could work ers and
com pa nies ben efit?". March 2024.
[12] https: / / github.com / ggerganov / llama.cpp . gger -
anov . March 2024.
[26] Johann Guten berg . "Bible". 1455.
[4] https: / / allfamousbirthday.com / donald-knuth / .
Febru ary 2024.
[23] https: / / ocaml.org . "The Ob jectiv e Caml sys -
tem ". 2023.
[21] Gra ham Hut ton . "Higher-order func tions for
pars ing ". Journal of functional programming, 2(3).
1992. pp. 323–343.
[5] Don ald E Knuth . "The Art of Com puter Pro -
gram ming: Volume 4A, Com bina torial Algo rithms
Part 1". Addison-Wesley. Janu ary 2011. 912 pages .
[6] Don ald E Knuth . "The Art of Com puter Pro -
gram ming: Volume 4B, Com bina torial Algo rithms
Part 2". Addison-Wesley. October 2022. 736 pages .
[15] Don ald E Knuth, Michael F Plass . "Break ing
para graphs into lines ". Software: Practice and Experi-
ence, 11(11). No vem ber 1981. pp. 1119–1184.
[27] Franklin Mark Liang . "Word Hy-phen-a-tion
by Com-put-er ". 1983.
[17] Robin Milner, Mads Tofte, Robert Harper,
David Mac Queen . "The de finition of Stan dard ML
(Revised) ". MIT Press. May 1997. 114 pages .
[8] John C Mitchell . "Type Systems for Pro gram -
ming Lan guages ". Van Leeuw en, Jan, ed . Formal
Models and Semantics. 1990. pp. 365–458.
[1] Tom Mur phy VII. "Bad ness 0 (Epsom's version) ".
SIGBOVIK. April 2024. 14 pages .
[30] Tom Mur phy VII. "GradIEEEnt half de cent ".
SIGBOVIK. March 2023. pp. 33–56.
[18] Tom Mur phy VII. "Modal Types for Mo bile
Code ". Janu ary 2008.
[13] Tom Mur phy VII. "NaN gates and flip FLOPS".
SIGBOVIK. April 2019.
[10] Tom Mur phy VII. "The First Level of Super
Mario Bros. is Easy with Lexicographic Or der ings
and Time Trav el. After that it gets a little tricky ".
SIGBOVIK. April 2013. pp. 112–133.
[20] Tom Mur phy VII. "The Wizard of TILT: Effi-
cient(?), Con venient and Abstract Type Rep resen ta -
tions ". Carnegie Mellon tech report CMU-CS-02-120 .
March 2002.
[29] Tom Mur phy VII. "The glEnd() of Zelda ". SIG-
BOVIK. April 2016. pp. 105–112.
[14] Tom Mur phy VII. "ZM~~ # PRinty# C with
ABC!". SIGBOVIK. April 2017. pp. 129–148.
Fu, Brian Fuller, Cyn thia Gao, Vedanuj Gosw ami,
Na man Goy al, An thony Hartshorn, Saghar Hos -
seini, Rui Hou, Hakan Inan, Marcin Kar das, Viktor
Kerkez, Ma dian Khabsa, Isabel Kloumann, Artem
Korenev, Punit Singh Koura, Marie-Anne Lachaux,
Thibaut Lavril, Jeny a Lee, Diana Liskovich, Ying -
hai Lu, Yun ing Mao, Xavier Mar tinet, Todor Mi-
hay lov, Pushkar Mishra, Igor Moly bog, Yixin
Nie, An drew Poul ton, Jeremy Reizen stein, Rashi
Rungta, Kaly an Saladi, Alan Schelten, Ruan Silva,
Eric Michael Smith, Ran jan Sub ra man ian, Xiao -
qing Ellen Tan, Binh Tang, Ross Taylor, Ad ina
Williams, Jian Xiang Kuan, Puxin Xu, Zheng Yan,
Iliyan Zarov, Yuchen Zhang, An gela Fan, Melanie
Kam badur, Sha ran Narang, Aurelien Rodriguez,
Robert Stojnic, Sergey Edunov, Thomas Scialom .
"Llama 2: Open foun da tion and fine-tuned chat
mod els". ArXiv.org. July 2023.

[25] http: / / tom7.org / fixed ersys / . Tom Mur phy VII.

"The Fixed erSys font fam ily". 2024.

[2] https: / / en.wikipedia.org / wiki /

Wikipedia:W ikiProject_Punctuation . Tom Mur phy
VII. "WikiPro ject Punc tu ation ". July 2007.

[19] https: / / sourceforge.net / p / tom7misc / svn / HEAD /

tree / trunk / rephrase / . Tom Mur phy VII. "BoVeX
source code ". 2024.

[22] Chris Okasaki . "Even higher-order func tions

for pars ing or Why would any one ever w ant to
use a sixth-order func tion? ". Journal of Functional
Programming, 8(2). March 1998. pp. 195–199.

[28] A Phillips, M Davis . "Tags for iden tifying lan -

guages ". Sep tem ber 2009.

[9] https: / / gamefaqs.gamespot.com / snes /

588741-super-metroid / faqs / 10114. rs1n . "Super
Metroid Speed Guide and FAQ". 1996.

[24] Didier Rémy, Jérôme Vouil lon . "Ob jectiv e ML:

An effectiv e object-oriented exten sion to ML". In
Theory And Practice of Objects Systems, 4(1). 1998.
pp. 27–50.

[11] Hugo Tou vron, Louis Mar tin, Kevin Stone, Pe-
ter Albert, Am jad Alma hairi, Yasmine Babaei, Niko -
lay Bash lykov, Soumy a Batra, Pra jjwal Bhar gav a,
Shruti Bhos ale, Dan Bikel, Lukas Blecher, Cris t-
ian Can ton Ferrer, Moy a Chen, Guillem Cu cu rull,
David Esiobu, Jude Fernan des, Jeremy Fu, Wenyin