Re: Printing

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: michael@elehack.net,  emacs-devel@gnu.org
> Date: Wed, 01 Apr 2009 10:36:34 -0400
> 
> >> > I hope you are not saying that ps-print machinery is the only way
> >> > Emacs will be able to print in the future, i.e. rely on PostScript
> >> > support of the OS infrastructure.
> >> Yes, that's what I'm saying.
> > Then, if history teaches us anything, we will probably having this
> > discussion 10 years from now as well.
> 
> Note that I'm not opposed to implementations that use some other way of
> printing than Postscript.  I'm just saying that AFAICT in the
> foreseeable future, Emacs's printing will be based on Postscript.
> And in this regard, it works OK on Free systems where Postscript is
> always supported by the printing system (so the only problems on such
> systems have to do with Emacs's own ability to produce the right
> Postscript code).

PostScript is supported well on both free and proprietary platforms,
you are missing the point.  Let me remind you that what started this
thread was the complaints that ps-printing works well only for ASCII
and Latin-1 characters.

In this area, we basically didn't move much since ps-mule was
introduced more than 10 years ago.  Based on that experience, I fear
that if we stick to PostScript as the only decent printing facility in
Emacs, we will not improve our support of printing non-ASCII text for
the foreseeable future.  If you think otherwise, please explain how
come we are still where we were in 1998.

> >> What other way to print are you thinking of?
> 
> > The way every modern platform does that: through a printer API,
> > whereby you select fonts and layout, then render text to some device,
> > and the text gets printed to the printer you select.
> 
> Under GNU/Linux, the above goes through Postscript: the app generates
> a Postscript file and then passes it to the printing subsystem
> (typically CUPS) along with options such as color/bw, duplex/simplex,

You are again missing the point: it is not important how things are
done under the hood.  For example, on my home XP box, the default
printer is set up to use the PostScript driver, but applications still
don't emit PostScript themselves; the driver does.  So applications
don't care where the fonts are nor what fonts are built into the
printer and which ones need to be downloaded into it.  On the same
printer, I need to work hard configure ps-mule if I want to print
something that includes non-ASCII text.

> ... so generating Postscript is not at all contradictory with the desire
> to provide the usual printer dialog.

When PostScript generation is hidden from the application code, you
can leave it to the lower levels to solve problems such as finding and
selecting the right fonts.  With ps-print, since we produce PostScript
in Lisp, we also need to be able to DTRT with fonts, which is
obviously not an easy job to do on an arbitrary end-user platform.
That's the big difference.

> > Since Emacs already knows how to render text, it shouldn't be too hard
> > to teach it do so to something other than a screen.
> 
> That sounds good as well, but someone has to write the code.

Someone has to write the code for better support of non-ASCII
printing, too.  TANSTAAFL.