The strangely difficult problem of drawing a box around text | Hacker News Reader

The strangely difficult problem of drawing a box around text

blog.battlefy.com

83 pointspyrolistical40 comments

So I used to design graphic accelerators for Mac video cards, I made (among other things) cool hardware to speed up font rendering. While some of the stuff I did was great the font rendering was underwhelming, especially on the high end apps we were targeting ... I dug into what they were doing ....

Pagemaker - invalidated the font cache at the drop of a hat, spent all its time rebuilding it.

But Quark express was the hard one - it spent all its time multiplying (which was slowish on 680x0s) - turns out it used Adobe Type Manager (ATM) to render text and they had solved some pixel cruft problems by adding 2 spaces to the end of every string they rendered and clipping it to the desired space .... in other word they drew a box around it ... ATM solved this problem (clipping) by laying out a line (all those multiplications) and if it didn't fit it would split the line in two and try again - because of those 2 clipped spaces this resulted in N squared/2 behaviour (24 char text would do 24->12 12-> 6 6-> 3 3-> 2 1) and as a result the code spent all its time laying out the text over and over again and comparatively none actually drawing

So don't do that

It's not just restricted to CSS either.

I made an app that lets you highlight quotes on Apple devices and it was such a pain building it in Swift. Just highlighting so it would look absolutely beautiful took about a month (it was also my first time learning the language). I had to dig deep down into the way fonts worked. CGRect became my best friend.

Fun project, but there's a reason why you don't see a lot of apps replicating Medium.com's highlighting feature. I also believe it's why highlighting text on iOS devices breaks every couple of months.

It's literally built a top a mountain of chewing gum and sticks holding it together. It's a mess.

Not necessarily for a Swift project, but your experience makes me wonder about the current web API for highlighting spans of text.

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/...

Complicated...

Man that gave me flashbacks…

Ludicrously difficult. I thought there would be a library for it or something.

I should make it open-source. I spent so much time on it and it doesn’t see much use. And I’m sure a lot of programmers could use it in a project somewhere.

Seems kinda straightforward to me, especially compared to the complexity of other web APIs? It's just a couple classes and functions. What am I missing?

It's not easy to read, but web specs are always written in over complicated and overly detailed prose that might as well have been written by a lawyer.

I'm sure it's relatively easy for someone experienced with programming. I wrote the program back when I was learning Swift for the first time. There's a lot of counterintuitive shapes and graphics and knowledge you need. It's not linear algebra "difficult", but it does accumulate, until you're wondering why you're spending so much time drawing rectangles over text.

I enjoyed the project, but it was definitely rife with a lot of strange behavior layered on top of each other.

And Apple Documentation is a bit of a nightmare and basically useless in most cases.

This didn't even get into accents (I think they're called?) stacked to the moon:

L̷̛͎͈̗̜̼͚̔̋͌̈́̂i̶̗͓̹̭͉̘͒͗͗͗̿̉̑͜k̷̨̡͇̩̝̖͙̱͇͙͔̣̿̂͑̊͒̎̓̓̑ę̴̡̛͔̝͚̻͔͙̫̩͈̙̇̽́̔̆́̕͜ ̸̡̘̬͖́͒̄̂͗̑̕͘͝t̸̞͍̜͉̼͙̳̣̠̠́̉̈̊͜ḩ̵̞̪̟͙̲̤̐̓̒i̵̧̞̝̻̜̪̬̖̜̮̳̙͚̥͐͐͒͌̆̇͑́͌̒͠s̶̨͔̘̖̕

Draw a box around this. Oh, and they're called diacritic marks.

When you put stuff like this in a JS alert() it just plainly clips out of the dialog box (at least in Firefox).

Not on my system. Firefox 93.0 on Windows.

That isn't really that hard to deal with. Placing those combining characters is tricky, especially when internationalization is concerned, but once you have pixel positions the text bounds are easy to calculate given the metrics info in the font.

Then why do so many websites allow them to flow out of where they should be and cover the whole page?

I didn't want to push the limit, but I think my comment with the diacritics could have covered other people's comments or the entire page.

Careful... that's how you summon Tony the Pony.

Seems like an application where the latest and greatest machine learning + javascript bloat may actually prove useful.

I think this is more along the lines of redefining the bounds of text.

Because even in his demo, you can see where he's not encapsulating all of the text space. The comma is cut. As would be any letter with a descender. Also any letter with an ascender or capital letter with a diacritic mark.

Also, he has some space before the first "B", but not after the last "x". Why doe the first letter get leading space but the last not get an equal amount of trailing space? Or is the kerning of the letters just concerned with leading space?

Unfortunately the HTML spec hasn't yet clearly defined how TextMetrics work, so you can end up with different text alignment and measurements between browsers. See this spec issue: https://github.com/whatwg/html/issues/6731

Small caps are actually a solution to the problem of otherwise uneven proportions created by capital letters only occupying the upper half of the letters body and a good way of creating a "boxy" layout with text.

Here's an example https://jsfiddle.net/y4uk07jL/1/

