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

List:       koffice
Subject:    Re: karbon
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-10-22 19:13:22
[Download RAW message or body]

I think I start to understand what you want.

As your printner is 600 dpi, you would want that (let name it so) the grid is 
based also on 600dpi. But Postscript is not working that way. PostScript is 
based on 72dpi (the point.) That is why all KOffice application use the point 
as base.

Of course PS and also KOffice use floating points, but that is still not 
making it 600dpi-based, however one turns that around. (360dpi, 720dpi and 
1440dpi are better values in this case, as there are multiples of 72.)

Sure in theory, this means a higher risk of moiré. However as far as I know it 
is the job of the RIP to minimize that. The RIP does know that PS is about 
72dpi and that the RIP's device can probably do more (whatever 300dpi, 
360dpi, 600dpi, 720dpi, 1200dpi, 2400dpi or whatever a high-end professional 
printing machine has for a resolution.)

As for Ghostscript, I do not know if it can do this or if it can do this with 
all its printer drivers. I suppose that this is one of the reasons why the 
Gimp people have done special Gimp drivers, also usable with Ghostscript.

Have a nice day!

On Wednesday 22 October 2003 09:06, James Richard Tyrer wrote:
> 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.

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