[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: karbon being DPI based (was karbon)
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2003-10-27 1:24:40
[Download RAW message or body]

Nicolas Goutte wrote:
> On Sunday 26 October 2003 22:32, James Richard Tyrer wrote:
> 
>>Tomasz Grobelny wrote:
>>
>>>On Sunday 26 of October 2003 07:57, James Richard Tyrer wrote:
>>>
>>>>not make mistakes like Troll Tech made with the PostScript driver.
>>>
>>>I haven't followed the whole discussion (although I've read part of it)
>>>but I would like to ask what are the mistakes Trolltech made. Not that I
>>>think QPainter + QPrinter is enough for office suite but I would like to
>>>know more on this subject (especially image rendering).
>>
>>You know.  Problems caused by trying to have the printed image match the
>>screen.
>>
>>I found a new one last week.  It seems that if you print an HTML page from
>>Konqueror that the size of a JPEG which it contains will depend on the
>>screen resolution you set in X.  So, if you have a higher resolution
>>screen, the image might get too wide for US Letter or ISO A4 paper. :-(
>>
>>Clearly, it should scale the page so that it was the correct width for
>>whatever size paper you chose -- that the screen width is scaled to the
>>width of the paper less your margins or reasonable default minimums (0.25
>>inch/18 Points for US letter [based on 8 inches being the maximum that many
>>8.5 inch printers will print]).
>>
>>It appears that a default resolution of 72 DPI applies if I print a JPEG
>>from the: "Image Viewer part", so it is going to be smaller than the screen
>>image (in most cases) and there is no way to adjust it.
> 
> 
> Yes, Qt prints images at 72dpi. And yes I hate it too, see my one of other 
> emails of today (the one about the Qt wish.) It is exactly the same problem.
> 
Since the Qt PostScript driver prints HTML pages at the screen resolution, 
I suspect that there must be some way for KDE to change this setting.
> 
>>In both cases, the actual image is embedded in the PS file and it is left
>>to the printer or GhostScript to interpolate it to the printer resolution.
>>  This is correct for a generic PS file, but certainly not the best choice
>>for printing.
>>
>>My usual rant applies:
>>
>>"Did anybody design this before they wrote the code?"
> 
> 
> Well, first one is happy that it prints at all. Then one does more work. Or 
> would you prefer that KWord does not print because we are using that 
> screen==printer mode of QPrinter?

That is a hard question. :-)  Since it does not use the font metrics in the 
font files, it is basically useless for many purposes.

You said that we are using the screen==printer mode.  Is there another 
mode?  I thought that there wasn't.  I didn't read the code very carefully 
-- just skimmed through it looking for the parts where the font names are 
put in the PS files.

> Note: I am not saying that we could[n't] do better. (My question is always where to 
> find the manpower to also do changes.)
> 
My complaint here was really about Troll Tech and they hire people to do 
this, don't they?  But, I have the theory that it probably would take less 
manpower to first design something and then build it rather than several 
iterations of building it and making large changes.
> 
>>Note that it is no problem to print an image whatever size you want by
>>running the image through The GIMP and making a PS file but The GIMP is
>>certainly over-kill for this
> 
> 
> Simply saving the image and giving it to lpr or kprinter should do the same if 
> the print filter are set correctly.

If just giving it to Kprinter will fix the problem, one wonders why it 
doesn't do the same if the "Image Viewer part" gives it to it.  Yes, I 
know, it doesn't generate a PS file, but again, why can't you do that from 
the "Image Viewer part"?

--
JRT

____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]