Thomas Zander
Qt
KDE
Graphics Dojo
Posted by Thomas Zander
 in Qt, KDE, Graphics Dojo
 on Thursday, August 28, 2008 @ 13:28

For the last 5 years a huge focus of my work has been on fonts and text. You know you went to far when you can tell the difference between a Helvetica and an Arial by just looking at the printed ‘a’.
Its unsurprising that people end up asking me what the difference is between leading and linespacing, why the customer claims we don’t do kerning for that specific font, why WYSIWYG actually fails for most people. I naturally can’t be because I’m the only one stupid enough to claim to know this, right?
I considered claiming ignorance, but then my weird behavior may no longer have any reason, so that would just make me a worse freak. Instead I just wrote an application that shows everyone how text works. And I’ll write a blog or two about what you can see on screen and how that relates to your questions even before you have them. Genius or what?
So, here is an example text;
fontanatomy1.png
let me quickly go over the different parts. In red we have the outline, this is the total amount of space that the text takes. This is what is reserved in your user interface for the text. The sizes you see on the right hand side are the major anatomical dividers of a font face. Much like your body has a head and legs (I’m making assumptions about that, work with me). The baseline is the only one that is really interesting to point out. it’s the zero-point for a font. All measurements start from there. So you have a part that’s above and a part that’s below the baseline. I’ll leave it to your imagination to mirror that to your own anatomy.
In blue we have the size taken by the individual characters. But when we are talking about fonts we actually should be talking about glyphs. There are subtle differences, but I won’t bore you with that. Each glyph has its own rectangle as you can see in the blue. This is useful to see since the m is wider than the j, which is useful to know since you position the characters next to each other. The blue little gradients are helpers (called bearings) to position the glyphs better so they visually look more pleasing.

Ok, with the basics behind you here are a bit more interesting things; consider the two following screenshots.
fontanatomy2.pngfontanatomy3.png

The only difference is that kerning is turned on for the first and turned off for the second. Notice how the blue boxes overlap in the first image and how they are simply placed side by side in the second.
In general you want kerning to be turned on, its on by default in Qt because it increases readability.

Last example; this one is tricky.
fontanatomy4.pngfontanatomy5.png
Fonts are designed in a way that they can be scaled and reused for any size. Which is a pretty neat idea since it avoids using a crystal ball to figure out which sizes to ship your font in. There is a little problem, though. A font that is printed on paper at 10cm per character needs a lot of detail but if you use the same character at on screen at just a couple of millimeters height, you have problems to make that one look good.
So, font makers ship something called ‘hints’. Which make their fonts look better at smaller sizes then the computer could do automatically. This is enabled per default and is practically speaking exactly what you want.
Except for one problem; if you add all those little adjustments they can add up. So much that if you have a sentence you can have a word that fits just fine when you show the font on screen, but if you then take the same width and same text but on paper, those little adjustments may just move a word to the next line.
In other words; hinting gets in the way of what you see is what you get text-layout. So, in Qt you can turn this off. Allowing you to get the exact same line-breakings on screen as you get on paper.
Look at the following two screenshots. You will see a little spacing between the little blue squares in the one where the hinting is turned off. We call this mode ‘designer metrics’.
if you want to play around with this stuff yourself, here you can find the sources;

svn checkout svn://labs.trolltech.com/svn/graphics/fontAnatomy

For the people that are still here, thanks for sharing the pain! And I’ll answer the question of “why should I care!”. The concepts shown in this blog have good support in Qt4. The point to take home is that the font is the one that specifies all the information. If the font doesn’t have kerning, game over. If the font has horrible sizing information, you are out of luck. With this little tool at least you can see the differences that different fonts make.

17 Responses to “font anatomy”

» Posted by Kenji Sugita
 on Thursday, August 28, 2008 @ 13:52

How about a vertical font metrics?

» Posted by Axel
 on Thursday, August 28, 2008 @ 13:59

Dear Thomas

As a LaTeX fanboy I’m really glad to see someone taking care of typesetting in KDE, KOffice, Qt etc. Keep up the good work! Will KDE, Koffice and Qt be able to make use of all the goodies that the OpenType specification provides?

Regards,
Axel

» Posted by Luiz
 on Thursday, August 28, 2008 @ 14:32

Odd, on my linux I saw absolutely no difference when I checked/unchecked the Enable Kerning and Use Design Metrics. I’m gonna test it on my windows as well. But it should’ve made difference right?
One thing, does this means that there’s work being done to get WYSIWYG editing/printing on QTextEdit? textEdit->document()->setUseDesignMetrics(true) doesn’t do the trick. On windows I’ve manage to get QTextEdit (using a textwidth with the same width as the paper rect of the printer) to match the layout of the printed text by reimplementing the print function (and not using setUseDesignMetrics) . But on Linux the same code doesn’t produce the same result. Arg I see ifdefs on my future…
I hope some improvements are being made on this area. Making a more powerful Text Editor with Qt is proving to be quite a challenge.

Regards,

Luiz

» Posted by Ben
 on Thursday, August 28, 2008 @ 14:45

> So, font makers ship something called ‘hints’. Which make their fonts look better at smaller sizes then the computer could do automatically. This is enabled per default and is practically speaking exactly what you want.

Not quite, many distributions use the Freetype autohinter and that ignores the font hinting. Gives us font makers headaches since users will always blame the font if the autohinter generates bad spacing, inconsistencies or generally bad results :-)

» Posted by girish
 on Thursday, August 28, 2008 @ 15:01

