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

List:       koffice
Subject:    Re: karbon
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2003-10-22 7:06:13
[Download RAW message or body]

Thomas Zander wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> 
> On Wednesday 15 October 2003 05:57, James Richard Tyrer wrote:
> 
>> Thomas Zander wrote:
>> 
>>> Ahh; now I see where you are going; my first answer would have been
>>> to say that you missed the advantage of vector (resolution
>>> independent) but now I see it is about points (knots) being placed
>>> on an underlying grid. While I am not completely aware of how things
>>> work in Karbon; knowing the developers I can say that this is a
>>> non-issue. Knots are placed in an absolute manner using doubles
>>> (XFig uses ints). Which basically means that they are resolution
>>> in-dependent. Just like Vector graphics are suppost to be. A double
>>> allows almost infinite resolution, and exactly that is the thing we
>>> left behind us when we moved away from applications like XFig.
>> 
>> Yes, SVG allows decimal fractions, but what I am talking about is how 
>> well fine detail prints or paints (with a printer or to a pixmap 
>> respectively). This is the same issue, the rendering of fine detail,
>> and fine detail renders better when the image aligns to a grid with
>> the resolution of the printer or pixmap.
> 
> 
> So; if I have a printer (lets take the DC70 I have here) that is 600
> DPI; what kind of DPI setting do I take in my application for full color
> print? Remember that the screening resolution is about 133lpi, but
> naturally an operator can adjust the RIP to change that to 150lpi since
> he now uses glossy paper. Oh; and don't forget that the artist now wants
> to print that 20 cm logo at 15cm. So the Karbon file is resized in his
> DPI application making your assumption moot.
> 
No matter what you say, if I am making something with find detail to print 
on my 600 DPI laser, you should know that I would want to take the 
resolution into account.  Do you know what a Moirč pattern is?  And that is 
not the only artifact when the resolution of the image doesn't match the 
resolution of the printer.

> In the end; premature optimisation is not wanted here either (as opposed
> to applying the saying to programming).  Trust the postscript and
> postscript engines to do that for you; they have come a _long_ way since
> the XFig days, you know!
> 
Apparently not.  We just think that something new is a panacea.  It never 
is.  Printers and video screens are still pixel bases and as long as that 
is true, an image that aligns with the pixels will look better than one 
that doesn't.
> 
>>>> NOTE: that if Karbon-14 is going to have pixmap support added, it
>>>> is going to need to have DPI in any case.
>>> 
>>> That is not true; FrameMaker, Quark and other DTP applications don't
>>> do that either.  The source image has a set of pixels. Making it 10
>>> cm wide will effectively make the DPI setting (for that specific
>>> image) different from making it 5cm wide.
>> 
>> Karbon-14 is not a DTP application.  The proper comparison would be to
>> The GIMP which does have control of DPI.
> 
> 
> Thats just nonsense; if you mix vector and pixmaps the only accurate 
> comparison is with DTP applications (or Illustrator naturally), not with
> an application that is grounded completely in a pixel minded
> environment.
> 
It seems foolish to say that something is nonsense.  Are you having a
rational discussion.  I think not.  And, I think that your are not at all
familiar with the current development version of The GIMP.
> 
> 
>>> Notice that the image never changes the amount of pixels; karbon
>>> just sends the original image to the postscript output specifying a 
>>> different resulting size.
>> 
>> That is correct, it doesn't change the number of pixels -- you have to
>> do that explicitly if that is what you want.
> 
> No you don't.  The application does that at printing time. You just
> scale it to a different size if you want; no mention of pixels anywhere.
>  And again; the RIP is very capable of rendering that pixmap to his
> DPI/lpi settings making the most of the picture.

Does it?  Does it produce an interpolated image or does it just print the
pixels?

> I'm wondering what kind of RIPs you have experience with; since you seem
> to believe we are still in the PS1 days...

GhostScript is the one that Linux normally uses.

--
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]