faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
WYSIWYG: Is this hopeless
by James Richard Tyrer on Tuesday 20/Dec/2005, @14:44
|
Having skimmed through the new documentation:
http://doc.trolltech.com/4.1/qfontmetrics.html
http://doc.trolltech.com/4.1/qprinter.htm
http://doc.trolltech.com/4.1/qpaintdevice.htm
I find two interesting points:
QList<int> QPrinter::supportedResolutions () const
For X11 where all printing is directly to postscript, this function will always return a one item list containing only the postscript resolution, i.e., 72 (72 dpi ... ).
int QFontMetrics::width ( QChar ch ) const
Returns the logical width of character ch in pixels.
I have to wonder, is it possible that the Trolls just don't get it? If you compute the font metrics at 72 DPI and then print it at 600 DPI, no wonder it looks BAD.
On Windows, the printer resolution list will contain numbers like 300, 600 that it gets from the printer driver. In that context, the resolution of PostScript is INFINITY.
[Another small problem is that not all printers have square resolution.]
OTOH, if we are just using the DPI as logical units it would work with 72 DPI except for the type of "QFontMetrics::width". "int" will not work, it needs to be "float" for X11. But, that won't work cross platform -- or will it? How does Redmond work?
The place to start appears to be with: "enum QPrinter::PrinterMode". This is where we should have the three modes:
ScreenResolution
PrinterResolution
PostScript
But, this has already been hacked so what appears to be needed is that: "HighResolution" should always refer to the resolution of the printer (we need this for Windows compatability and to make PDFs), and PostScript should be added as "3". The problem is that using this will break every function which returns the size of any font metric in pixels.
I don't have any good answers -- I can only note that they appear to have used the DOS/Windows paradigm of knowing the printer resolution and painted themselves into a corner. An interim solution would be for X11 to also use the Windows paradigm of using the printer resolution for WYSIWYG layout. But, this would require changes in KPrint so that it would use a PPD file for all printing. This would not be an ideal solution since the printing would still be a little off, but it would be a great improvement -- at 1200 DPI, you probably wouldn't be able to tell the difference. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: WYSIWYG: Is this hopeless
by Anonymous on Tuesday 20/Dec/2005, @15:09
|
James,
> I have to wonder, is it possible that the Trolls just don't get it?
They do get it. If you take a closer look at Qt 4 you'll discover that
a) there is also a QFontMetricsF class that gives you (as a developer) floating point precision for simple self-made text layouting.
b) /all/ the internal text layouting in Qt is using floating point precision.
Actually internally 26.6 fixed point is used, just like Freetype, but that's good enough and in the API of QFontMetricsF, QTextLayout and in the higher level Scribe classes you (as a developer) see qreal.
c) when laying out text you can disable the screen hinting and use linear scaled design font metrics for a nice preview on the screen that matches
(line/page break wise) exactly what you also get on a high resolution printer.
The last point actually still needs tuning for nicer screen output, but it does not fall into your "Trolls don't get it" category.
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by James Richard Tyrer on Tuesday 20/Dec/2005, @17:40
|
By WYSIWYG, I mean true WYSIWYG. Not Windows style which is just font metrics hinted at the printer resolution.
Yes, there is also a QFontMetricsF class (should have read more but ... ), but using that in place of the "int" typed class will require large changes in code. After thinking about this, it would appear that you could use the "float" type for all layout in KDE and this would solve part of the problem. It still has cross platform issues since X11 code could be used on Windows but Windows code might not work on X11 if it used the "int" class.
Yes, according to the documentation:
http://freetype.sourceforge.net/freetype2/docs/tutorial/step2.html
Freetype expresses the size of the glyphs in 64ths of a pixel -- that is 26,6 fixed point binary. But, that is for _hinted_ font metrics.
However, I have not been able to find where in Qt that you would choose unhinted font metrics. If you choose "QPrinter::HighResolution" you have not selected unhinted; it appears that on X11 that you have selected 600 DPI with hinting at that resolution -- at least it appears to me that "QPrinter::PrinterMode" would be what you would use to choose unhinted, and there is no PostScript option.
True WYSIWYG requires "metrics in design font units", and without further information, I don't see how you can do that. And if you are just doing 600 DPI then the "float" class is not needed. Even if you were using 7200 DPI, integer arithmetic would be faster than float unless you had to use if for scaled font design units.
Perhaps there is a Qt tutorial somewhere that might explain this in more detail.
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by Anonymous on Tuesday 20/Dec/2005, @22:54
|
-- snip
>Yes, there is also a QFontMetricsF class (should have read more but ... ), but using that in place of the "int" typed class will require large changes in code. After thinking about this, it would appear that you could use the "float" type for all layout in KDE and this would solve part of the problem. It still has cross platform issues since X11 code could be used on Windows but Windows code might not work on X11 if it used the "int" class.
-- snip
There is no portability issue using floating point precision instead of integer precision for text layouting. Not if you also do the glyph positioning in the toolkit, so the same precision is used across all platforms, which is what Qt does.
-- snip
>Freetype expresses the size of the glyphs in 64ths of a pixel -- that is 26,6 fixed point binary. But, that is for _hinted_ font metrics.
-- snip
Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. But that should be by far precise enough for decent glyph positioning on your 600 dpi printer.
-- snip
>However, I have not been able to find where in Qt that you would choose unhinted font metrics.
-- snip
People doing their own high-level text layouting (such as for example KWord might want to do when ported to Qt 4) should use QTextLayout. With QTextLayout it is possible to enable the use of design font metrics by setting the 'useDesignMetrics' property in the associated QTextOption object. Everyone else is free to use the high-level Scribe classes and enable the use of font design metrics there using QTextDocument's useDesignMetrics property.
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by Anonymous on Tuesday 20/Dec/2005, @23:20
|
-- snip
> Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. But that should be by far precise enough for decent glyph positioning on your 600 dpi printer.
-- snip
Maybe that part should be clarified. I meant it should be good enough for doing text layout in low screen resolution (~96 DPI) but with subpixel positioning for decent output on a higher resolution device then. With a factor 64 of added precision you get an effective resolution of ~6000 DPI.
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by James Richard Tyrer on Wednesday 21/Dec/2005, @21:10
|
> There is no portability issue
The portability issue does exist between *NIX and Windows. If a large OO Writer document is moved from Windows to *NIX and the compatibility mode in OO isn't used, the document will become noticeably shorter because hinting isn't used to compute the line lengths in *NIX. I think that the same thing might happen with Qt based wordprocessors, but only if the QFontMetricsF class functions returned non-integer values for unhinted glyphs.
> Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6.
Actually, IIUC, FreeType2 supplies these more precise figures but it doesn't actually use them to render the _hinted_ glyphs. They are supplied so that the application can more precisely compute the layout. This could be used to support a mode where the screen image was hinted but the printed metrics were correctly based on unhinted glyph dimension. WordPerfect can do something like this and it isn't really what I would call a feature. Real WYSIWYG is much better.
> But that should be by far precise enough for decent glyph positioning on your
> 600 dpi printer.
Perhaps although most office level lasers now start at 1200 DPI and inkjets are 1440 DPI. But, this isn't WYSIWYG, it is 600 DPI hinted fonts. As I said elsewhere, perhaps 7200 DPI hinted fonts would be sufficient in all cases, but I don't see 600 DPI as sufficient.
So, I take issue with the choice of 600 DPI as the ONLY value for "HighResolution" with X11. This is OK as a default but it should be settable.
> People doing their own high-level text layouting (such as for example KWord
> might want to do when ported to Qt 4) should use QTextLayout.
So, this is what I am taking issue with. You shouldn't have to do this (use completely different code) just to get true WYSIWYG. This should be possible using the "QFontMetricsF class" and setting the "PrinterMode" to "PostScript" (i.e. unhinted fonts).
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by Anonymous on Wednesday 21/Dec/2005, @22:19
|
-- snip
> > But that should be by far precise enough for decent glyph positioning on your
> > 600 dpi printer.
> Perhaps although most office level lasers now start at 1200 DPI and inkjets are 1440 DPI. But, this isn't WYSIWYG, it is 600 DPI hinted fonts. As I said elsewhere, perhaps 7200 DPI hinted fonts would be sufficient in all cases, but I don't see 600 DPI as sufficient.
-- snip
Actually QPrinter::HighResolution gives you 1200 DPI.
-- snip
> So, this is what I am taking issue with. You shouldn't have to do this (use completely different code) just to get true WYSIWYG. This should be possible using the "QFontMetricsF class" and setting the "PrinterMode" to "PostScript" (i.e. unhinted fonts).
-- snip
We are almost in agreement James :). We agree that it should be transparent to the programmer. However I argue that it is easier to default to screen dimensions when printing, because that's exactly what you also see when you debug/develop on the screen. For printing a higher resolution should of course be used, transparently to the programmer by simply scaling the QPainter. And for WYSIWYG the text should be layouted and positioned only /once/, in screen dimension but with a precision high enough to give nice output on a higher resolution printer.
Default to a 7200 DPI resolution for everything would be an insane waste of resources and it is harder to understand for developers because it significantly differs from what you see on the screen (ever debugged with xmag? :). Plus 99% of the time you do want your text hinted to low-resolution screen output, because 99% of the time text is displayed solely for screen output: Text in menus, text in web pages, text in tooltips, text in labels, etc. That is the common case and that is why text is hinted by default. Those few applications that need WYSIWYG can easily set the one or other property on an object :)
Anyway, I have to run now to catch my plane to my hometown for christmas vacation. Merry christmas everyone on the dot and in the KDE community :)
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by James Richard Tyrer on Thursday 22/Dec/2005, @00:13
|
> Actually QPrinter::HighResolution gives you 1200 DPI.
That is good, but I did read 600 DPI in the dox.
I note that as I have said before that you need to be able to choose between: "Screen", "DPI", and "FontMetrics" resolution depending on what you are doing.
Obviously "Screen" is best for viewing on the screen. To emulate Windows or to make a PDF, you would normally use "DPI" but for true WYSIWYG (e.g. something to be sent out to be printed) you need to be able to choose "FontMetrics".
It would be a great feature if you could choose these three modes and not have to change any code to do it. This would require using "float" for the layout and would (therefore) be a little slower -- but most machines have many times as much power as they need for wordprocessing.
I don't see how 7200 DPI for layout would be a problem. It shouldn't add overhead since it could all still be done with 32 bit integers and integer arithmetic.
And Merry Christmas to everyone. I got the Flu for Christmas, hope everyone else is doing better.
|
[
Reply To This | View ]
|
|
Re: WYSIWYG: Is this hopeless
by ac on Tuesday 20/Dec/2005, @16:02
|
I have to admit that I don't understand a word you said. But does this mean that the printing problems in KWord will not be fixed even when based on this version of Qt?
|
[
Reply To This | View ]
|
Re: WYSIWYG: Is this hopeless
by James Richard Tyrer on Tuesday 20/Dec/2005, @17:51
|
No, what it does mean is that so far in reading the documentation, I have not yet figured out how to do true WYSIWYG using font design units transformed into actual floating point dimensions (rather than DPI) for glyph dimensions.
However, if we could work in 7200 DPI resolution, it would be so close to correct that nobody would know the difference and that appears to require only small changes in Qt to do. 7200 DPI is a good value to simulate WYSIWYG because it is 5*1440 and 6*1200 so it would work for both common printer resolution moduli.
|
[
Reply To This | View ]
|
|
Re: WYSIWYG: Is this hopeless
by cm on Thursday 22/Dec/2005, @04:20
|
Hello James,
please take a look at this:
http://blogs.qtdeveloper.net/archives/2005/12/22/printing-and-wysiwyg/
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
