added a comment - - edited
When I wrote my treatise on font rasterisation (which I am surprised has not been mentioned) http://freddie.witherden.org/pages/font-rasterisation/ I covered the issue of producing freely (or linearly) scalable text at length — covering all three major approaches to rendering freely scalable text. Now, I will be the first to admit that I was/still am somewhat critical of Qt in its approach to this.
I will start of by analysing the problem faced by a word processing application (as opposed to that of a document reader — whose requirements are somewhat more stringent). In general there are three approaches to producing freely scalable text.
1) Don't use horizontal hinting. This is the ideal solution if the platforms native font rasterisation library supports it (OS X and FreeType). It always works (and is even suitable for document viewers).
2) The method of correctional deltas. Calculate the difference (the delta) between a line of hinted text and a line of un-hinted text (i.e., the device metric text). Distribute this delta as inter-word spacing. For word processors this method is incredibly effective. The same rasterisation is used for the document as for all other application text (unlike when the type/degree of hinting is changed) and it is seldom noticeable.
Page and line breaks are in the right places and so it is very almost WYSIWYG (words may be shifted slightly). If more accuracy is required the line can be sub-divided with each sub-division being corrected. If necessary space can be inserted/removed from between letters.
Word processors tend to take an approach similar to this although they often don't distribute the delta between words. Instead (as far as I can discern) a line of text is 'walked' through until a delta > 1.0 pixels is reached which is then corrected for instantly. Slightly uglier (as the space often ends up between letters) but it is very accurate (the error bound is |delta| < 1 pixel at any point along the line).
See Owen Taylor (2003) for more information on this type of approach.
3) Stick you head in the sand. By this, referred to as the naive method in my treatise, one positions hinted characters as if they were un-hinted. This is what Qt currently does when useDesignMetrics() is true. As the dimensions of hinted characters are different to those of un-hinted characters the results are often quite awful. (Hence the complains purporting to KOffice.)
Now, solution 2) is often very attractive. Why? As not explicit support for un-hinted text is required from the underlying rasteriser. However, there is a problem. It relies on the concept of a 'line' of text. In a word processor this is not a problem as such a construct is readily available. But, when rendering a 'document' such as a PDF there is no such concept. Characters in what we see as a line of text are often just a list of (x, y, char), i.e., each character is positioned absolutely on the page. As there is no line it is just not possible to generate a correctional delta. In this situation one is forced to use un-hinted text. (Adobe do this by shipping their own font rasterisation library, OS X is freely scalable out of the box and poppler has FreeType.)
So, as it is the most general solution, lets talk some more about producing un-hinted text. Un-hinted text is something of a misnomer — a better term is horizontally scalable text. Vertical hinting is fine — and encouraged. (This is what the LIGHT hinting option provided by FreeType provides.)
On Linux: Use FreeType with LIGHT or NO hinting. Perform horizontal advance calculations in floating point/fixed point. Render with sub-pixel precision.
On OS X: Render text as usual. Be sure not to round glyph positions to the pixel grid as OS X supports sub-pixel positioning.
On Window's: Use DirectWrite if under Vista/7 (similar to the rendering provided by the WPF, the 'new' way to render text) as it can produce freely scalable text. Otherwise if on XP break out FreeType.
The Window's solution is not clean if running under XP. However, you seldom see Window's users complain about the text in Adobe reader (unlike with old versions of Safari) and the desktop is slowly moving towards freely scalable text with DirectWrite.
Now, the key question: what should Qt provide and what should it not provide. A question which is slightly easier to answer is: what do application developers need/want? In short: an option for true freely scalable text. The 'how' is not a concern. Currently someone wanting this kind of functionality needs to roll out their own library and have a knowledge of: FreeType, CoreText/ATSUI, DirectWrite (+ some GDI). This is a tall order and beyond reach of many developers.
This is unfortunate as it means that many will just fall back on FreeType for all of their freely scalable textual needs (poppler does this) — even though the underlying OS (OS X, Vista/7) may provide native support for such text. This is why I consider it a toolkit issue — a general problem with platform specific solutions.
So in summary: useDesignMetrics can be fixed up by using the method of correctional deltas (option 2). KOffice users will be happy and Qt becomes a bit nicer. However, the long term solution is to provide an option for guaranteed freely scalable text on all platforms. This way applications that need truly freely scalable text can get it and those which do not can still get close with useDesignMetrics (with the added bonus of not changing the appearance of characters).
Finally, I would recommend against any inclination to expose hinting/anti-aliasing options from Qt (expect for possibly sub-pixel rendering as it is useful to disable it for rendering images to be saved/printed on other systems). Cairo exposes (FreeType centric) hinting options in the platform neutral cairo_font_options_t structure and it really does not solve any problems. (The structure attempts to set hinting on a best effort basis — and hence the hinting options are a no-op for Window's — not sufficient for an application requiring freely scalable text.)
I'm going to shut up now Polemically yours, Freddie.
P.S. I'll address sub-pixel positioning at some point if people are interested — but most of it is covered in my treatise.