If you want the box exactly like the author in the blog post (don't really know why anyone would want that?) you can do that by adjusting the line-height.

I can recommend Ellen Luptons book Thinking with type. Turns out some typographic problems was actually solved long before CSS and even computers. :)

I think that depends on the font, and is mostly not going to be true. In the handful of fonts I’m trying, upper case is correctly centred each time (eyeballed only), and small caps is very visibly unbalanced.

Yes, it is going to depend on the font. All fonts don't have real small caps meaning the browser will just scale down the normal capital letters and not appropriately adjusting them to the x-height. Choosing a font is however not just about how it looks, it's also a technical decision. If you gonna print on a certain paper your font may need ink traps, if you want your font to appear centered you want a font that supports true small caps.

I think you may be missing my point: in all the cases I’m looking at, capital letters are centred vertically, not lowercase letters like x (that being what small caps will be tuned to) as you’re suggesting; synthetic or real small caps will make no difference.

For the web, I use Capsize to eliminate the extra vertical space. It's a huge hack, but it does seem to work well across modern browsers, and it certainly makes dealing with web design layouts a lot easier.

https://seek-oss.github.io/capsize/

The default font for the link on iPadOS15 Mobile Safari has different heights for ‘d’ and ‘D’. Using a line gap of 3. I am not a font geek, so can anyone explain whether this is common?

This is primarily a recruitment ad. The poster has a uniform record of submitting similar stuff from this particular domain.

The information you're after to measure line heights, glyph sizes, em-height, etc. is generally in the 'head' [1] and 'OS/2' [2] tables of an OpenType font. Don't be afraid to parse these tables if you need to; it's not hard to do, even in JavaScript. (Of course, to have access to the tables in the first place you'll need to be using a webfont that you control.)

[1]: https://docs.microsoft.com/en-us/typography/opentype/spec/he...

[2]: https://docs.microsoft.com/en-us/typography/opentype/spec/os...

> it's not hard to do, even in JavaScript

But if you’re going to try to do anything fancy like this, it’s practically certainly better to do it as a build step, because otherwise you’ll be shipping extra parser code, doing extra work, and either loading the font twice or slowing down the CSS pipeline by putting JavaScript into the critical path. Also, remember that the font may not load (e.g. user preference overriding all fonts), so don’t depend on this sort of thing for fine detail unless you’ve confirmed the font is actually being used.

Demo only works in Chrome and Chromium. It’s IE all over again…

Case in point: Microsoft Teams. On Chrome it gives an option to use the web client. On Firefox it doesn't even show it as an option. For the longest time I thought that Teams didn't even have a web client.

Can't you just render text to a canvas element then crop the canvas? That results in the exact bounding dimensions you need.

Not always. In my experience there are two things that tend to break when you try to render to canvas and apply the empirically measured dimensions to HTML text: (1) subpixel rendering because it does still exist despite high DPI displays, and (2) kerning and hinting don't always give you the same metrics inside/outside canvas, especially for non-Latin characters.

The more valuable article linked from this article: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-v...

I... Actually prefer the box in the simple solution. Why is the other preferred?

It’s more about accuracy. Most designers specify an explicit spacing between the edges of the characters and other elements on the screen. If the devs can’t access those edges, then they have to adjust in order to compensate. So having accurate dimensions would reduce time to delivery.

Makes sense. I've never seen mocks that relied on this particular box.

The border box is just a visual aid. The real issue is with placement, ex: centering vertically. If you don't know the exact text bounds you will have off center text.

Ah. That makes some sense. I'm curious how often this comes up.

I had a lot of trouble wrapping my head around this years ago:

https://stackoverflow.com/questions/47538712/what-determines...

This is about CSS.

It is also about pixel-perfect madness. Please just don't. Make things that scale, make things that adjust, and tolerate end users that have different fonts and size preferences.

I don't know where you're coming from. It's not about pixel-perfect madness that I can see? It's about drawing a box? Wanting to draw a neat box around text is a reasonable thing to want to do. Know how fonts behave and being able make websites look how you want is a legit part of a designer's toolkit, I'd say. Is your problem that the designer didn't add an extra layer of pixel->some-other-unit conversion on top of everything else? (But in browser pixels are also abstract entities ('logical pixels') not related to screen pixels anymore for the most part, which are deeply hidden away and basically inaccessible last time I checked (3 or so months ago)).

But for instance, towards the end the writer says: 'The next time somebody complains about paragraphs having inconsistent spacing when the font changes, I’ll know why and how to fix it.'. So, it looks like they care about h

[ I can't check out his example on my current device, so I don't know if it's scale/custom-css compatible or not. ]

The box is just an example, the real subject of the post is the list under “A few consequences with how CSS does its thing”. And all those examples really are pixel-perfectness (pixel-perfect text boxes, pixel-perfect alignment of different fonts, pixel-perfect vertical centering of text in a button).

quite, we've been travelling backwards in accessibility terms for a while.

Reply on news.ycombinator.com