Hacker News Reader

Comment by roughly | Hacker News Reader

That’s incredible. I’m always impressed with the utility of the TrueType/open font spec - the flexibility there is really an underappreciated work of engineering genius.

View on HN

Arguably one of those cases where the capability is awesome, but using the capability is wat.

https://www.destroyallsoftware.com/talks/wat

I mean, fonts are Turing-complete [0], so it isn’t surprising that this is possible. Turing-completeness is often by accident rather than by genius [1].

[0] https://litherum.blogspot.com/2019/03/addition-font.html

[1] https://en.wikipedia.org/wiki/Turing_completeness#Unintentio...

Which makes sense, because human language is apparently Turing complete, so anything intended to represent it faithfully would wind up with that characteristic, too.

Human language isn’t a formal language, so this is a category error.

In the present context, an example is that the common reading of a Kanji word isn’t always well-defined, and neither is the decomposition of a sequence of Kanji characters into words.

It's often used as one, though.

No, it’s not? https://en.wikipedia.org/wiki/Formal_language#Definition

It's an interesting move to point me to a rigorously written English language definition of a formal language to make the argument that humans don't co-opt our natural languages as formal languages when the need arises.

That’s not what “formal language” means. English being used to describe a formal definition doesn’t make it a formal language.

I didn’t say it was a formal language, I said humans co-opt it as one.

Bitmap fonts aren't turing complete. The fact that TrueType is built with an arbitrary virtual machine is insane, makes implementations ridiculously complex, and is a huge security liability. The purpose of the VM wasn't to "represent human language faithfully" but to make fonts look a little better when displayed at a variety of resolutions, via hinting. Hinting doesn't necessarily require a full VM, but somebody let the engineers have a little too much fun.

And yet, actually mapping all written human languages and their ligatures, variations, etc, seems to require this level of complexity. So the choice is either you draw the line and decide which languages you consider legitimate or not, or you build a machine of sufficient complexity to capture all languages, and the tradeoff, I suppose, is how much knowledge you want to actually be able to capture in your computerized system.

Unicode is distinct from, and completely unrelated to, TrueType. Unicode does not require a virtual machine to interpret. You can simply express languages and their variations with Unicode + bitmap fonts.

Unless you want ligatures.

Do you really believe the only way to implement ligatures is with a virtual machine? Dumb and dirty psuedocode written in 5 seconds of thinking about it but come on, this is not that complicated.

  for each character in text
    characterToPrint = Parse(character)
    if character is LigatureStartCandidate
      characterToPrint = LookAheadForNextLigatureCandidateAndResolve(character)
    Print(characterToPrint)

And you've now gotten 92% of the way there. Iterate a few dozen more times to get up to 97%, 98%, 99%, etc., and eventually you'll have rewritten OpenType.

Would you like to elaborate on those few dozen more cases rather than handwaving them away? Embedding a VM into a font format is foundationally a ridiculous idea and should require real justification, although I know our industry is in love with anything that allows arbitrary code execution exploits.

I could, or you could open your mind to the idea that the reason opentype wound up being as complex as it is is because the problem space you’re trying to solve is more complicated than you think it is. There is a working reference implementation which does the thing you think can be done more cheaply, you’re just throwing popcorn from the cheap seats here.

That algorithm fails for languages as exotic as English with its three character ligatures like ffl that are used in truffle, but not in cufflink.

The real challenge is Arabic, though, see https://fontspec.org/opentype-shaping/opentype-shaping-arabi...

I went to research your examples with Google, and interestingly enough, it now thinks that it's a "classic textbook example" while citing one source — this comment of yours (20 min old at the time):

> In typography, ligatures should be used in "truffle" but should not be used in "cufflink."

> This specific pair of words is a classic textbook example used by typographers and software developers to demonstrate the limitations of basic, automated font-rendering rules.

What a world to live in.

On the same point of yours, bad two-letter ligatures also exist: surfing (fi), selfless (fl), halftime (ft), etc. "Swordfish" is fine but "dwarfish" is not.

The AI learns quick because it does not hold onto its ego.

Little VMs are really easy to sandbox if you don't need a billion instructions per second, and compared to complicated math thresholds it's easier and simpler for a VM to implement everything you need.

Reply on news.ycombinator.com