PDF and Postscript generators
With the release of 4.1 Qt has gained the ability to generate PDF natively. We have put special care trying to make sure all features of Arthur are also supported in our PDF generator.
This implies that we can do alpha transparency and gradients in the generated PDF. One main issue I found while bugfixing the implementation is that our open source PDF renderers (ghostscript and poppler) still have a large way to go to support more advanced PDF features. poppler wasn’t even able to handle masked images (something that apparently has been fixed a few weeks ago), while both of them had rather large problems with real transparency.
We have written code to generate native gradients in PDF that are semitransparent. The only problem is that the only viewer that can render them correctly is adobe’s acrobat reader. So for the moment that code is disabled and we embed the gradient as a pixmap. The resulting PDFs are quite a bit bigger and slower, but at least they render correct on all three PDF viewers.
The only small drawback of our PDF generator in Qt 4.1.0 is that the generated PDF is not searchable. But this is only because the code needed to implement this has missed the 4.1.0 deadline. It’s written and tested, and Qt 4.1.1 will thus generate searchable and Unicode compliant PDF .
At the same time I’ve took the opportunity and have rewritten parts of the Postscript backend. We now embed fonts as Type1 fonts (it used to be Type3), something that will make the size of the generated Postscript quite a bit smaller. At the same time I’ve fixed a few bugs in the Postscript generator that where outstanding since Qt 4.0.0.
Qt can do WYSIWYG layouting!
While I’m writing about printing, let me also say that the myth that Qt can’t do WYSIWYG text layouting is wrong. I saw this being repeated quite a few times on the dot, see for example James comment.
Qt 4 has support for using design metrics of fonts. If you’re layouting text on a per paragraph level, QTextOption has a flag to enable this. If you use Qt’s build in rich text support, you can set a flag on a complete QTextDocument.
When using these flags, all text layouting calculations will be done with subpixel precision using the linear/design metrics from the font.
The fact that QPrinter::supportedResolutions() returns 72 for postscript has nothing to say in this respect. All the number gives you is a conversion factor between units on a QPainter and millimeters on the output device. QPainter has since Qt 4.0 a floating point API that allows you to place objects at arbitrary positions inside a postscript (or for that respect PDF) document.
So in the end there should be no real problem for kword or any other Qt application to do WYSIWYG text layouting and printing.
Have a nice christmas and a happy new year!
4 Responses to “printing and WYSIWYG”
Great work Lars. I’ve followed your presentation in Ludwigsburg and became aware of the extreme complexity of text layouting and large amount of work you have done.
Does Qt 4.0 breaks lines in a paragraph using the same algorithm than TeX ? It would be great to have the typographical algorithms of TeX included in Qt to get the best of both worlds : the typographical quality of TeX and the modernity of Unicode with a standard font system. Are we very far from that ?
The PDF support sounds rather cool. Maybe KPDF can just use it KDE 4.0 and onwards?
segedenum: generation, not rendering
I didn’t actually say that Qt couldn’t do WYSIWYG. I said that I hadn’t figured it out yet. Now that I have, I am still not really satisfied.
IIUC, to have WYSIWYG, you must use the new class: “QTextDocument” rather than just changing from the: “QFontMetrics” class to the: “QFontMetricsF” class.
While this new class looks like if would be quite usefull, it will mean a complete rewrite of large amounts of code in KWord. Is there some reason that WYSIWYG couldn’t be added to: “QPrinter::PrinterMode” so that the only change in the code would be to change to the “float” class and functions?
You are partially correct that the resolution of 72 DPI isn’t relevant. It is correct to layout PS documents in units of 1/72 of an inch as long as they are floating point with a fraction because that is what PS uses in the file.
However, in addition to font metrics WYSIWYG, it is also necessary to do layout at fixed DPI — either the DPI of the printer to emulate Windows in *NIX or when making PDFs.. So, while using 72 DPI with fractions is correct for PostScript WYSIWYG, it is necessary to be able to set: “QPrinter::HighResolution” when using Qt-X11. While 600 DPI is an acceptable default, this needs to be setable.
The size of hinted fonts changes depending on the DPI that they are rendered at. This is why long text documents shrink when moved from Windows to *NIX. This needs to be directly addressed so that the user can choose which resolution to use for the layout of a document: “Screen”, “DPI”, or “FontMetrics”. This may be a new idea to some, but WordPerfect users should be familiar with the fact that changing the printer driver will change the layout of the document.
Therefore, I also suggest that “QPrinter::supportedResolutions()” does need to return the resolutions available based on the current printer selected. In X11, this would be derived from a PPD file. It appears that there also needs to be some way to determine if PostScript is available to do font metrics based WYSIWYG. This would always be true on X11, but might not be on older versions of Windows.