Thanks thomas, great post, given the very detailed docs for the property (http://doc.trolltech.com/4.4/qtextdocument.html#useDesignMetrics-prop) :-))

» Posted by Tim
 on Thursday, August 28, 2008 @ 15:56

What are those blue gradients on the vertical edges?

» Posted by Elvis Stansvik
 on Thursday, August 28, 2008 @ 16:37

Nice post and cool program. How come e.g. the ‘f’ in the first of the screenshots sticks out of the blue rect a bit at the top? I tried the program and it happens at certain font sizes that the glyphs stick out here and there. Has it something to do with the rect drawing not taking anti-aliasing of the font into consideration? Anyway, nice tool.

» Reply from Thomas Zander
 on Friday, August 29, 2008 @ 07:37
Thomas Zander

@axel Thanks for the kind words :)
Any fixes and support we add in Qt will automaticaly mean KDE and KOffice will use that as well, yes. As far as adding support for more features from OpenType goes, it is very interresting to look at and we might pick that up for a future release. Most of the support is actually not done in Qt but in harfbuzz, an open source library anyone can hack on :)

@Luiz Its the fonts that make the difference. Its likely that you picked a font (on either platform) that doesn’t have the level of detail (hinting) that this actually make you see the difference. Arial and dejavu were chosen for my screenshots. Also note that kerning is most visible in combinations like “VA”.
WYSIWYG in QTextEdit is a different story, there is no pagination and frankly no page awareness in QTextEdit, so getting the same width on screen as on paper is a hit and miss. QTextEdit was not meant to be a paper-based-layout kind of widget. KWord for example uses QTextDocument and its producing very good results, but it does do things in a completely different way.

@girish I added some more comments to that property now. See also the QTextOption::setUseDesignMetrics()

@Tim The blue little gradients are helpers (called bearings) to position the glyphs better so they visually look more pleasing. They signify the difference between the outline of a glyph and where they allow the next glyph to begin.

@Elvis The blue boxes (tightBoundingRect) of each character are calculated with the metrics from the font at that size. The painting uses hinting to make the font look good visually, so the height of the individual glyph at this high zoom can look a little off. Notice how everything is still in the red bounding box, so actual layout is not affected.

» Posted by Damjan
 on Friday, August 29, 2008 @ 11:00

Hey Thomas, sorry to spam you, but do you have an idea how hard would it be to implement this http://trolltech.com/developer/task-tracker/index_html?method=entry&id=129519 (Qt support for “locl” (Localized Forms) in OpenType fonts for replacing generic letters with localized ones).

Pango already has it for some time, and is really neccesseary for my language (macedonian).

» Posted by Axel
 on Friday, August 29, 2008 @ 13:11

@Damjan,

if I understand Thomas correctly that functionality should also be addressed in the harfbuzz library.
For other features of OpenType have a look at the linux libertine font project: http://linuxlibertine.sourceforge.net/Libertine-DE.html#opentype

Great OpenType support would be a real “Alleinstellungsmerkmal” in office software, that is, this feature would make KOffice something special in an arialized world.

» Posted by Damjan
 on Tuesday, September 02, 2008 @ 18:33

@Axel
I understand that harfbuzz might be better to be used for more the advanced OT features but locl is a bit of a more sensitive issue, so it might be better to support in Qt directly. Like Pango does for ex. http://en.wikipedia.org/wiki/Pango#Support_for_OpenType_features

» Posted by Damjan
 on Thursday, September 04, 2008 @ 19:33

or you are saying that Qt will use harfbuzz ?

ps.
Is there a way for the public to discuss on bugs in the Qt bug tracking system? This is a discussion I’m interested in, but it seems weird to do it as coments on this blog post?

» Posted by Erik
 on Saturday, September 06, 2008 @ 09:44

@Thomas
Heh, that introduction was funny to read, especially because I works in the same area :-)

Anyway, in this description you managed to keep silent on cross-platform excitement for non-X11 environments. (Not that surprising, as your heads-deep into KOffice.) So a nasty question to you: how does this play together with ATS/ATSUI and ClearType? Especially because they have a very different philosophy on “how to make fonts look good on screen” (Apple: font designer is in charge, MS: ClearType renderer is in charge). I guess this makes the headache even worse for a cross-platform toolkit…

» Posted by patrik08
 on Wednesday, September 10, 2008 @ 11:12

Thousand Tanks to this Know-How … That push me to begin write a Opendocument *.odt format reader on Qt4.5 . A reader on XSL-FO
( http://www.qt-apps.org/content/show.php/Fop+MiniScribus+XSL-Fo?content=67552 ) i having already beta, Opendocument use the XSL-FO namenspace is similar.
Now tell me Know-How how i can Implement not only inline frame float left/right , but absolute position y,x on page 1,2,3 … inside QTextDocument.

» Reply from Thomas Zander
 on Thursday, September 11, 2008 @ 17:46
Thomas Zander

@Damjan
Qt has been using harfbuzz since Qt4.4.0
@Erik all of the features work perfectly cross platform, all those pesky details are done internally in Qt :)

» Posted by Damjan
 on Friday, September 12, 2008 @ 13:33

So, it seems that harfbuzz does not support the locale OpenType feature, at least a quci grep trough the git[1] version didn’t find anything.
And from what I see from the git[1] summary page it doesn’t have any progress since 7 months ago?!?

[1] http://gitweb.freedesktop.org/?p=harfbuzz.git;a=summary



© 2008 Nokia Corporation and/or its subsidiaries. Nokia, Qt and their respective logos are trademarks of Nokia Corporation in Finland and/or other countries worldwide.
All other trademarks are property of their respective owners.