Hacker News Reader

Comment by Dwedit | Hacker News Reader

Some programs (such as WordPad) use a fancy combo box to select fonts. They draw each font name in the font itself. That requires loading and rendering with each font just so it can be displayed for the preview. WordPad isn't preloading fonts at boot time though. It does the slow thing where it loads up every font when you open the combobox.

View on HN

In principle, this could be implemented by only fully loading the font once you scroll to it in the combobox’s viewport.

Partial preprocessing might be needed, however, in order to extract the proper font names for sorting and autocomplete.

That’s pretty much what Office does anyway; it doesn’t pre-render previews for the whole list but does that when fonts scroll into view.

To be fair, that's how they should be displayed. I don't select a font based on its name, I select it based on its look.

Professional designers, on the other hand, need to care not just about typeface and foundry, but also about the exact version of fonts.

Back when magazines weren't nearly dead, I did production for a few years. The very first issue I worked on, I screwed up an ad by using a newer version of the font - the leading tables were different and a text block wrapped when it shouldn't have, so the advertiser got a couple free runs.

Always turned off rendering in lists and menus where I could, because it was not useful, slow, and harder to read.

I think this update to the fonts list was from some PHB instead of being requests from users. Some manager decided that the UI needed to be updated and tweaked because it was working, and we can't just let that happen

Same, but the software could:

1. Optimize for rendering the on-screen fonts first, then fill in the rest after the user’s starting looking at them.

2. Cache the preview. If it takes longer to render the sample text than to load a png, save the rendering so you can load it again next time.

It’s such a common idiom that fonts should have some kind of optimized “header” or something that can make it previewable but quick

I think for this to be generally effective for Windows software, developers on the whole not being consistent or wanting to invest the effort in little bits of polish like that, they would need an API into a system-wide implementation.

Which they could do, but it would take forever to see adoption in Windows culture, and Microsoft evidently cannot, just cannot, get their UI shit together.

To be fair, I don't care what the name of the font looks like in the font itself. I want to see the text I have selected updated with the font selected in the list.

well it also works this way.

well, this is how it should work. this "new" showing the name of the font in the font in the list is reeks from someone that had an idea, developed, tested on a system with standard fonts installed, AKA a small number of fonts, compared to someone that has a long list of fonts. Some PHB accepted it, and it got deployed only to be met by the crushing realities of users large set of installed fonts.

Ultimately, yes, that's what I want to see. But "Garamond" in the blind tells me nothing about how that will make my text look. So if I can see it before rendering all of my text in it, that's not unwelcome.

Two problems are that (1) the font name isn’t always very suitable to give a good impression of the font, and (2) for some fonts (symbol fonts, very ornate fonts, very small fonts) it can make the font name unreadable.

A better solution for the use-case of selecting fonts by looks is a dedicated font selection dialog that shows both the font name and a customizable example text in the font, and also lets you control the font size and variant (bold, italic). Some applications do exactly that.

I was wondering why they would load all the fonts, and this seems like a reasonable answer.

I seem to remember that both LO and Inkscape and possibly GIMP had bugs (since resolved IIRC) that involved this exact thing.

Reply on news.ycombinator.com