[Gnome-print] Re: RFC: A draft proposal ...
- From: Damien Diederen <dash linuxbe org>
- To: Mathieu Lacage <lacage email enst fr>
- Cc: gnome-print helixcode com, gnome-devel-list gnome org
- Subject: [Gnome-print] Re: RFC: A draft proposal ...
- Date: Tue, 18 Apr 2000 22:16:12 +0200
Hello !
On Tue, Apr 18, 2000 at 01:59:32PM +0200, Mathieu Lacage wrote:
> Derek Simkowiak <dereks@kd-dev.com> writes:
>
[clip]
> > I'm working on a Gtk+-only text editor (I'm currently bogged down
> > in writing a new text widget :), and for my printing system I plan to pipe
> > the text file through "mpage" (which converts text into Postscript).
> > Type "man mpage" and you'll immediately see the huge variety of print
> > options I'll be able to offer in my program. All I need to do is put
> > together a GUI dialog box around the common/useful mpage command-line
> > options and boom! I've got a full-blown printing system that works with
> > any printer supported by Red Hat Linux (read: Ghostscript filters).
>
> Ghostscript rasterizing system is not THAT good. Raph has some sample
> prints which prove this.
While I agree that GhostScript rasterizing is not always perfect, I wonder
if this is not "fixable". Is the GhostScript codebase unmaintainable ?
Wouldn't it be possible to take the parser and the PostScript interpreter
out of it, and to interface it with libart (or whatever you want to use
as a rendering engine ?).
This would also improve the print quality for the vast number of users that
are using GhostScript to print on their non-PostScript printers with
non-gnome applications (and the large base of PostScript manipulation tools
will probably not be ported to Gnome, while they could be used by Gnome
applications -- have a look at the example Derek gave about his text editor
and mpage).
> >
> > One point not mentioned in the RFC is all the pre-existing Open
> > Source code, algorithms, and documentation built around Postscript. If we
> > don't go with Postscript, we would not only need to re-invent the wheel,
> > but we'd need to throw out a mature, stable, well-supported wheel at the
> > same time.
> >
> > ...Not to mention that many printers support Postscript right out
> > of the box.
>
> which is NOT the case for most low-cost printers which most people buy.
>
> It happens sadly that our target users (desktop users) don't usually
> buy PS printers. (My mother has no PS printer)
Rasterizing still has to be done, even if you don't use PostScript, as
a vast majority of application printouts is vector data.
>
> >
> > Also, using Postscript is a proven model. If Postscript works for
> > GNUStep, I don't see why it shouldn't work for Gnome.
>
> Postscript imaging model misses some stuff. First one to come to my mind
> is transparency (ie: alpha compositing) which can be simulated in PS
> though, I know.
I don't quite grasp why a GhostScript/Libart frankeinstein couldn't serve
our need (the extension could be described in the XPD, and emulation
could be provided for true PostScript printers -- this needs to be done,
anyways).
...
0.5 1 0 0 gs_setrgbacolor
eofill
...
> Mathieu
>
Cu,
Damien.
--
* Pétition contre les brevets logiciels : http://lln.udev.org/sign.php3
--
Damien Diederen
dash@linuxbe.org
http://users.swing.be/diederen/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]