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

List:       koffice
Subject:    Re: karbon
From:       Thomas Zander <zander () kde ! org>
Date:       2003-10-15 7:30:09
[Download RAW message or body]

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

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!


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


> > 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.
I'm wondering what kind of RIPs you have experience with; since you seem to 
believe we are still in the PS1 days...

- -- 
Thomas Zander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/jPeECojCW6H2z/QRAqk+AJ9n1I6e0uDnE62UtgLsV6accpMKgACePKHn
2oHn3FTsd+WoItXpoWAqlFY=
=HSSr
-----END PGP SIGNATURE-----
____________________________________
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]