[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Printing
From: |
grischka |
Subject: |
Re: Printing |
Date: |
Wed, 01 Apr 2009 22:51:42 +0200 |
User-agent: |
Thunderbird 2.0.0.18 (X11/20081125) |
Well, I agree with most you wrote.
Just, if BMP is raw graphical data then Postscript isn't much more than
a sophisticated compression method to encode it.
With higher data capacities nowadays such compressions become more or
less obsolete, also because at the same time accurate WYSIWYG becomes
more important.
So my guess is that anyway the "Postcript experts" are a dying out
species and once they have gone nobody will want to fix that part of
the "toolkit onto itself" in question here. Admittedly, whether this
happens sooner or later may vary depending on the OS.
--- grischka
David De La Harpe Golden wrote:
If that were so then only postscript experts would be able to teach
their application to print something.
Application developers use toolkits, toolkit developers target the
printing system. /Except/ on windows, that printing subsystem tends to
involve postscript: A toolkit, like gtk+ with cairo, draws vectors to a
postscript document [1] instead of rasterising (or sending trapezoids
(xrandr) or general polys (opengl) to the display driver in the modern
era) to the screen when it wants to print, then sends that postscript
document to the printing daemon which does whatever is necessary to
print it (for cheap printers, maybe rasterising it fully to
device-specific bitmap data with ghostscript, for postscript printers,
maybe munging it a bit to the postscript level the printer wants and
passing it on). i.e. a hypothetical "pure gtk+ stack" emacs at the
application level might well use gtk+ and cairo for both screen display
and printing and abstract over the individual platform and indeed screen
vs. print differences, but cairo is still probably just going to be
drawing to postscript underneath for printing purposes on free or even
nonfree but unixy platforms.
Since emacs is currently a "toolkit unto itself" for the most part, as
Stefan has already pointed out, it kind of makes sense for it to
generate its own postscript. Though maybe just saving out and
"enscript"ing text files might currently work about as well...
On windows, the toolkit uses win32 drawing commands on a printer device
context [2] instead of postscript drawing on a postscript document.
Typically they might internally rasterise to a high-res DIB (.bmp) then
printed with basically just one such win32 drawing command consisting of
"draw this enormous .bmp please".
So, if you squint *a lot*, .bmp in the windows printing world is a
*little* like .ps in the nonwindows printing world. Maybe windows
people might be conceptualising .ps as device-specific thing that things
are printed _to_ (and it is that _too_ I guess), but it is /also/ a
quasistandard intermediate format for printing in the relevant OS apis
on nonwindows.
Mind you, PDF would work just as well or better than postscript for that
purpose, but the current de-facto standard is for OSes to expose an
interface that accepts postscript documents for printing. Windows is the
only vaguely relevant one that _doesn't_, pretty much, and it's only a
ghostscript installation away anyway, it provides mswinpr2 to rasterise
postscript to .bmps sent to native windows printers (which may then of
course inefficiently convert them back to postscript to send to native
postscript printers, but anyway...)
[1] http://cairographics.org/manual/cairo-ps-surface.html
[2] http://cairographics.org/manual/cairo-win32-surface.html
- Re: Printing, (continued)
- Re: Printing, grischka, 2009/04/01
- Re: Printing, David De La Harpe Golden, 2009/04/01
- Re: Printing, Stefan Monnier, 2009/04/01
- Re: Printing, Stefan Monnier, 2009/04/02
- Re: Printing, grischka, 2009/04/02
- Re: Printing, Stefan Monnier, 2009/04/02
Re: Printing, YAMAMOTO Mitsuharu, 2009/04/02