Printing

Printing

[Андрей Парамонов]

Hello!

I use Emacs on regular basis for a couple of years already, and I find
it a great piece of software. Currently I use Emacs 23. As a user, I'm
very pleased with the overall direction of development. I highly
appreciate recent usability improvements, namely Xft fonts, visual
line wrapping, transparent remote file access, etc.

With the most important internationalisation and display issues fixed
in Emacs 23, it's probably the right time to attack another long
standing problem: the printing. By this post I wish to attract your
attention to fundamental usability problems of Emacs printing
mechanism, and initiate a discussion of how to resolve them.

Emacs printing is broken -- and I mean it -- is *fundamentally*,
totally broken. You have either to be a PostScript guru, restrict
yourself to ASCII characters, or cheat/hack to be able to use Emacs
printing. And I'm not even talking about non-GNU systems! Many users
find it major pain or impossible to setup printing in Emacs (here are
links to *recent* threads at gnu.emacs.help):

Pretty multilingual PostScript printing:
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/4b08d4ff107d48d/

Printing with emacs: Not working:
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/c477e1561c444583/

Printing in Emacs:
http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/d4c5ee0e29adcdfb/

To reproduce the problem you only need Emacs, X and a printer:

1) C-h h; the 'Hello' buffer with international characters shows
   up. If you don't see anything except Latin characters, please
   install the TTF version of unifont.

2) M-x ps-print-buffer-faces; the buffer is printed, but every
   non-Latin character is replaced with '?'.

However, if the 'Hello' buffer contents is printed via as simple
editor as GEdit, *all* the characters are printed, and appear smooth
and nice!

Having analysed mine and other users' experience, and having examined
how the printing works in modern applications, I propose the following
requirements for the Emacs printing mechanism:

1) Simple printing configuration should require no or almost no
   knowledge and effort. The only user input that might be required is
   the printer name.

2) It should not be necessary to install additional packages/files
   solely for the Emacs printing.

3) Printing functionality should work equally good on PostScript and
   non-PostScript printers.

I can think of the following ways of how these requirements may be
achieved:

a) Try to improve current functionality, making no or almost no
   modifications to the current printing engine. This includes
   simplifying the configuration interface. Not sure points 2) and 3)
   can be fixed this way though.

b) Use standard GTK+ printing facilities as GEdit and many other
   applications do. Emacs is built with GTK+ interface for quite some
   time now, so I suppose there should be no architectural problem in
   using GTK+ for printing as well. Please correct me if I'm wrong.

c) Utilise superior rendering capabilities of some other application,
   like it is done by package hfyview.el:
   http://www.emacswiki.org/emacs/PrintWithWebBrowser . This
   approach doesn't conform to 2) though.

From the user perspective, I like b) because I think it would solve 3)
and would present a nice user interface. I call you to discuss the
pros and contras of the proposed approaches from the programmer
perspective and/or propose other solutions.

Thanks for your effort,
Andrey Paramonov

To reproduce the problem you only need Emacs, X and a printer:

1) C-h h; the 'Hello' buffer with international characters shows
   up. If you don't see anything except latin characters, please
   install the TTF version of unifont.

2) M-x ps-print-buffer-faces; the buffer is printed, but every
   non-latin character is replaced with '?'.

However, if the 'Hello' buffer contents is printed via as simple
editor as GEdit, *all* the characters are printed, and appear smooth
and nice!

Having analyzed mine and other users' experience, and having examined
how the printing works in modern applications, I propose the following
requirements for the Emacs printing mechanism:

1) Simple printing configuration should require no or almost no
   knowledge and effort. The only user input that might be required is
   the printer name.

2) It should not be necessary to install additional packages/files
   solely for the Emacs printing.

3) Printing functionality should work equally good on PostScript and
   non-PostScript printers.

I can think of the following ways of how these requirements may be
achieved:

a) Try to improve current functionality, making no or almost no
   modifications to the current printing engine. This includes
   simplifying the configuration interface. Not sure points 2) and 3)
   can be fixed this way though.

b) Use standard GTK+ printing facilities as GEdit and many other
   applications do. Emacs is built with GTK+ interface for quite some
   time now, so I suppose there should be no architectural problem in
   using GTK+ for printing as well. Please correct me if I'm wrong.

c) Utilize superior rendering capabilities of some other application,
   like it is done by package hfyview.el:
   http://www.emacswiki.org/emacs/PrintWithWebBrowser . This
   approach doesn't conform to 2) though.

From the user perspective, I like b) because I think it would solve 3)
and would present a nice user interface. I call you to discuss the
pros and contras of the proposed approaches from the programmer
perspective and/or propose other solutions.

Thanks for your effort,
Andrey Paramonov

Re: Printing

[Jan Djärv]

Андрей Парамонов skrev:

> b) Use standard GTK+ printing facilities as GEdit and many other
>    applications do. Emacs is built with GTK+ interface for quite some
>    time now, so I suppose there should be no architectural problem in
>    using GTK+ for printing as well. Please correct me if I'm wrong.
> 

The problem is that Gtk+ printing assumes you are rendering with cairo.  Emacs
 does not do that.  Changing that would be a major undertaking.  Something
like porting Emacs to a totally new toolkit.

	Jan D.

Re: Printing

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

>>>>> On Sat, 28 Mar 2009 15:56:04 +0100, Jan Djärv <jan.h.d@swipnet.se> said:

> Андрей Парамонов skrev:
>> b) Use standard GTK+ printing facilities as GEdit and many other
>> applications do. Emacs is built with GTK+ interface for quite some
>> time now, so I suppose there should be no architectural problem in
>> using GTK+ for printing as well. Please correct me if I'm wrong.
>> 

> The problem is that Gtk+ printing assumes you are rendering with
> cairo.  Emacs does not do that.  Changing that would be a major
> undertaking.  Something like porting Emacs to a totally new toolkit.

FWIW, several ports for Mac OS X are using Quartz 2D that can generate
PDF as in Cairo.  So creating a "resolution-independent screenshot" is
immediate especially with Cocoa.  Of course, it is still not
sufficient for general printing.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: ctfont.pdf --]
[-- Type: application/pdf, Size: 52506 bytes --]

Re: Printing

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

>>>>> On Tue, 31 Mar 2009 11:13:13 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> b) Use standard GTK+ printing facilities as GEdit and many other
>>> applications do. Emacs is built with GTK+ interface for quite some
>>> time now, so I suppose there should be no architectural problem in
>>> using GTK+ for printing as well. Please correct me if I'm wrong.
>>> 

>> The problem is that Gtk+ printing assumes you are rendering with
>> cairo.  Emacs does not do that.  Changing that would be a major
>> undertaking.  Something like porting Emacs to a totally new
>> toolkit.

> FWIW, several ports for Mac OS X are using Quartz 2D that can
> generate PDF as in Cairo.  So creating a "resolution-independent
> screenshot" is immediate especially with Cocoa.  Of course, it is
> still not sufficient for general printing.

I tried making a really preliminary proof-of-concept cairo port. :-)
It's still rough and has several glitches/limitations, but at least it
can generate a "resolution-independent screenshot" PDF as attached.
Maybe I'll clean up the code this weekend and hopefully post a patch.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: cairotest.pdf --]
[-- Type: application/pdf, Size: 28152 bytes --]

Re: Printing

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

>>>>> On Thu, 02 Apr 2009 18:39:24 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I tried making a really preliminary proof-of-concept cairo port. :-)
> It's still rough and has several glitches/limitations, but at least
> it can generate a "resolution-independent screenshot" PDF as
> attached.  Maybe I'll clean up the code this weekend and hopefully
> post a patch.

Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).

* No configure support.  The easiest way would be to compile it with
  the GTK+ support that is already linked with cairo libs.  Add
  -DUSE_CAIRO to CFLAGS to activate the cairo code.

* With an experimental function (x-export-frame-image FRAME TYPE), you
  can get the current FRAME screenshot as a unibyte string in TYPE
  format.  TYPE can be 'pdf, 'ps, 'png, or 'svg if the installed cairo
  supports their formats.

* Currently, texts, rectangles (filling and stroking), and trapezoids
  for reliefs are drawn using cairo by hooking the corresponding
  drawing routine calls in xterm.c.  They use X11 GC (with extension
  data) for colors and clipping rectangles, but operations on them can
  easily be ported to non-X11 (e.g., terminal-only) environments just
  like the Carbon port.

* Images could also be drawn with cairo, but I didn't do that because
  the image drawing in xterm.c depends on X-specific data structures.
  As a result, you can't see any images in the exported screenshot as
  of now.

* Stipples are ignored (both on screen and exported one).

* Exported png images seem to be incorrect in some cases.  I suspect
  it has something to do with cairo's cluttering the activated FT_Size
  mentioned in ftcrfont.c, but I'm not sure.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: emacs-23.0.92-cairo.patch.gz --]
[-- Type: application/octet-stream, Size: 12059 bytes --]

Re: Printing

[Lennart Borgman]

On Sat, Apr 4, 2009 at 4:44 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Thu, 02 Apr 2009 18:39:24 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
>
>> I tried making a really preliminary proof-of-concept cairo port. :-)
>> It's still rough and has several glitches/limitations, but at least
>> it can generate a "resolution-independent screenshot" PDF as
>> attached.  Maybe I'll clean up the code this weekend and hopefully
>> post a patch.
>
> Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).
>
> * No configure support.  The easiest way would be to compile it with
>  the GTK+ support that is already linked with cairo libs.  Add
>  -DUSE_CAIRO to CFLAGS to activate the cairo code.
>
> * With an experimental function (x-export-frame-image FRAME TYPE), you
>  can get the current FRAME screenshot as a unibyte string in TYPE
>  format.  TYPE can be 'pdf, 'ps, 'png, or 'svg if the installed cairo
>  supports their formats.
>
> * Currently, texts, rectangles (filling and stroking), and trapezoids
>  for reliefs are drawn using cairo by hooking the corresponding
>  drawing routine calls in xterm.c.  They use X11 GC (with extension
>  data) for colors and clipping rectangles, but operations on them can
>  easily be ported to non-X11 (e.g., terminal-only) environments just
>  like the Carbon port.
>
> * Images could also be drawn with cairo, but I didn't do that because
>  the image drawing in xterm.c depends on X-specific data structures.
>  As a result, you can't see any images in the exported screenshot as
>  of now.
>
> * Stipples are ignored (both on screen and exported one).
>
> * Exported png images seem to be incorrect in some cases.  I suspect
>  it has something to do with cairo's cluttering the activated FT_Size
>  mentioned in ftcrfont.c, but I'm not sure.


Does this work on w32?

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 4 Apr 2009 08:54:32 +0200, Lennart Borgman <lennart.borgman@gmail.com> said:

>>> I tried making a really preliminary proof-of-concept cairo
>>> port. :-) It's still rough and has several glitches/limitations,
>>> but at least it can generate a "resolution-independent screenshot"
>>> PDF as attached.  Maybe I'll clean up the code this weekend and
>>> hopefully post a patch.
>> 
>> Here's the patch for the Emacs 23.0.92 pretest (not the trunk
>> HEAD).

>> * Currently, texts, rectangles (filling and stroking), and
>> trapezoids for reliefs are drawn using cairo by hooking the
>> corresponding drawing routine calls in xterm.c.  They use X11 GC
>> (with extension data) for colors and clipping rectangles, but
>> operations on them can easily be ported to non-X11 (e.g.,
>> terminal-only) environments just like the Carbon port.
>> 
>> * Images could also be drawn with cairo, but I didn't do that
>> because the image drawing in xterm.c depends on X-specific data
>> structures.  As a result, you can't see any images in the exported
>> screenshot as of now.

> Does this work on w32?

No.  Because I hooked to the drawing routine calls in xterm.c to
minimize the changes as the first step, which is intended for doing
some experiments whether cairo is useful for printing in Emacs.

If it is proved to be useful, then the next step would be to introduce
page-device frames in contrast to the existing screen-device frames,
so as to make the cairo drawing work without window systems.  That's
why I mentioned X-specific data structures above.  As seen by the size
of the changes to xterm.c, core drawing code can be shared between
these different types of frames.

Actually, the design of the cairo patch is based on that of the
Carbon(+AppKit) port.  The work of rewriting from Xlib to cairo was
very similar to that from QuickDraw to Quartz 2D.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Leo]

On 2009-04-04 03:44 +0100, YAMAMOTO Mitsuharu wrote:
[...]
> Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).
>
> * No configure support.  The easiest way would be to compile it with
>   the GTK+ support that is already linked with cairo libs.  Add
>   -DUSE_CAIRO to CFLAGS to activate the cairo code.
>
> * With an experimental function (x-export-frame-image FRAME TYPE), you
>   can get the current FRAME screenshot as a unibyte string in TYPE
>   format.  TYPE can be 'pdf, 'ps, 'png, or 'svg if the installed cairo
>   supports their formats.
>
> * Currently, texts, rectangles (filling and stroking), and trapezoids
>   for reliefs are drawn using cairo by hooking the corresponding
>   drawing routine calls in xterm.c.  They use X11 GC (with extension
>   data) for colors and clipping rectangles, but operations on them can
>   easily be ported to non-X11 (e.g., terminal-only) environments just
>   like the Carbon port.
>
> * Images could also be drawn with cairo, but I didn't do that because
>   the image drawing in xterm.c depends on X-specific data structures.
>   As a result, you can't see any images in the exported screenshot as
>   of now.
>
> * Stipples are ignored (both on screen and exported one).
>
> * Exported png images seem to be incorrect in some cases.  I suspect
>   it has something to do with cairo's cluttering the activated FT_Size
>   mentioned in ftcrfont.c, but I'm not sure.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

This is a giant step forward.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.

               www.git-scm.com
    git - the one true version control system

Re: Printing

[Richard M Stallman]

The code looks fairly clean, but it totally lacks comments.
It needs to have full and clear comments before it is installed.

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 04 Apr 2009 18:00:49 -0400, Richard M Stallman <rms@gnu.org> said:

> The code looks fairly clean, but it totally lacks comments.  It
> needs to have full and clear comments before it is installed.

It's not intended as something to be installed at all, but an
experimental one to see if it's worth going forward.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Kenichi Handa]

In article <wlab6xuohg.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> > I tried making a really preliminary proof-of-concept cairo port. :-)
> > It's still rough and has several glitches/limitations, but at least
> > it can generate a "resolution-independent screenshot" PDF as
> > attached.  Maybe I'll clean up the code this weekend and hopefully
> > post a patch.

> Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).

As your patch contains fixes to ftfont.c:

[...]
! 	if (FT_Load_Char (ft_face, i, FT_LOAD_DEFAULT) == 0)
[...]
!       font->underline_thickness = ft_face->underline_thickness * size / upEM;

I've just comitted those changes.  Thank you for finding
them.  Does the patch contain any other fixes?

---
Kenichi Handa
handa@m17n.org

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 06 Apr 2009 17:03:18 +0900, Kenichi Handa <handa@m17n.org> said:

> [...]
> ! 	if (FT_Load_Char (ft_face, i, FT_LOAD_DEFAULT) == 0)
> [...]
> !       font->underline_thickness = ft_face->underline_thickness * size / upEM;

> I've just comitted those changes.  Thank you for finding
> them.  Does the patch contain any other fixes?

Not in the patch, but I can find a similar code in xftfont.c for the
latter.  And maybe

  XFillRectangle (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), gc,
		  x, y - font->ascent, width, y + font->descent);

in ftxfont_draw_backgrond (sic) should be

  XFillRectangle (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), gc,
		  x, y - FONT_BASE (font), width, FONT_HEIGHT (font));

What do you think about the use of GC extension data in the patch?  It
allows us to extract information about clipping rectangles not from
struct glyph_string but from GC without using a wrapper.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Kenichi Handa]

In article <wld4bqcgs2.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Not in the patch, but I can find a similar code in xftfont.c for the
> latter.  And maybe

>   XFillRectangle (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), gc,
> 		  x, y - font->ascent, width, y + font->descent);

> in ftxfont_draw_backgrond (sic) should be

>   XFillRectangle (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), gc,
> 		  x, y - FONT_BASE (font), width, FONT_HEIGHT (font));

Thank you.  I've just fixed them.

> What do you think about the use of GC extension data in the patch?  It
> allows us to extract information about clipping rectangles not from
> struct glyph_string but from GC without using a wrapper.

Sorry but I don't have a time to read your code in detail.
Could you explain why using GC extension data is better than
(struct glyphs_string *)->clip?

---
Kenichi Handa
handa@m17n.org

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 06 Apr 2009 20:47:28 +0900, Kenichi Handa <handa@m17n.org> said:

>> What do you think about the use of GC extension data in the patch?
>> It allows us to extract information about clipping rectangles not
>> from struct glyph_string but from GC without using a wrapper.

> Sorry but I don't have a time to read your code in detail.  Could
> you explain why using GC extension data is better than (struct
> glyphs_string *)->clip?

I guess you introduced the members for clipping rectangles in struct
glyph_string because we can't extract such information, which is
necessary for text drawing, from the raw GC.  In the case of cairo
drawing, such information is also necessary for almost all kinds of
drawing, and the use of GC extension data allows us to extract
clipping rectangles without introducing a wrapper data structure of GC
(though we need a couple of wrapper functions,
x_(re)set_clip_rectangles).  This strategy can also be applied to the
existing text drawing routines.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Kenichi Handa]

In article <wlhc119wf2.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> > Sorry but I don't have a time to read your code in detail.  Could
> > you explain why using GC extension data is better than (struct
> > glyphs_string *)->clip?

> I guess you introduced the members for clipping rectangles in struct
> glyph_string because we can't extract such information, which is
> necessary for text drawing, from the raw GC.

Yes.

> In the case of cairo
> drawing, such information is also necessary for almost all kinds of
> drawing, and the use of GC extension data allows us to extract
> clipping rectangles without introducing a wrapper data structure of GC
> (though we need a couple of wrapper functions,
> x_(re)set_clip_rectangles).  

That doesn't answer my question.  As I now don't remember
well when and how it is used, just by reading your comment,
I don't understand what is the problem of using (struct
glyphs_string *)->clip, and how using GC extention data
solves it.

---
Kenichi Handa
handa@m17n.org

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 07 Apr 2009 10:01:46 +0900, Kenichi Handa <handa@m17n.org> said:

>> In the case of cairo drawing, such information is also necessary
>> for almost all kinds of drawing, and the use of GC extension data
>> allows us to extract clipping rectangles without introducing a
>> wrapper data structure of GC (though we need a couple of wrapper
>> functions, x_(re)set_clip_rectangles).

> That doesn't answer my question.  As I now don't remember well when
> and how it is used, just by reading your comment, I don't understand
> what is the problem of using (struct glyphs_string *)->clip, and how
> using GC extention data solves it.

Not a problem, but just a matter of uniformity.  Even in the current
xterm.c, colors and clipping information is managed by GC for drawings
except texts.  The use of GC extension data enables us to get rid of
this special treatment for text drawings.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Future of display engine [Re: Printing]

[Kenichi Handa]

In article <wlws9x1cz7.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> > That doesn't answer my question.  As I now don't remember well when
> > and how it is used, just by reading your comment, I don't understand
> > what is the problem of using (struct glyphs_string *)->clip, and how
> > using GC extention data solves it.

> Not a problem, but just a matter of uniformity.  Even in the current
> xterm.c, colors and clipping information is managed by GC for drawings
> except texts.  The use of GC extension data enables us to get rid of
> this special treatment for text drawings.

Ah, I see your point.  I was thinking the other way round.
I vaguely think we can have more uniform display engine if
we can have various information for displaying in a device
independent way.  Though, I have not investigate it in
detail.

---
Kenichi Handa
handa@m17n.org

Re: Future of display engine [Re: Printing]

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 08 Apr 2009 10:19:33 +0900, Kenichi Handa <handa@m17n.org> said:

>> Not a problem, but just a matter of uniformity.  Even in the
>> current xterm.c, colors and clipping information is managed by GC
>> for drawings except texts.  The use of GC extension data enables us
>> to get rid of this special treatment for text drawings.

> Ah, I see your point.  I was thinking the other way round.  I
> vaguely think we can have more uniform display engine if we can have
> various information for displaying in a device independent way.
> Though, I have not investigate it in detail.

Yes. I was thinking about uniformity in the other direction.  Packing
graphics state information such as colors and clipping rectangles into
GC is what Xlib (which is the current standard in Emacs) is doing, and
can be ported to the other graphics frameworks as I showed in the
cairo patch and the Carbon(+AppKit) port (both QuickDraw and Quartz
2D).  Of course, it would be meaningful to change that design so it
fits with some "next generation standard" graphics framework in Emacs.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

>>>>> On Sat, 04 Apr 2009 11:44:27 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> I tried making a really preliminary proof-of-concept cairo port. :-)
>> It's still rough and has several glitches/limitations, but at least
>> it can generate a "resolution-independent screenshot" PDF as
>> attached.  Maybe I'll clean up the code this weekend and hopefully
>> post a patch.

> Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).

> * Currently, texts, rectangles (filling and stroking), and trapezoids
>   for reliefs are drawn using cairo by hooking the corresponding
>   drawing routine calls in xterm.c.  They use X11 GC (with extension
>   data) for colors and clipping rectangles, but operations on them can
>   easily be ported to non-X11 (e.g., terminal-only) environments just
>   like the Carbon port.

> * Images could also be drawn with cairo, but I didn't do that because
>   the image drawing in xterm.c depends on X-specific data structures.
>   As a result, you can't see any images in the exported screenshot as
>   of now.

I added fringe bitmap drawing with cairo because it can be added
without using X-specific data structures.

Handa-san, could you check if the following change to ftfont.c is
correct?  It is also included in the revised patch below.

*************** ftfont_text_extents (font, code, nglyphs
*** 1255,1261 ****
  		  metrics->lbearing = m->horiBearingX >> 6;
  		  metrics->rbearing = (m->horiBearingX + m->width) >> 6;
  		  metrics->ascent = m->horiBearingY >> 6;
! 		  metrics->descent = (m->horiBearingY + m->height) >> 6;
  		}
  	      first = 0;
  	    }
--- 1255,1261 ----
  		  metrics->lbearing = m->horiBearingX >> 6;
  		  metrics->rbearing = (m->horiBearingX + m->width) >> 6;
  		  metrics->ascent = m->horiBearingY >> 6;
! 		  metrics->descent = (m->height - m->horiBearingY) >> 6;
  		}
  	      first = 0;
  	    }
*************** ftfont_text_extents (font, code, nglyphs
*** 1269,1276 ****
  		  = width + ((m->horiBearingX + m->width) >> 6);
  	      if (metrics->ascent < (m->horiBearingY >> 6))
  		metrics->ascent = m->horiBearingY >> 6;
! 	      if (metrics->descent > ((m->horiBearingY + m->height) >> 6))
! 		metrics->descent = (m->horiBearingY + m->height) >> 6;
  	    }
  	  width += m->horiAdvance >> 6;
  	}
--- 1269,1276 ----
  		  = width + ((m->horiBearingX + m->width) >> 6);
  	      if (metrics->ascent < (m->horiBearingY >> 6))
  		metrics->ascent = m->horiBearingY >> 6;
! 	      if (metrics->descent < ((m->height - m->horiBearingY) >> 6))
! 		metrics->descent = (m->height - m->horiBearingY) >> 6;
  	    }
  	  width += m->horiAdvance >> 6;
  	}

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: emacs-23.0.92-cairo.patch.gz --]
[-- Type: application/octet-stream, Size: 13784 bytes --]

Re: Printing

[Kenichi Handa]

In article <wl1vs4iyp2.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Handa-san, could you check if the following change to ftfont.c is
> correct?  It is also included in the revised patch below.

Thank you.  Those changes are correct.  I've just committed them.

> *************** ftfont_text_extents (font, code, nglyphs
> *** 1255,1261 ****
>   		  metrics->lbearing = m->horiBearingX >> 6;
>   		  metrics->rbearing = (m->horiBearingX + m->width) >> 6;
>   		  metrics->ascent = m->horiBearingY >> 6;
> ! 		  metrics->descent = (m->horiBearingY + m->height) >> 6;
>   		}
>   	      first = 0;
>   	    }
> --- 1255,1261 ----
>   		  metrics->lbearing = m->horiBearingX >> 6;
>   		  metrics->rbearing = (m->horiBearingX + m->width) >> 6;
>   		  metrics->ascent = m->horiBearingY >> 6;
> ! 		  metrics->descent = (m->height - m->horiBearingY) >> 6;
>   		}
>   	      first = 0;
>   	    }
> *************** ftfont_text_extents (font, code, nglyphs
> *** 1269,1276 ****
>   		  = width + ((m->horiBearingX + m->width) >> 6);
>   	      if (metrics->ascent < (m->horiBearingY >> 6))
>   		metrics->ascent = m->horiBearingY >> 6;
> ! 	      if (metrics->descent > ((m->horiBearingY + m->height) >> 6))
> ! 		metrics->descent = (m->horiBearingY + m->height) >> 6;
>   	    }
>   	  width += m->horiAdvance >> 6;
>   	}
> --- 1269,1276 ----
>   		  = width + ((m->horiBearingX + m->width) >> 6);
>   	      if (metrics->ascent < (m->horiBearingY >> 6))
>   		metrics->ascent = m->horiBearingY >> 6;
> ! 	      if (metrics->descent < ((m->height - m->horiBearingY) >> 6))
> ! 		metrics->descent = (m->height - m->horiBearingY) >> 6;
>   	    }
>   	  width += m->horiAdvance >> 6;
>   	}

---
Kenichi Handa
handa@m17n.org

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 08 Apr 2009 10:33:59 +0900, Kenichi Handa <handa@m17n.org> said:

> In article <wl1vs4iyp2.wl%mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Handa-san, could you check if the following change to ftfont.c is
>> correct?  It is also included in the revised patch below.

> Thank you.  Those changes are correct.  I've just committed them.

I've just found the following part was partially applied.  Could you
check the direction of the inequality in the if-condition?

> *************** ftfont_text_extents (font, code, nglyphs
> *** 1269,1276 ****
>   		  = width + ((m->horiBearingX + m->width) >> 6);
>   	      if (metrics->ascent < (m->horiBearingY >> 6))
>   		metrics->ascent = m->horiBearingY >> 6;
> ! 	      if (metrics->descent > ((m->horiBearingY + m->height) >> 6))
> ! 		metrics->descent = (m->horiBearingY + m->height) >> 6;
>   	    }
>   	  width += m->horiAdvance >> 6;
>   	}
> --- 1269,1276 ----
>   		  = width + ((m->horiBearingX + m->width) >> 6);
>   	      if (metrics->ascent < (m->horiBearingY >> 6))
>   		metrics->ascent = m->horiBearingY >> 6;
> ! 	      if (metrics->descent < ((m->height - m->horiBearingY) >> 6))
> ! 		metrics->descent = (m->height - m->horiBearingY) >> 6;
>   	    }
>   	  width += m->horiAdvance >> 6;
>   	}

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 4252 bytes --]

>>>>> On Tue, 07 Apr 2009 18:46:01 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> I tried making a really preliminary proof-of-concept cairo port. :-)
>>> It's still rough and has several glitches/limitations, but at least
>>> it can generate a "resolution-independent screenshot" PDF as
>>> attached.  Maybe I'll clean up the code this weekend and hopefully
>>> post a patch.

>> Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).

>> * No configure support.  The easiest way would be to compile it with
>>   the GTK+ support that is already linked with cairo libs.  Add
>>   -DUSE_CAIRO to CFLAGS to activate the cairo code.

>> * Currently, texts, rectangles (filling and stroking), and trapezoids
>>  for reliefs are drawn using cairo by hooking the corresponding
>>  drawing routine calls in xterm.c.

This time, I combined the cairo drawing code with GTK+ print dialogs
code, which is actually almost the same as examples in the GTK+
reference.  The added primitives are:

(x-page-setup-dialog): Pop up a page setup dialog.
(x-get-page-setup): Return the value of the current page setup.
  It returns an alist like
  ((orientation . portrait)
   (width . 559.2755905511812) (height . 783.5697637795276)
   (left-margin . 18.0) (right-margin . 18.0)
   (top-margin . 18.0) (bottom-margin . 40.32000000000001))
(x-print-frames-dialog FRAMES): Pop up a print dialog to print the
  current contents of FRAMES.

The last one is intended to be called after some pagination (in Lisp)
that creates a frame per page.  Below is a simple example.

(defun test-print-buffer (buffer-or-name)
  "Paginate and print buffer contents."
  (interactive "bBuffer to export:")
  (with-current-buffer buffer-or-name
    (let* ((buffer (current-buffer))
	   (start-pos (point-min))
	   (end-pos (point-max))
	   (page-setup (if (fboundp 'x-get-page-setup)
			   (x-get-page-setup)
			 '((width . 559.0) (height . 783.0))))
	   (width-in-points (cdr (assq 'width page-setup)))
	   (height-in-points (cdr (assq 'height page-setup)))
	   buffers frames)
      (unwind-protect
	  (progn
	    (with-selected-frame (selected-frame)
	      ;; Paginate and create a frame for each page.
	      (while (< start-pos end-pos)
		(let ((inhibit-quit t))
		  (set-buffer
		   (make-indirect-buffer
		    buffer (generate-new-buffer-name (buffer-name buffer)) t))
		  (push (current-buffer) buffers)
		  (setq kill-buffer-hook nil) ;; XXX
		  (select-frame (make-frame
				 '((internal-border-width . 0)
				   (vertical-scroll-bars . nil)
				   (left-fringe . 0) (right-fringe . 0)
				   (menu-bar-lines . 0) (tool-bar-lines . 0)
				   (line-spacing . 0)
				   (minibuffer . nil) (visibility . nil)
				   (cursor-type . nil)))
				'norecord)
		  (push (selected-frame) frames))
		(set-frame-size (selected-frame)
				(floor (/ width-in-points (frame-char-width)))
				(floor (/ height-in-points (frame-char-height))))
		(setq header-line-format nil)
		(setq mode-line-format nil)
		(set-window-start nil start-pos)
		(goto-char (window-end nil t))
		(while (and (< start-pos (point))
			    (not (pos-visible-in-window-p (1- (point)))))
		  (backward-char))
		(narrow-to-region start-pos (point))
		(setq start-pos (point))))
	    ;; Print the frames.
	    (if (null frames)
		(error "Buffer %s is empty" buffer-or-name)
	      (mapc 'make-frame-visible frames)
	      (if (fboundp 'x-print-frames-dialog)
		  (x-print-frames-dialog (reverse frames))
		;; Dummy stub just to reproduce an intermittent error
		;; in x-print-frames-dialog even without it.
		(dolist (frame frames)
		  (unless (eq (frame-visible-p frame) t)
		    (error "Frames to be printed must be visible.")))
		(redisplay t))))
	;; Clean up
	(mapc 'delete-frame frames)
	(mapc 'kill-buffer buffers)))))

You can try printing with M-x test-print-buffer RET.  Because the
current cairo drawing routines are hooked onto those in xterm.c in
order to minimize the change, you'll see the actual frames on screen.
Moreover, you might get an incorrect printed result because your
window manager may clip the frames to fit in the screen size.
Nevertheless, I think you can get the basic idea with this sample
code.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: emacs-23.0.92-cairo.patch.gz --]
[-- Type: application/octet-stream, Size: 17848 bytes --]

Re: Printing

[Stefan Monnier]

Hi,

I'd be interested to see this pushed further.  Maybe you could make
a branch in the bzr repository for it?


        Stefan


>>>>> "YAMAMOTO" == YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>> On Tue, 07 Apr 2009 18:46:01 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>>> I tried making a really preliminary proof-of-concept cairo port. :-)
>>>> It's still rough and has several glitches/limitations, but at least
>>>> it can generate a "resolution-independent screenshot" PDF as
>>>> attached.  Maybe I'll clean up the code this weekend and hopefully
>>>> post a patch.

>>> Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).

>>> * No configure support.  The easiest way would be to compile it with
>>> the GTK+ support that is already linked with cairo libs.  Add
>>> -DUSE_CAIRO to CFLAGS to activate the cairo code.

>>> * Currently, texts, rectangles (filling and stroking), and trapezoids
>>> for reliefs are drawn using cairo by hooking the corresponding
>>> drawing routine calls in xterm.c.

> This time, I combined the cairo drawing code with GTK+ print dialogs
> code, which is actually almost the same as examples in the GTK+
> reference.  The added primitives are:

> (x-page-setup-dialog): Pop up a page setup dialog.
> (x-get-page-setup): Return the value of the current page setup.
>   It returns an alist like
>   ((orientation . portrait)
>    (width . 559.2755905511812) (height . 783.5697637795276)
>    (left-margin . 18.0) (right-margin . 18.0)
>    (top-margin . 18.0) (bottom-margin . 40.32000000000001))
> (x-print-frames-dialog FRAMES): Pop up a print dialog to print the
>   current contents of FRAMES.

> The last one is intended to be called after some pagination (in Lisp)
> that creates a frame per page.  Below is a simple example.

> (defun test-print-buffer (buffer-or-name)
>   "Paginate and print buffer contents."
>   (interactive "bBuffer to export:")
>   (with-current-buffer buffer-or-name
>     (let* ((buffer (current-buffer))
> 	   (start-pos (point-min))
> 	   (end-pos (point-max))
> 	   (page-setup (if (fboundp 'x-get-page-setup)
> 			   (x-get-page-setup)
> 			 '((width . 559.0) (height . 783.0))))
> 	   (width-in-points (cdr (assq 'width page-setup)))
> 	   (height-in-points (cdr (assq 'height page-setup)))
> 	   buffers frames)
>       (unwind-protect
> 	  (progn
> 	    (with-selected-frame (selected-frame)
> 	      ;; Paginate and create a frame for each page.
> 	      (while (< start-pos end-pos)
> 		(let ((inhibit-quit t))
> 		  (set-buffer
> 		   (make-indirect-buffer
> 		    buffer (generate-new-buffer-name (buffer-name buffer)) t))
> 		  (push (current-buffer) buffers)
> 		  (setq kill-buffer-hook nil) ;; XXX
> 		  (select-frame (make-frame
> 				 '((internal-border-width . 0)
> 				   (vertical-scroll-bars . nil)
> 				   (left-fringe . 0) (right-fringe . 0)
> 				   (menu-bar-lines . 0) (tool-bar-lines . 0)
> 				   (line-spacing . 0)
> 				   (minibuffer . nil) (visibility . nil)
> 				   (cursor-type . nil)))
> 				'norecord)
> 		  (push (selected-frame) frames))
> 		(set-frame-size (selected-frame)
> 				(floor (/ width-in-points (frame-char-width)))
> 				(floor (/ height-in-points (frame-char-height))))
> 		(setq header-line-format nil)
> 		(setq mode-line-format nil)
> 		(set-window-start nil start-pos)
> 		(goto-char (window-end nil t))
> 		(while (and (< start-pos (point))
> 			    (not (pos-visible-in-window-p (1- (point)))))
> 		  (backward-char))
> 		(narrow-to-region start-pos (point))
> 		(setq start-pos (point))))
> 	    ;; Print the frames.
> 	    (if (null frames)
> 		(error "Buffer %s is empty" buffer-or-name)
> 	      (mapc 'make-frame-visible frames)
> 	      (if (fboundp 'x-print-frames-dialog)
> 		  (x-print-frames-dialog (reverse frames))
> 		;; Dummy stub just to reproduce an intermittent error
> 		;; in x-print-frames-dialog even without it.
> 		(dolist (frame frames)
> 		  (unless (eq (frame-visible-p frame) t)
> 		    (error "Frames to be printed must be visible.")))
> 		(redisplay t))))
> 	;; Clean up
> 	(mapc 'delete-frame frames)
> 	(mapc 'kill-buffer buffers)))))

> You can try printing with M-x test-print-buffer RET.  Because the
> current cairo drawing routines are hooked onto those in xterm.c in
> order to minimize the change, you'll see the actual frames on screen.
> Moreover, you might get an incorrect printed result because your
> window manager may clip the frames to fit in the screen size.
> Nevertheless, I think you can get the basic idea with this sample
> code.

> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 04 May 2012 23:06:43 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> Hi, I'd be interested to see this pushed further.  Maybe you could
> make a branch in the bzr repository for it?

Perhaps I'll work a bit locally first, starting with adding a new type
of (output-only) graphical terminal for printing.  The idea is to add
a printing support via cairo without being tied with a particular
window system.

Is anyone already working for supporting multiple types of graphical
terminals simultaneously?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Lennart Borgman]

On Mon, May 7, 2012 at 5:38 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Fri, 04 May 2012 23:06:43 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
>
>> Hi, I'd be interested to see this pushed further.  Maybe you could
>> make a branch in the bzr repository for it?
>
> Perhaps I'll work a bit locally first, starting with adding a new type
> of (output-only) graphical terminal for printing.  The idea is to add
> a printing support via cairo without being tied with a particular
> window system.
>
> Is anyone already working for supporting multiple types of graphical
> terminals simultaneously?

Is Cairo enough to make a general printing system? Should not the
abstraction be on a higher level so that different OS:es can be
supported?

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 7 May 2012 13:25:23 +0200, Lennart Borgman <lennart.borgman@gmail.com> said:

>> Perhaps I'll work a bit locally first, starting with adding a new
>> type of (output-only) graphical terminal for printing.  The idea is
>> to add a printing support via cairo without being tied with a
>> particular window system.
>> 
>> Is anyone already working for supporting multiple types of
>> graphical terminals simultaneously?

> Is Cairo enough to make a general printing system? Should not the
> abstraction be on a higher level so that different OS:es can be
> supported?

Actually, the primary motivation of introducing a cairo terminal was
to support the generation of PDF data from the buffer contents
directly using the Emacs redisplay engine, even from a tty session
(i.e., without X server running), rather than supporting multiple
window systems.  Showing a print dialog, sending the output to a
printer, etc. will need another library or something, perhaps in a
window-system dependent way.

Do you possibly have some idea of "abstraction on a higher level"?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Lennart Borgman]

On Tue, May 8, 2012 at 3:04 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Mon, 7 May 2012 13:25:23 +0200, Lennart Borgman <lennart.borgman@gmail.com> said:
>
>>> Perhaps I'll work a bit locally first, starting with adding a new
>>> type of (output-only) graphical terminal for printing.  The idea is
>>> to add a printing support via cairo without being tied with a
>>> particular window system.
>>>
>>> Is anyone already working for supporting multiple types of
>>> graphical terminals simultaneously?
>
>> Is Cairo enough to make a general printing system? Should not the
>> abstraction be on a higher level so that different OS:es can be
>> supported?
>
> Actually, the primary motivation of introducing a cairo terminal was
> to support the generation of PDF data from the buffer contents
> directly using the Emacs redisplay engine, even from a tty session
> (i.e., without X server running), rather than supporting multiple
> window systems.  Showing a print dialog, sending the output to a
> printer, etc. will need another library or something, perhaps in a
> window-system dependent way.
>
> Do you possibly have some idea of "abstraction on a higher level"?

Ah, I see. Did you consider the printing already available in nXhtml?
This makes html pages from buffers (and also from frames for other
purposes).

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 8 May 2012 03:25:33 +0200, Lennart Borgman <lennart.borgman@gmail.com> said:

>> Actually, the primary motivation of introducing a cairo terminal
>> was to support the generation of PDF data from the buffer contents
>> directly using the Emacs redisplay engine, even from a tty session
>> (i.e., without X server running), rather than supporting multiple
>> window systems.  Showing a print dialog, sending the output to a
>> printer, etc. will need another library or something, perhaps in a
>> window-system dependent way.
>> 
>> Do you possibly have some idea of "abstraction on a higher level"?

> Ah, I see. Did you consider the printing already available in
> nXhtml?  This makes html pages from buffers (and also from frames
> for other purposes).

I've heard of the conversion from a buffer contents to html, but I
didn't know that it also supports the conversion from a frame.

Yes, conversion to html is useful and handy for many purposes.
Although the direct use of the Emacs redisplay engine in printing via
cairo has its strength in reproducibility of some peculiarities such
as compositions in Emacs display features, if people don't need them
in printing so much, then it might be rather overkill.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Lennart Borgman]

On Tue, May 8, 2012 at 4:15 AM, YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>> On Tue, 8 May 2012 03:25:33 +0200, Lennart Borgman <lennart.borgman@gmail.com> said:
>
>>> Actually, the primary motivation of introducing a cairo terminal
>>> was to support the generation of PDF data from the buffer contents
>>> directly using the Emacs redisplay engine, even from a tty session
>>> (i.e., without X server running), rather than supporting multiple
>>> window systems.  Showing a print dialog, sending the output to a
>>> printer, etc. will need another library or something, perhaps in a
>>> window-system dependent way.
>>>
>>> Do you possibly have some idea of "abstraction on a higher level"?
>
>> Ah, I see. Did you consider the printing already available in
>> nXhtml?  This makes html pages from buffers (and also from frames
>> for other purposes).
>
> I've heard of the conversion from a buffer contents to html, but I
> didn't know that it also supports the conversion from a frame.

That is just a minor convenience thing for those wanting to display
another type of screen shot.

> Yes, conversion to html is useful and handy for many purposes.
> Although the direct use of the Emacs redisplay engine in printing via
> cairo has its strength in reproducibility of some peculiarities such
> as compositions in Emacs display features, if people don't need them
> in printing so much, then it might be rather overkill.

If the goal is to produce a pdf file you can do that by first making a
html file and then display that in a web browser. From the web browser
you can then print or create a pdf.

What you get is just the buffer content (no extra headers or so), but
with colors.

Re: Printing

[Jason Rumney]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Is Cairo enough to make a general printing system? Should not the
> abstraction be on a higher level so that different OS:es can be
> supported?

Cairo is portable to many OS:es.  Are there any in particular which you
are concerned about being left out?

Re: Printing

[Lennart Borgman]

On Wed, May 9, 2012 at 4:50 PM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> Is Cairo enough to make a general printing system? Should not the
>> abstraction be on a higher level so that different OS:es can be
>> supported?
>
> Cairo is portable to many OS:es.  Are there any in particular which you
> are concerned about being left out?

Do you mean it is available and in use on w32?

Re: Printing

[Stefan Monnier]

[ Hi Simon! ]

> Is anyone already working for supporting multiple types of graphical
> terminals simultaneously?

Simon Leinen wanted to work on this a while ago, but I haven't heard
back from him about it, so I expect he was sufficiently busy with other
problems

It would be a great to be able to use a single Emacs that can display on
a w32 display as well as X11 remote displays.


        Stefan

Re: Printing

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ Hi Simon! ]
>
>> Is anyone already working for supporting multiple types of graphical
>> terminals simultaneously?

I'm also interested in this area.

The Emacs Xwidget branch has a proof-of-concept Cairo widget that can be
embedded in an Emacs buffer. There is also a POC Clutter widget. (there
isnt really much of an api to talk to these widgets yet, instead I
focused on the embeddable webkit widget)

Anyhow, a full blown Cairo port would be much more interesting of
course, but perhaps the concepts could be combined. 


>
> Simon Leinen wanted to work on this a while ago, but I haven't heard
> back from him about it, so I expect he was sufficiently busy with other
> problems
>
> It would be a great to be able to use a single Emacs that can display on
> a w32 display as well as X11 remote displays.
>
>
>         Stefan

-- 
Joakim Verona

Re: Printing

[Simon Leinen]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

>
> > Is anyone already working for supporting multiple types of graphical
> > terminals simultaneously?
>
> Simon Leinen wanted to work on this a while ago, but I haven't heard
> back from him about it, so I expect he was sufficiently busy with other
> problems
>

Unfortunately that's exactly true.  I never really got started with it, and
won't get to it in the near or medium future.  However I'm more than
willing to help test this if someone does start implementing this.

It would be a great to be able to use a single Emacs that can display on
> a w32 display as well as X11 remote displays.
>

For me the motivation was similar (except Mac/NextStep instead of w32), but
my current workaround is to just use X11 on the Mac.  Improved
TTY/X11(/...) coexistence could be another benefit.

I allow myself to quote some useful hints from a private mail you sent me
then (almost three years ago):

Stefan> It'd would be a good change, yes.   I don't think anybody has
started
Stefan> working on that (the same holds for w32+X11).
Stefan> IIUC, the work necessary to get it to work is as follows:
Stefan> - handle all the necessary renaming (many C functions have the same
name
Stefan>   in the different backends).  This may require introducing some
Stefan>   additional indirections to dynamically decide which of the backend
Stefan>   functions to use.  We already have such indirections (to choose
betwen
Stefan>   ty and GUI code), so most of the infrastructure should be there
Stefan>   already, but there's most likely still some things missing,
especially
Stefan>   for the features which don't exist under ttys.
Stefan> - change the various #ifdefs so that more than one of each GUI's
code
Stefan>   can be compiled in at the same time.
Stefan> - try and figure out what to do with all the remaining problems
(similar
Stefan>   to what you're saying about the indirect problems introduced by
the
Stefan>   multi-tty code, such as ssh-agent issues).  It'll probably be a
good
Stefan>   time to fix all the mess we still have around the "x-*" functions
Stefan>   (some of which are X11-specific but others aren't).

Best regards,
-- 
Simon.

[-- Attachment #2: Type: text/html, Size: 2921 bytes --]

Re: Printing

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 7 May 2012 19:20:35 +0200, Simon Leinen <simon.leinen@gmail.com> said:

>>> Is anyone already working for supporting multiple types of
>>> graphical terminals simultaneously?

>> Simon Leinen wanted to work on this a while ago, but I haven't
>> heard back from him about it, so I expect he was sufficiently busy
>> with other problems

> Unfortunately that's exactly true.  I never really got started with
> it, and won't get to it in the near or medium future.  However I'm
> more than willing to help test this if someone does start
> implementing this.

>> It would be a great to be able to use a single Emacs that can
>> display on a w32 display as well as X11 remote displays.

> For me the motivation was similar (except Mac/NextStep instead of
> w32), but my current workaround is to just use X11 on the Mac.
> Improved TTY/X11(/...) coexistence could be another benefit.

> I allow myself to quote some useful hints from a private mail you
> sent me then (almost three years ago):

Thanks for the info.  I guess adding a new type of output-only
graphical terminal for printing is much easier than supporting
multiple types of GUI terminals, because we don't have to care about
event handling for the former.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Printing

[Michael Ekstrand]

Андрей Парамонов <cmr.pent@gmail.com> writes:
> Having analysed mine and other users' experience, and having examined
> how the printing works in modern applications, I propose the following
> requirements for the Emacs printing mechanism:
>
> 1) Simple printing configuration should require no or almost no
>    knowledge and effort. The only user input that might be required is
>    the printer name.

If you have your printer set up correctly on your system, this should be
easy to do.  Setting it up correctly can be a challenge, but A., that
isn't an Emacs problem, and B., CUPS seems to do a good job of
auto-detecting USB and network printers these days.

> 2) It should not be necessary to install additional packages/files
>    solely for the Emacs printing.

I hope you mean packages beyond the core things needed to get printing
working on GNU/Linux systems in general (CUPS, GhostScript, hpijs for HP
printers, etc.).

> 3) Printing functionality should work equally good on PostScript and
>    non-PostScript printers.

Already covered in a properly configured environment (provided your
printer is supported by GhostScript/gimpprint/foomatic).

> I can think of the following ways of how these requirements may be
> achieved:
>
> a) Try to improve current functionality, making no or almost no
>    modifications to the current printing engine. This includes
>    simplifying the configuration interface. Not sure points 2) and 3)
>    can be fixed this way though.

2 and 3 are covered by this one as pretty much any Linux printing is
going through Postscript, even for non-Postscript printers; the printing
engine (e.g. CUPS) uses Ghostscript to render the PostScript to the
appropriate printer language.  The GTK+ printing systems are just
creating PostScript with Cairo, so far as I know.  If you can print on
your GNU/Linux system, you either have the appropriate conversion tools
or are talking to a PostScript printer (or print server doing the
conversion for you).

This solution also has the benefit of working in a TTY :).

I wouldn't mind, however, seeing the GTK+ UI able to use the GTK print
dialogs to select what printer to run the PostScript it generates
through.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

Re: Printing

[Stefan Monnier]

> 2) M-x ps-print-buffer-faces; the buffer is printed, but every
>    non-Latin character is replaced with '?'.

Yes, this is a serious problem that needs to be addressed.

> b) Use standard GTK+ printing facilities as GEdit and many other
>    applications do. Emacs is built with GTK+ interface for quite some
>    time now, so I suppose there should be no architectural problem in
>    using GTK+ for printing as well. Please correct me if I'm wrong.

This is a lot more difficult than it sounds: Emacs uses Gtk is very
non-essential ways (i.e. only for the scrollbars, toolbars, and
menubars, but not for the actual text).
It might be a good idea to try and do a real Gtk port of Emacs, tho.


        Stefan

Re: Printing

[Андрей Парамонов]

2009/3/28 Michael Ekstrand <michael@elehack.net>:
>> Having analysed mine and other users' experience, and having
>> examined how the printing works in modern applications, I propose
>> the following requirements for the Emacs printing mechanism:
>>
>> 1) Simple printing configuration should require no or almost no
>>    knowledge and effort. The only user input that might be required
>>    is the printer name.
>
> If you have your printer set up correctly on your system, this
> should be easy to do.

Yes, exactly, this should be easy. And it *is* easy in other
applications, namely GEdit, Firefox, etc. But unfortunately, it is not
easy in Emacs. That's why I've started the discussion.

Do you have a printer? If so, could you please print the contents of
Emacs 'Hello' buffer and tell us if all the characters you see on the
screen appear on the printed page as well?

>> 2) It should not be necessary to install additional packages/files
>>    solely for the Emacs printing.
>
> I hope you mean packages beyond the core things needed to get
> printing working on GNU/Linux systems in general (CUPS, GhostScript,
> hpijs for HP printers, etc.).

I mean that if you have all the fonts needed to render your text in
Emacs frame, and you can print that text using GEdit, you must not be
required to install anything else to be able to print from
Emacs. Currently, you must install so-called BDF fonts (in this case,
the quality would be inacceptably bad, but at least some non-Latin
characters would be printed), or you must install a web browser to be
able to use hfyview.el.

>> 3) Printing functionality should work equally good on PostScript
>>    and non-PostScript printers.
>
> Already covered in a properly configured environment (provided your
> printer is supported by GhostScript/gimpprint/foomatic).

I own a HP LaserJet 1018 which doesn't support PostScript directly, as
don't most of the consumer printers sold today. I'm not a PostScript
guru, but I'm pretty sure that my system indeed does some kind of
PostScript emulation, translating PostScript commands via GhostScript
and then telling the printer what to do in the language the latter
understands.

Maybe -- just maybe -- the Emacs printing works nicely on more
expensive printers which support PostScript directly. I can't tell for
sure because I don't have access to such a printer. As for my setup,
the printing functionality provided by Emacs works bad.

To clear things up: the problem is *not* in the printer, and *not* in
the drivers. Installing the printer on my system was a breeze. I've
encountered the only problematic application so far, and the
disappointing part is that it's Emacs.

Andrey Paramonov

Re: Printing

[Michael Ekstrand]

Андрей Парамонов <cmr.pent@gmail.com> writes:
> 2009/3/28 Michael Ekstrand <michael@elehack.net>:
>>> Having analysed mine and other users' experience, and having
>>> examined how the printing works in modern applications, I propose
>>> the following requirements for the Emacs printing mechanism:
>>>
>>> 1) Simple printing configuration should require no or almost no
>>>    knowledge and effort. The only user input that might be required
>>>    is the printer name.
>>
>> If you have your printer set up correctly on your system, this
>> should be easy to do.
>
> Yes, exactly, this should be easy. And it *is* easy in other
> applications, namely GEdit, Firefox, etc. But unfortunately, it is not
> easy in Emacs. That's why I've started the discussion.
>
> Do you have a printer? If so, could you please print the contents of
> Emacs 'Hello' buffer and tell us if all the characters you see on the
> screen appear on the printed page as well?

I tried it, using my HP PSC 2175 (so GhostScript/hpijs is doing the PS
to HP language conversion), and yes, it failed miserably on the vast
majority of the characters.

>>> 2) It should not be necessary to install additional packages/files
>>>    solely for the Emacs printing.
>>
>> I hope you mean packages beyond the core things needed to get
>> printing working on GNU/Linux systems in general (CUPS, GhostScript,
>> hpijs for HP printers, etc.).
>
> I mean that if you have all the fonts needed to render your text in
> Emacs frame, and you can print that text using GEdit, you must not be
> required to install anything else to be able to print from
> Emacs. Currently, you must install so-called BDF fonts (in this case,
> the quality would be inacceptably bad, but at least some non-Latin
> characters would be printed), or you must install a web browser to be
> able to use hfyview.el.

That is a reasonable expectation IMO.

>>> 3) Printing functionality should work equally good on PostScript
>>>    and non-PostScript printers.
>>
>> Already covered in a properly configured environment (provided your
>> printer is supported by GhostScript/gimpprint/foomatic).
>
> I own a HP LaserJet 1018 which doesn't support PostScript directly, as
> don't most of the consumer printers sold today. I'm not a PostScript
> guru, but I'm pretty sure that my system indeed does some kind of
> PostScript emulation, translating PostScript commands via GhostScript
> and then telling the printer what to do in the language the latter
> understands.
>
> Maybe -- just maybe -- the Emacs printing works nicely on more
> expensive printers which support PostScript directly. I can't tell for
> sure because I don't have access to such a printer. As for my setup,
> the printing functionality provided by Emacs works bad.
>
> To clear things up: the problem is *not* in the printer, and *not* in
> the drivers. Installing the printer on my system was a breeze. I've
> encountered the only problematic application so far, and the
> disappointing part is that it's Emacs.

OK.  I misunderstood the framing of the problem.  With this
clarification, I agree, the problem is a valid one and a solution should
be found somehow.  I do believe that the solution with the best results
will be to enhance the PostScript generation to properly handle the
non-latin characters, although this does not seem to be an easy task.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

Re: Printing

[Stefan Monnier]

>> I own a HP LaserJet 1018 which doesn't support PostScript directly, as
>> don't most of the consumer printers sold today. I'm not a PostScript
>> guru, but I'm pretty sure that my system indeed does some kind of
>> PostScript emulation, translating PostScript commands via GhostScript
>> and then telling the printer what to do in the language the latter
>> understands.

AFAIK, there are mainly 2 problems:
1 - Printing non-ascii chars is poorly supported.
2 - Printing on systems that do not support Postscript.

The second problem is less important to the extent that it only affects
proprietary operating systems, AFAIK, and it can be solved by installing
additional Free Software (mostly Ghostscript).

A further problem is the lack of "printing dialog" to choose the printer
and the printing style.


        Stefan

Re: Printing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 30 Mar 2009 11:24:35 -0400
> Cc: emacs-devel@gnu.org
> 
> 1 - Printing non-ascii chars is poorly supported.
> 2 - Printing on systems that do not support Postscript.
> 
> The second problem is less important to the extent that it only affects
> proprietary operating systems, AFAIK, and it can be solved by installing
> additional Free Software (mostly Ghostscript).

The second problem is simply irrelevant: if the printer supports
PostScript, the OS is not important, because all modern OSs support
PostScript printers.

IOW, there's no such thing as a ``system that doesn't support
PostScript''.

Re: Printing

[Stefan Monnier]

>> The second problem is less important to the extent that it only affects
>> proprietary operating systems, AFAIK, and it can be solved by installing
>> additional Free Software (mostly Ghostscript).

> The second problem is simply irrelevant: if the printer supports
> PostScript, the OS is not important, because all modern OSs support
> PostScript printers.

By "the system" I mean "the hardware & OS on which Emacs runs".
For Emacs to be able to print, the system (either the printer or some
part of the software) needs to support Postscript.

Printers that don't understand Postscript are still pretty common,
AFAIK.  And Windows doesn't provide Postscript support for
non-Postscript printers unless you install ghostscript.  So it's
not irrelevant.


        Stefan

Re: Printing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: michael@elehack.net,  emacs-devel@gnu.org
> Date: Mon, 30 Mar 2009 21:56:51 -0400
> 
> >> The second problem is less important to the extent that it only affects
> >> proprietary operating systems, AFAIK, and it can be solved by installing
> >> additional Free Software (mostly Ghostscript).
> 
> > The second problem is simply irrelevant: if the printer supports
> > PostScript, the OS is not important, because all modern OSs support
> > PostScript printers.
> 
> By "the system" I mean "the hardware & OS on which Emacs runs".
> For Emacs to be able to print, the system (either the printer or some
> part of the software) needs to support Postscript.
> 
> Printers that don't understand Postscript are still pretty common,
> AFAIK.  And Windows doesn't provide Postscript support for
> non-Postscript printers unless you install ghostscript.  So it's
> not irrelevant.

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.  Because if you do, the history of
that until today should tell us this is not necessarily a good idea.

Re: Printing

[Stefan Monnier]

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

> Because if you do, the history of that until today should tell us this
> is not necessarily a good idea.

What other way to print are you thinking of?


        Stefan

Re: Printing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: michael@elehack.net,  emacs-devel@gnu.org
> Date: Tue, 31 Mar 2009 20:52:33 -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.

> > Because if you do, the history of that until today should tell us this
> > is not necessarily a good idea.
> 
> 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.  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.

Re: Printing

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.

But that's exactly what postscript _is_ -- a printer API that lets you
select fonts and layout and then renders text to some device....

It's sad that some printers don't support it, but it's not like the
alternatives are much more dependable (maybe pdf is, these days, but
it's basically postscript, so maybe something could be worked out).

-Miles

-- 
Cat, n. A soft, indestructible automaton provided by nature to be kicked when
things go wrong in the domestic circle.

Re: Printing

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, michael@elehack.net,
>         emacs-devel@gnu.org
> Date: Wed, 01 Apr 2009 13:17:52 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> 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.
> 
> But that's exactly what postscript _is_ -- a printer API that lets you
> select fonts and layout and then renders text to some device....

Obviously, there are some problems, since non-ASCII support in
ps-print still needs a lot of tinkering and intimate knowledge of what
your printing infrastructure supports.  This basically didn't change
since ps-mule was added about 10 years ago.  There were good
intentions to add support for Type1 fonts, but 10 years later there
still is no ps-type1.el, and what BDF fonts produce in print is simply
too ugly to be palatable.

Re: Printing

[Jason Rumney]

Eli Zaretskii wrote:
> 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.  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.
>   

The problem is that the way Emacs renders text, even in GUI toolkits, is 
based more on the way text is rendered on tty devices than on the 
standard way of rendering text in the GUI toolkit. That does make it 
somewhat harder to teach Emacs to render to a printer than it is for 
other native GTK, NS or Windows apps. ps-print is probably actually 
closer to what we need as a starting point than the existing redisplay 
code, as it already takes care of pagination (albeit assuming a constant 
font height apart from the header and footer), which is usually the 
difficult part of implementing printing support in a GUI app.

FWIW, I agree that printing would be better done that way, but given the 
complications of understanding and modifying the existing redisplay 
code, it will probably be another 10 years before it is, and will 
probably come out of something like a port of Emacs redisplay to cairo 
rather than a dedicated effort to add printing support to existing 
platform specific code.

Re: Printing

[Eli Zaretskii]

> Date: Wed, 01 Apr 2009 12:24:41 +0800
> From: Jason Rumney <jasonr@gnu.org>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>, michael@elehack.net, 
>  emacs-devel@gnu.org
> 
> The problem is that the way Emacs renders text, even in GUI toolkits, is 
> based more on the way text is rendered on tty devices than on the 
> standard way of rendering text in the GUI toolkit. That does make it 
> somewhat harder to teach Emacs to render to a printer than it is for 
> other native GTK, NS or Windows apps.

Perhaps we could use some third-party library that does the hard
work.

> FWIW, I agree that printing would be better done that way, but given the 
> complications of understanding and modifying the existing redisplay 
> code, it will probably be another 10 years before it is

ps-mule was introduced 10 years ago, and we are still basically in the
same place as far as non-ASCII printing is concerned.  So obviously
it's not like ps-print is going to get better in that area tomorrow.

Re: Printing

[Stephen J. Turnbull]

Eli Zaretskii writes:

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

FWIW, XEmacs has an msprinter device for exactly this purpose.  AFAIK,
our Windows users are mostly satisfied with printing per se, although
our printer config dialog seems rife with nasty regressions. :-(

Re: Printing

[Stefan Monnier]

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

>> > Because if you do, the history of that until today should tell us this
>> > is not necessarily a good idea.
>> 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,
... so generating Postscript is not at all contradictory with the desire
to provide the usual printer dialog.

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


        Stefan

Re: Printing

[Eli Zaretskii]

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

Re: Printing

[Stefan Monnier]

> PostScript is supported well on both free and proprietary platforms,
> you are missing the point.

I may be missing the point, but Postscript is not supported well
under Windows.

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

Point taken,


        Stefan

Re: Printing

[Richard M Stallman]

    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.

This is not the right way to choose the method for solving a problem.
How much people have worked on this in the past is beside the point.

The real question about printing non-ASCII text is what needs to be
done to make ps-print handle more character sets, and what the
obstacles are.

      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.

Supporting application-specific APIs could be a big pain in the neck.
Each one of them could be a big pain in the neck.  It might be a lot
easier to make ps-print find the necessary fonts, if that can be dne
in a mostly portable way, than to support several totally different
printing APIs.

If supporting these printing APIs requires redesigning Emacs
redisplay, that would yoke this big task to an even bigger task which
might be a mistake anyway.  It would take many years to redo redisplay
and fix the bugs.  Interfaces such as Cairo would probably impede
portability even if they are not 100% unportable, and they might also
cause a slowdown in redisplay.

I if you want a good chance of making progress happen, I suggest you
start working on the solitions that are much easier, even if they are
difficult in absolute terms.

Would you like to collect the docs of the APIs used for finding and
specifying fonts on the various systems, so people can see what work
is really involved in supporting them?

Re: Printing

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, michael@elehack.net, emacs-devel@gnu.org
> Date: Thu, 02 Apr 2009 09:02:19 -0400
> 
>     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.
> 
> This is not the right way to choose the method for solving a problem.
> How much people have worked on this in the past is beside the point.

It's not beside the point: it can give us some idea how many people
are likely to work on it in the future.

> The real question about printing non-ASCII text is what needs to be
> done to make ps-print handle more character sets, and what the
> obstacles are.

I suspect there are no people among active contributors to Emacs who
know that.  Otherwise, they would have already solved this.

> Supporting application-specific APIs could be a big pain in the neck.
> Each one of them could be a big pain in the neck.

It could, but then again it could be much easier, too.

> Would you like to collect the docs of the APIs used for finding and
> specifying fonts on the various systems, so people can see what work
> is really involved in supporting them?

I will add this to my todo, but it's so long that there's no knowing
if I ever get to doing that.  Nor am I the ideal candidate, for that
matter: I'm not much of an expert on these APIs, I know only a couple
of them, and only very superficially.

Re: Printing

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 01, 2009 at 06:14:59AM +0300, Eli Zaretskii wrote:

[...]

> > 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,
[...]

Hm. I know that's the modern "trend", but I am unconvinced that it is in
the end a Good Thing. Implement all those interfaces for
$rendering_system_du_jour (GTK, QT, Windows 32, whatever) instead of
going for one more or less abstract (Postscript, PDF), well-documented
and widely implemented?

What next: implement the virtual file systems on the graphics toolkit?
Oh, wait...

(sorry if it sounds too ranty: it isn't personal. But watching all the
desktop environments implement things which belong to other layers of
the system is painful, especially in the Free Software context).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ1I6WBcgs9XrR2kYRAoD+AJ99+hGyjdIpFcWUkYWC/cIGdP710wCfWMpg
Pamv7XloQkOBuPlf4x/yj0A=
=2ezH
-----END PGP SIGNATURE-----

Re: Printing

[Lennart Borgman]

On Thu, Apr 2, 2009 at 12:08 PM,  <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, Apr 01, 2009 at 06:14:59AM +0300, Eli Zaretskii wrote:
>
> [...]
>
>> > 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,
> [...]
>
> Hm. I know that's the modern "trend", but I am unconvinced that it is in
> the end a Good Thing. Implement all those interfaces for
> $rendering_system_du_jour (GTK, QT, Windows 32, whatever) instead of
> going for one more or less abstract (Postscript, PDF), well-documented
> and widely implemented?

Is not this reality versus ideality? I think most users on different
systems will appreciate that we use the API:s for that system. They
will know what to do at once then without having to relearn.

And a simple way to do this is to use an intermediate layer like wxwidgets.

Re: Printing

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 02, 2009 at 12:52:25PM +0200, Lennart Borgman wrote:

[...]

> Is not this reality versus ideality? I think most users on different
> systems will appreciate that we use the API:s for that system. They
> will know what to do at once then without having to relearn.

In a way, yes, but I think my rant still holds. Even while there is some
truth to what you say above, you are conflating API with "user
interface" ("most users ...will appreciate that we use the APIs... they
will know..."). See? That is the think coming from Microsoft and Apple:
One Big System, from device driver up to desktop environment. And we are
copying that (but I'm getting seriously off-topic with that by now, I
fear).

> And a simple way to do this is to use an intermediate layer like wxwidgets.

For printing? Well, that's what my rant was about :-)

Look at the Gnome guys. There is mount, there is FUSE (I'm sure BSDs
have something similar). Why VFS? Why invent a new way of "mounting"
"file systems" which is dependent on some random desktop environment?
(KDE ain't better in this!).

In our printer case I'd propose to start recognizing that we have
several layers:

  (1) how to render
  (2) how to choose a printer
  (3) how to configure the capabilities of a printer

For (1), I think we'd be fine if we managed to render utf-8 via
one of ps or pdf properly. (2) and (3) might be in the realm of CUPS,
perhaps?

Showing the "standard" "system" "printer dialog box" would fulfill your
proposal above, but that is now an entirely separate point.

Regards, and thanks for beearing with my rant :)

- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJ1Ka3Bcgs9XrR2kYRAumVAKCBkVeZ9oVfA0VPpev19GZ67W7xeQCZAdDM
dm+VOpzR4qTYun4PmIpUFCE=
=bhyn
-----END PGP SIGNATURE-----

Re: Printing

[Lennart Borgman]

On Thu, Apr 2, 2009 at 1:51 PM,  <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Apr 02, 2009 at 12:52:25PM +0200, Lennart Borgman wrote:
>
> [...]
>
>> Is not this reality versus ideality? I think most users on different
>> systems will appreciate that we use the API:s for that system. They
>> will know what to do at once then without having to relearn.
>
> In a way, yes, but I think my rant still holds. Even while there is some
> truth to what you say above, you are conflating API with "user
> interface" ("most users ...will appreciate that we use the APIs... they
> will know..."). See?

You have a point, but using these API:s you get the standard UI.


>> And a simple way to do this is to use an intermediate layer like wxwidgets.
>
> For printing? Well, that's what my rant was about :-)
>
> Look at the Gnome guys. There is mount, there is FUSE (I'm sure BSDs
> have something similar). Why VFS? Why invent a new way of "mounting"
> "file systems" which is dependent on some random desktop environment?
> (KDE ain't better in this!).
>
> In our printer case I'd propose to start recognizing that we have
> several layers:
>
>  (1) how to render
>  (2) how to choose a printer
>  (3) how to configure the capabilities of a printer
>
> For (1), I think we'd be fine if we managed to render utf-8 via
> one of ps or pdf properly. (2) and (3) might be in the realm of CUPS,
> perhaps?
>
> Showing the "standard" "system" "printer dialog box" would fulfill your
> proposal above, but that is now an entirely separate point.
>
> Regards, and thanks for beearing with my rant :)

Writing a pdf-file would of course allow printing on w32 more simple
too - if you install some software to read and print pdf.

Re: Printing

[Stefan Monnier]

> Writing a pdf-file would of course allow printing on w32 more simple
> too - if you install some software to read and print pdf.

Considering that I'd rather not encourage people to install proprietary
software, is it really significantly easier to install support for
printing PDF than support for printing Postscript (in Windows)?


        Stefan


PS: This said, I agree that pdf-print.el would be welcome.

Re: Printing

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Writing a pdf-file would of course allow printing on w32 more simple
>> too - if you install some software to read and print pdf.
>
> Considering that I'd rather not encourage people to install proprietary
> software,

Ghostscript/GSView can display (and print) pdf. It is possible to
install other Free pdf viewers on Windows such as the ones created for
KDE, but not easy.

> is it really significantly easier to install support for printing PDF
> than support for printing Postscript (in Windows)?

AFAIK, restricting ourselves to Free software, no.

-- 
Oscar

Re: Printing

[Samuel Bronson]

On Thu, Apr 2, 2009 at 9:47 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> is it really significantly easier to install support for printing PDF
>> than support for printing Postscript (in Windows)?
>
> AFAIK, restricting ourselves to Free software, no.

If we were doing that, we wouldn't be in that mess in the first place
-- we'd not be using Windows!

Installing Adobe Reader is surely easier than figuring out how to get
ghostscript set up on windows, no?

Re: Printing

[Óscar Fuentes]

Samuel Bronson <naesten@gmail.com> writes:

>>> is it really significantly easier to install support for printing PDF
>>> than support for printing Postscript (in Windows)?
>>
>> AFAIK, restricting ourselves to Free software, no.
>
> If we were doing that, we wouldn't be in that mess in the first place
> -- we'd not be using Windows!

IIRC, it is a policy of the FSF to discourage using propietary software
for any purpose, even less to require it for adding capabilities to a
Free software package.

> Installing Adobe Reader is surely easier than figuring out how to get
> ghostscript set up on windows, no?

Driving Adobe Reader from an external application (or from the command
line) for printing is tricky: it relies on undocumented features that
changes with each version. OTOH, starting it for document viewing is
easy (although sometimes refuses to work). For printing purposes,
waiting for the pdf reader to start, then printing from it, is an
annoyance if you need to print often.

-- 
Oscar

Re: Printing

[Lennart Borgman]

On Thu, Apr 2, 2009 at 4:24 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Driving Adobe Reader from an external application (or from the command
> line) for printing is tricky: it relies on undocumented features that
> changes with each version. OTOH, starting it for document viewing is
> easy (although sometimes refuses to work). For printing purposes,
> waiting for the pdf reader to start, then printing from it, is an
> annoyance if you need to print often.

If it is already started it shows a new document fast. And for w32 it
is surely an easier alternative than most others. (I myself use the
web browser + htmlfontify trick for printing. It is good enough for
me, but I guess ps-print gives more flexibility.)

Re: Printing

[Lennart Borgman]

On Thu, Apr 2, 2009 at 3:37 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Writing a pdf-file would of course allow printing on w32 more simple
>> too - if you install some software to read and print pdf.
>
> Considering that I'd rather not encourage people to install proprietary
> software, is it really significantly easier to install support for
> printing PDF than support for printing Postscript (in Windows)?


Yes, I think so since most people already have a viewer for PDF
installed. And that viewer can be used to print.

Re: Printing

[Stefan Monnier]

>>> Writing a pdf-file would of course allow printing on w32 more simple
>>> too - if you install some software to read and print pdf.
>> Considering that I'd rather not encourage people to install proprietary
>> software, is it really significantly easier to install support for
>> printing PDF than support for printing Postscript (in Windows)?
> Yes, I think so since most people already have a viewer for PDF
> installed. And that viewer can be used to print.

AFAIK, Windows comes neither with a Postscript viewer/printer nor with
a PDF viewer/printer.  So for ps-print.el we have to ask people to
install Ghostscript on such systems.  Assuming we had pdf-print.el,
which other software would we tell people to install?  As mentioned
non-proprietary options are unacceptable.

This said, maybe ps-print.el could be changed so it can run `gs'
directly (under Windows); this would mean that the user only needs to
install Ghostscript without configuring something like redmon and
creating a special postscript virtual printer.


        Stefan

Re: Printing

[Reiner Steib]

On Thu, Apr 02 2009, Stefan Monnier wrote:

> AFAIK, Windows comes neither with a Postscript viewer/printer nor with
> a PDF viewer/printer.  So for ps-print.el we have to ask people to
> install Ghostscript on such systems.  Assuming we had pdf-print.el,
> which other software would we tell people to install?  As mentioned
> non-proprietary options are unacceptable.

Ghostscript?  ;-)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Printing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: tomas@tuxteam.de,  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 02 Apr 2009 12:15:23 -0400
> 
> AFAIK, Windows comes neither with a Postscript viewer/printer nor with
> a PDF viewer/printer.

True.

> This said, maybe ps-print.el could be changed so it can run `gs'
> directly (under Windows); this would mean that the user only needs to
> install Ghostscript without configuring something like redmon and
> creating a special postscript virtual printer.

There's no need for these complications.  Installing Ghostscript on
Windows is very easy, and once installed, it can immediately be used
to print with ps-print to any Windows printer; no need for redmon or
virtual printers.  The instructions to configure Emacs on Windows to
do that are in the Emacs manual.

Again, this thread was not about PostScript printing in general:
setting that up is almost trivially easy (although I personally think
that printouts produced by Ghostscript are ugly).  The problem was
with printing non-ASCII text, and that needs to be solved in ps-print
and ps-mule, not in external applications.

Re: Printing

[Stefan Monnier]

> There's no need for these complications.  Installing Ghostscript on
> Windows is very easy, and once installed, it can immediately be used
> to print with ps-print to any Windows printer; no need for redmon or
> virtual printers.  The instructions to configure Emacs on Windows to
> do that are in the Emacs manual.

Wonderful, thanks.

> The problem was with printing non-ASCII text, and that needs to be
> solved in ps-print and ps-mule, not in external applications.

This thread has mentioned several issues, the non-ASCII chars being one
of them.  I think it's the main one at this point, indeed.


        Stefan

Re: Printing

[Lennart Borgman]

On Thu, Apr 2, 2009 at 6:15 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>> Writing a pdf-file would of course allow printing on w32 more simple
>>>> too - if you install some software to read and print pdf.
>>> Considering that I'd rather not encourage people to install proprietary
>>> software, is it really significantly easier to install support for
>>> printing PDF than support for printing Postscript (in Windows)?
>> Yes, I think so since most people already have a viewer for PDF
>> installed. And that viewer can be used to print.
>
> AFAIK, Windows comes neither with a Postscript viewer/printer nor with
> a PDF viewer/printer.  So for ps-print.el we have to ask people to
> install Ghostscript on such systems.  Assuming we had pdf-print.el,
> which other software would we tell people to install?  As mentioned
> non-proprietary options are unacceptable.
>
> This said, maybe ps-print.el could be changed so it can run `gs'
> directly (under Windows); this would mean that the user only needs to
> install Ghostscript without configuring something like redmon and
> creating a special postscript virtual printer.

An easy way would perhaps be to write a temporary pdf-file and then
call w32-shell-execute on that file with "print" as the operation.

Re: Printing

[Lennart Borgman]

On Thu, Apr 2, 2009 at 10:56 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> An easy way would perhaps be to write a temporary pdf-file and then
> call w32-shell-execute on that file with "print" as the operation.

Just tested with

  (w32-shell-execute "print" "MY-PDF-FILE")

This just sends the file MY-PDF-FILE to the printer with Acrobat.
Could perhaps someone test with GhostScript?

Re: Printing

[Stefan Monnier]

> This just sends the file MY-PDF-FILE to the printer with Acrobat.

Last I heard Acrobat is not Free.


        Stefan

Re: Printing

[Lennart Borgman]

On Sat, Apr 4, 2009 at 2:36 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> This just sends the file MY-PDF-FILE to the printer with Acrobat.
>
> Last I heard Acrobat is not Free.

If the user has installed a free pdf-viewer then w32-shell-execute may
work the same way as it did for me with Acrobat. That is what I
proposed that someone with a free pdf-viewer should test.

If it does not work as it should then there is a problem with the free
pdf-viewer (which we can suggest to the developers to fix).

Re: Printing

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>>> This just sends the file MY-PDF-FILE to the printer with Acrobat.
>>
>> Last I heard Acrobat is not Free.
>
> If the user has installed a free pdf-viewer then w32-shell-execute may
> work the same way as it did for me with Acrobat. That is what I
> proposed that someone with a free pdf-viewer should test.
>
> If it does not work as it should then there is a problem with the free
> pdf-viewer (which we can suggest to the developers to fix).

Not a problem, but an unimplemented feature.

The method you suggest sends the full document to the default printer,
no questions asked. This is not very user friendly.

-- 
Oscar

Re: Printing

[Lennart Borgman]

On Sat, Apr 4, 2009 at 3:05 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>>>> This just sends the file MY-PDF-FILE to the printer with Acrobat.
>>>
>>> Last I heard Acrobat is not Free.
>>
>> If the user has installed a free pdf-viewer then w32-shell-execute may
>> work the same way as it did for me with Acrobat. That is what I
>> proposed that someone with a free pdf-viewer should test.
>>
>> If it does not work as it should then there is a problem with the free
>> pdf-viewer (which we can suggest to the developers to fix).
>
> Not a problem, but an unimplemented feature.
>
> The method you suggest sends the full document to the default printer,
> no questions asked. This is not very user friendly.

Hm, yes you are right, there is no print dialog. I do not know if
there is another verb than "print" that can be used as argument to
w32-shell-execute to get the print dialog.

A free viewer can anyway implement such a new verb.

Re: Printing

[Eli Zaretskii]

> Date: Sat, 4 Apr 2009 02:00:00 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: tomas@tuxteam.de, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> On Thu, Apr 2, 2009 at 10:56 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
> > An easy way would perhaps be to write a temporary pdf-file and then
> > call w32-shell-execute on that file with "print" as the operation.
> 
> Just tested with
> 
>   (w32-shell-execute "print" "MY-PDF-FILE")
> 
> This just sends the file MY-PDF-FILE to the printer with Acrobat.
> Could perhaps someone test with GhostScript?

Test what?  The Emacs manual already says how to set up Emacs for
printing with Ghostscript; please see the node "Windows Printing".
The setup described there worked last time I tested it.

Re: Printing

[Lennart Borgman]

On Sat, Apr 4, 2009 at 10:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 4 Apr 2009 02:00:00 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: tomas@tuxteam.de, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>>
>> On Thu, Apr 2, 2009 at 10:56 PM, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>> > An easy way would perhaps be to write a temporary pdf-file and then
>> > call w32-shell-execute on that file with "print" as the operation.
>>
>> Just tested with
>>
>>   (w32-shell-execute "print" "MY-PDF-FILE")
>>
>> This just sends the file MY-PDF-FILE to the printer with Acrobat.
>> Could perhaps someone test with GhostScript?
>
> Test what?

If the above works with GhostScript.

> The Emacs manual already says how to set up Emacs for
> printing with Ghostscript; please see the node "Windows Printing".
> The setup described there worked last time I tested it.
>
>
>

Re: Printing

[Eli Zaretskii]

> Date: Sat, 4 Apr 2009 11:22:13 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: tomas@tuxteam.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> >> Just tested with
> >>
> >>   (w32-shell-execute "print" "MY-PDF-FILE")
> >>
> >> This just sends the file MY-PDF-FILE to the printer with Acrobat.
> >> Could perhaps someone test with GhostScript?
> >
> > Test what?
> 
> If the above works with GhostScript.

Like I said, how to set printing with Ghostscript is already explained
in the manual.  That setup uses a general Emacs infrastructure, not
the w32-specific w32-shell-execute.

Re: Printing

[James Cloos]

This is indeed a real issue.  Some slightly random thoughts:

Using the gtk print dialog when emacs is compiled --with-x-toolkit-gtk
and is in GUI mode would be a useful improvement.  (Using the toolkit's
print dialog is generally the way to go, but of the x-toolkits emacs
currently supports only gtk has a useful print dialog.)

The cups-based workflow is changing from postscript to pdf.  It would be
useful for emacs to have pdf-(print|spool)-(buffer|region)(-with-faces)?
commands.  A pdf-print.el similar to ps-print.el is therefore desired.

Work is underway on a pan-toolkit print dialog.  One of the deliverables
is an application which can be used in place of lp(1) or lpr(1).  This
will be similar to xpp(1) or gtklp(1), but using the new dialog.  I
expect there will be separate apps for each toolkit linked against the
pan-toolkit lib.  It would be useful for ps-lpr-command to default to
such an app when using gtk and in GUI mode.  Until that app is available
gtklp might be a useful option.

Anything which outputs pdf can be trivially expanded to support ps
output as well; it requires only a simple ps procset and a few small
conditionals in the code.  Most of the ps output looks identical to
the pdf output.

Improving ps-print.el to support all of the UCS is not outrageously
difficult.  I'm confident patches would be welcomed.  There are a large
number of acceptably-licensed apps and libs in the wild which one could
use as inspiration.  Cairo's pdf backend is a good example.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Printing

[Richard M Stallman]

    Emacs printing is broken -- and I mean it -- is *fundamentally*,
    totally broken. You have either to be a PostScript guru, restrict
    yourself to ASCII characters, or cheat/hack to be able to use Emacs
    printing.

I am sure that is not true.  I am not a PostScript guru, but when I
use ps-print-buffer, it works fine.

This is not to say that there can't be bugs.  I see you included
some test cases -- thank you for them.  I hope people will fix them.

    b) Use standard GTK+ printing facilities as GEdit and many other
       applications do. Emacs is built with GTK+ interface for quite some
       time now, so I suppose there should be no architectural problem in
       using GTK+ for printing as well. Please correct me if I'm wrong.

Sorry, that won't work.  Emacs can be built with several display
platforms, GTK being just one.  Sometimes none is used.  I normally
use Emacs on a tty and I want printing to work there too.

Re: Printing

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> Date: Sat, 28 Mar 2009 22:15:42 -0400
> Cc: emacs-devel@gnu.org
> 
>     Emacs printing is broken -- and I mean it -- is *fundamentally*,
>     totally broken. You have either to be a PostScript guru, restrict
>     yourself to ASCII characters, or cheat/hack to be able to use Emacs
>     printing.
> 
> I am sure that is not true.  I am not a PostScript guru, but when I
> use ps-print-buffer, it works fine.

It works fine out of the box for ASCII and Latin-1 characters.
Outside that area, ps-print needs non-trivial setup.  Note that the OP
said "restrict yourself to ASCII characters".

Re: Printing

[Richard M Stallman]

    It works fine out of the box for ASCII and Latin-1 characters.
    Outside that area, ps-print needs non-trivial setup.

What setup does it need?  Why is it needed?

If the user invokes it without doing this setup,
does it warn the user it won't work?

Re: Printing

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: cmr.pent@gmail.com, emacs-devel@gnu.org
> Date: Sun, 29 Mar 2009 21:17:07 -0400
> 
>     It works fine out of the box for ASCII and Latin-1 characters.
>     Outside that area, ps-print needs non-trivial setup.
> 
> What setup does it need?

See the commentary at the beginning of ps-mule.el.

> Why is it needed?

Because ps-print needs to know how to send non-ASCII characters to the
printer.  Characters from scripts that the printer supports directly
can be sent verbatim (encoded by a suitable coding-system).  Other
characters need to be downloaded into the printer before we can use
them.

> If the user invokes it without doing this setup,
> does it warn the user it won't work?

If some of the characters in the region you print don't have a
corresponding entry in ps-mule-font-info-database, it says something
vague about "some characters will not be printed".  If all of them
have entries, but the entries do not correctly reflect what the
printer can or cannot do, you get bad printout with no warning at all.

One way to fix this would be to update our default for
ps-mule-font-info-database so that it handles Unicode -- assuming that
modern PostScript printers indeed support large subranges of the
Unicode codespace.  I'm not an expert on printing, so I wouldn't know
if this is possible.

Re: Printing

[Lennart Borgman]

On Mon, Mar 30, 2009 at 5:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> One way to fix this would be to update our default for
> ps-mule-font-info-database so that it handles Unicode -- assuming that
> modern PostScript printers indeed support large subranges of the
> Unicode codespace.  I'm not an expert on printing, so I wouldn't know
> if this is possible.

Since printing with Emacs through the web browser (using
htmlfontify.el) does work it seems like modern printers do support
this. Or am I missing something?

Re: Printing

[Eli Zaretskii]

> Date: Mon, 30 Mar 2009 08:36:01 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> 
> On Mon, Mar 30, 2009 at 5:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > One way to fix this would be to update our default for
> > ps-mule-font-info-database so that it handles Unicode -- assuming that
> > modern PostScript printers indeed support large subranges of the
> > Unicode codespace.  I'm not an expert on printing, so I wouldn't know
> > if this is possible.
> 
> Since printing with Emacs through the web browser (using
> htmlfontify.el) does work it seems like modern printers do support
> this. Or am I missing something?

You are missing the fact that I was talking about PostScript printing,
not printing via the Windows printer API.

Re: Printing

[Lennart Borgman]

On Mon, Mar 30, 2009 at 8:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 30 Mar 2009 08:36:01 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
>>
>> On Mon, Mar 30, 2009 at 5:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > One way to fix this would be to update our default for
>> > ps-mule-font-info-database so that it handles Unicode -- assuming that
>> > modern PostScript printers indeed support large subranges of the
>> > Unicode codespace.  I'm not an expert on printing, so I wouldn't know
>> > if this is possible.
>>
>> Since printing with Emacs through the web browser (using
>> htmlfontify.el) does work it seems like modern printers do support
>> this. Or am I missing something?
>
> You are missing the fact that I was talking about PostScript printing,
> not printing via the Windows printer API.

I am not sure about that. Could someone who have this problem and have
a PostScript printer try printing through the web browser, please?

Re: Printing

[Eli Zaretskii]

> Date: Mon, 30 Mar 2009 21:04:37 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> 
> On Mon, Mar 30, 2009 at 8:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Mon, 30 Mar 2009 08:36:01 +0200
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> >>
> >> On Mon, Mar 30, 2009 at 5:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> > One way to fix this would be to update our default for
> >> > ps-mule-font-info-database so that it handles Unicode -- assuming that
> >> > modern PostScript printers indeed support large subranges of the
> >> > Unicode codespace.  I'm not an expert on printing, so I wouldn't know
> >> > if this is possible.
> >>
> >> Since printing with Emacs through the web browser (using
> >> htmlfontify.el) does work it seems like modern printers do support
> >> this. Or am I missing something?
> >
> > You are missing the fact that I was talking about PostScript printing,
> > not printing via the Windows printer API.
> 
> I am not sure about that. Could someone who have this problem and have
> a PostScript printer try printing through the web browser, please?

And that will prove what, exactly? that Windows knows how to use a PS
driver for a printer?

Re: Printing

[Lennart Borgman]

On Mon, Mar 30, 2009 at 10:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 30 Mar 2009 21:04:37 +0200
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
>>
>> On Mon, Mar 30, 2009 at 8:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Mon, 30 Mar 2009 08:36:01 +0200
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
>> >>
>> >> On Mon, Mar 30, 2009 at 5:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> > One way to fix this would be to update our default for
>> >> > ps-mule-font-info-database so that it handles Unicode -- assuming that
>> >> > modern PostScript printers indeed support large subranges of the
>> >> > Unicode codespace.  I'm not an expert on printing, so I wouldn't know
>> >> > if this is possible.
>> >>
>> >> Since printing with Emacs through the web browser (using
>> >> htmlfontify.el) does work it seems like modern printers do support
>> >> this. Or am I missing something?
>> >
>> > You are missing the fact that I was talking about PostScript printing,
>> > not printing via the Windows printer API.
>>
>> I am not sure about that. Could someone who have this problem and have
>> a PostScript printer try printing through the web browser, please?
>
> And that will prove what, exactly? that Windows knows how to use a PS
> driver for a printer?

I think that the browser will send PostScript to the printer. So I
believe it will show that the printer actually can print all the text
- but I am sure I might be missing something here.

Re: Printing

[Eli Zaretskii]

> Date: Mon, 30 Mar 2009 22:53:04 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> 
> On Mon, Mar 30, 2009 at 10:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Mon, 30 Mar 2009 21:04:37 +0200
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> >>
> >> On Mon, Mar 30, 2009 at 8:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> Date: Mon, 30 Mar 2009 08:36:01 +0200
> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> >> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> >> >>
> >> >> On Mon, Mar 30, 2009 at 5:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> > One way to fix this would be to update our default for
> >> >> > ps-mule-font-info-database so that it handles Unicode -- assuming that
> >> >> > modern PostScript printers indeed support large subranges of the
> >> >> > Unicode codespace.  I'm not an expert on printing, so I wouldn't know
> >> >> > if this is possible.
> >> >>
> >> >> Since printing with Emacs through the web browser (using
> >> >> htmlfontify.el) does work it seems like modern printers do support
> >> >> this. Or am I missing something?
> >> >
> >> > You are missing the fact that I was talking about PostScript printing,
> >> > not printing via the Windows printer API.
> >>
> >> I am not sure about that. Could someone who have this problem and have
> >> a PostScript printer try printing through the web browser, please?
> >
> > And that will prove what, exactly? that Windows knows how to use a PS
> > driver for a printer?
> 
> I think that the browser will send PostScript to the printer.

Yes, it will.

> So I believe it will show that the printer actually can print all
> the text

Not necessarily: PostScript language includes a capability to download
characters and images to the printer.  So the fact that something is
on paper does not yet mean it was printed using fonts that are built
into the printer.  (See ps-bdf.el for an example of how Emacs does
that; however, the results are not very nice, perhaps because the BDF
fonts are not suited well to printer resolution, only to that of
terminals.)

Re: Printing

[Lennart Borgman]

On Mon, Mar 30, 2009 at 10:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I think that the browser will send PostScript to the printer.
>
> Yes, it will.
>
>> So I believe it will show that the printer actually can print all
>> the text
>
> Not necessarily: PostScript language includes a capability to download
> characters and images to the printer.  So the fact that something is
> on paper does not yet mean it was printed using fonts that are built
> into the printer.  (See ps-bdf.el for an example of how Emacs does
> that; however, the results are not very nice, perhaps because the BDF
> fonts are not suited well to printer resolution, only to that of
> terminals.)

Do you mean that the web browser might have the needed font and can
sent it to the printer?

Re: Printing

[Eli Zaretskii]

> Date: Mon, 30 Mar 2009 23:27:19 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: rms@gnu.org, cmr.pent@gmail.com, emacs-devel@gnu.org
> 
> On Mon, Mar 30, 2009 at 10:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> I think that the browser will send PostScript to the printer.
> >
> > Yes, it will.
> >
> >> So I believe it will show that the printer actually can print all
> >> the text
> >
> > Not necessarily: PostScript language includes a capability to download
> > characters and images to the printer.  So the fact that something is
> > on paper does not yet mean it was printed using fonts that are built
> > into the printer.  (See ps-bdf.el for an example of how Emacs does
> > that; however, the results are not very nice, perhaps because the BDF
> > fonts are not suited well to printer resolution, only to that of
> > terminals.)
> 
> Do you mean that the web browser might have the needed font and can
> sent it to the printer?

Not the browser itself, but the Windows APIs and the printer driver
can do that.

Re: Printing

[Óscar Fuentes]

Lennart Borgman <lennart.borgman@gmail.com> writes:

>>> > You are missing the fact that I was talking about PostScript printing,
>>> > not printing via the Windows printer API.
>>>
>>> I am not sure about that. Could someone who have this problem and have
>>> a PostScript printer try printing through the web browser, please?
>>
>> And that will prove what, exactly? that Windows knows how to use a PS
>> driver for a printer?
>
> I think that the browser will send PostScript to the printer.

The browser will render the page using the GDI Windows API. Then,
the printer driver will translate this to wathever the printer requires
(PostScript, in this case).

[snip]

-- 
Oscar

Re: Printing

[Richard M Stallman]

    Because ps-print needs to know how to send non-ASCII characters to the
    printer.  Characters from scripts that the printer supports directly
    can be sent verbatim (encoded by a suitable coding-system).  Other
    characters need to be downloaded into the printer before we can use
    them.

Does GTK printing need similar setup?  If not, can we use whatever
mechanism it uses?

    If some of the characters in the region you print don't have a
    corresponding entry in ps-mule-font-info-database, it says something
    vague about "some characters will not be printed".

We could turn that into a query or an error.

Re: Printing

[Eli Zaretskii]

> From: Richard M Stallman <rms@gnu.org>
> CC: cmr.pent@gmail.com, emacs-devel@gnu.org
> Date: Mon, 30 Mar 2009 17:50:30 -0400
> 
>     Because ps-print needs to know how to send non-ASCII characters to the
>     printer.  Characters from scripts that the printer supports directly
>     can be sent verbatim (encoded by a suitable coding-system).  Other
>     characters need to be downloaded into the printer before we can use
>     them.
> 
> Does GTK printing need similar setup?  If not, can we use whatever
> mechanism it uses?

No, we can't.  As Jan explained, GTK+ requires that applications use
cairo for rendering, which we probably will not able to do even in the
GTK build, at least not easily.

>     If some of the characters in the region you print don't have a
>     corresponding entry in ps-mule-font-info-database, it says something
>     vague about "some characters will not be printed".
> 
> We could turn that into a query or an error.

Yes, but that still leaves unresolved the issue of how to set it up
correctly _after_ you know you need some setup.  There's not enough
information in ps-mule.el (or elsewhere in Emacs docs) to know what to
do, unless you have intimate knowledge of what your printer supports
and the fonts that are available.

Re: Printing

[Richard M Stallman]

    > We could turn that into a query or an error.

    Yes, but that still leaves unresolved the issue of how to set it up
    correctly _after_ you know you need some setup.

I agree.  If we follow this route, we need to do both.
So we may as well do one of them as a first step.

The question is whether there is a better route.

Re: Printing

[Андрей Парамонов]

2009/3/29 Richard M Stallman <rms@gnu.org>:
>    b) Use standard GTK+ printing facilities as GEdit and many other
>       applications do. Emacs is built with GTK+ interface for quite some
>       time now, so I suppose there should be no architectural problem in
>       using GTK+ for printing as well. Please correct me if I'm wrong.
>
> Sorry, that won't work.  Emacs can be built with several display
> platforms, GTK being just one.  Sometimes none is used.  I normally
> use Emacs on a tty and I want printing to work there too.
>

Yes, this is indeed an important requirement.

I think that neither GTK nor GhostScript depend on X per se. For
example, Debian installer uses GTK to provide multilingual user
interface from the very early stages of installation. I don't know if
the printing functionality of GTK actually requires X.

Thanks for your effort,
Andrey Paramonov

Re: Printing

[grischka]

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

That is not what "the above" means. Postscript is not a "printer API".
If that were so then only postscript experts would be able to teach
their application to print something.

Btw, using "Print Buffer..." from the "File" menu on one computer gave
me an error  "Opening output file: invalid argument, c:/XPSPort:",
on another said something like "Printing OK" but did nothing.  (Both with
MS-Vista)

Re: Printing

[David De La Harpe Golden]

> 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

[David De La Harpe Golden]

David De La Harpe Golden wrote:


> (or sending trapezoids 
> (xrandr)

uh, xrender I mean.

Re: Printing

[grischka]

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

[Lennart Borgman]

On Wed, Apr 1, 2009 at 8:55 PM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> 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".

As Jason pointed out (and I guess you mean) printing using the ms w32
toolkit is done using GDI API:s. It is like outputting things to the
screen. Therefore printing on w32 is normally very simple to
implement. However Emacs does its own output to the screen and does
not use GDI API:s on that level.

Whether the output is a DIB file or a PostScript dito depends on the
printer used. (The printer driver that is part of w32 or installed
with the printer decides that.)

Like someone (Jason?) said it may be possible to use the code in
ps-*.el to implement calls to the w32 GDI API:s (some C code is of
course needed to for the API calls). If someone understands the
structure of both PostScript and the w32 GDI API:s involved
sufficiently well it would perhaps be rather easy. Of course such work
should be coordinated with what is needed on GNU/Linux. (Something for
Google Summer of Code?)

Re: Printing

[David De La Harpe Golden]

David De La Harpe Golden wrote:

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

Hey, just found enscript homepage itself now recommends the "paps"
(giggle) command line tool for postscript printing of unicode text files.

http://paps.sourceforge.net/

See scans of me printing emacs hello with emacs' ps-print and
through paps - spot the difference:

http://harpegolden.net/misc/emacs-paps/emacs-hello-psprint.jpg
http://harpegolden.net/misc/emacs-paps/emacs-hello-paps.jpg

Yes, the paps output isn't _perfect_ (but all I did was saved
HELLO as utf-8 and fed it to paps), but it's already far, far better
- seeing as it supports non-latin1 stuff at all and all.

Lennart Borgman wrote:
  > Of course such work should be coordinated with what is needed on
  > GNU/Linux. (Something for Google Summer of Code?)

Turns out paps also apparently supports pango's small text formatting
markup language with the --markup flag:

http://library.gnome.org/devel/pango/unstable/PangoMarkupFormat.html

- if emacs could be persuaded to output such marked-up utf-8 text to be
filtered through paps, that might be a *very* short route to semidecent
printing, at least on GNU/linux and similar platforms.

Of course paps is using pango for its rendering - I guess Stefan's
aforementioned "real gtk" emacs port is a long-term solution for
free platforms, using the whole gtk+/cairo/pango stack (I believe
libm17n and libotf are also involved as a possible pango "shaper", but
don't really understand the whole area myself at present...) for a
unified vector-based screen GUI and print layer. Whole lot of work though.

But making emacs output utf-8 text marked up with pango markup language 
(for  replicating font-locking for quasi-wysiwig) to be fed through paps 
might be more at GSoC project scale ? Might even be too small...

Re: Printing

[Stefan Monnier]

> Btw, using "Print Buffer..." from the "File" menu on one computer gave
> me an error  "Opening output file: invalid argument, c:/XPSPort:",
> on another said something like "Printing OK" but did nothing.  (Both with
> MS-Vista)

Last I heard MS-Vista is not a Free system.


        Stefan

Re: Printing

[grischka]

Stefan Monnier wrote:
>> Btw, using "Print Buffer..." from the "File" menu on one computer gave
>> me an error  "Opening output file: invalid argument, c:/XPSPort:",
>> on another said something like "Printing OK" but did nothing.  (Both with
>> MS-Vista)
> 
> Last I heard MS-Vista is not a Free system.
> 

Sorry, I meant "Both with GNU/MS-Vista", of course.

> 
>         Stefan
> 

Re: Printing

[Samuel Bronson]

On Wed, Apr 1, 2009 at 10:33 PM, grischka <grishka@gmx.de> wrote:

> Sorry, I meant "Both with GNU/MS-Vista", of course.

You mean that MS bloatspace thing isn't needed? You can just run a
*nix userspace on top of an NT kernel now?

Re: Printing

[grischka]

Samuel Bronson wrote:
> On Wed, Apr 1, 2009 at 10:33 PM, grischka <grishka@gmx.de> wrote:
> 
>> Sorry, I meant "Both with GNU/MS-Vista", of course.
> 
> You mean that MS bloatspace thing isn't needed? You can just run a
> *nix userspace on top of an NT kernel now?
> 

GNU Emacs as it says on it's "About" splash is "one component of the
GNU operating system", so if GNU Emacs is run with MS-Vista this makes
a combination out of components from GNU and MS-Vista and hence a
GNU/MS-Vista system.  No?

Re: Printing

[Stefan Monnier]

>>> Btw, using "Print Buffer..." from the "File" menu on one computer gave
>>> me an error  "Opening output file: invalid argument, c:/XPSPort:",
>>> on another said something like "Printing OK" but did nothing.  (Both with
>>> MS-Vista)
>> Last I heard MS-Vista is not a Free system.
> Sorry, I meant "Both with GNU/MS-Vista", of course.

I do not know what you mean by "GNU/MS-Vista", but under most GNU
systems, Emacs should print something or signal an error (provided the
print system is configured, of course).  If it didn't, please report it
as a bug.


        Stefan

Re: Printing

[grischka]

Stefan Monnier wrote:
>>>> Btw, using "Print Buffer..." from the "File" menu on one computer gave
>>>> me an error  "Opening output file: invalid argument, c:/XPSPort:",
>>>> on another said something like "Printing OK" but did nothing.  (Both with
>>>> MS-Vista)
>>> Last I heard MS-Vista is not a Free system.
>> Sorry, I meant "Both with GNU/MS-Vista", of course.
> 
> I do not know what you mean by "GNU/MS-Vista", but under most GNU
> systems, Emacs should print something or signal an error (provided the
> print system is configured, of course).  If it didn't, please report it
> as a bug.

If it wasn't to solve problems with "Printing" then what is this
thread for?  Clearly you don't need more reports stacked away
in some tracker.

Re: Printing

[Stefan Monnier]

>> I do not know what you mean by "GNU/MS-Vista", but under most GNU
>> systems, Emacs should print something or signal an error (provided the
>> print system is configured, of course).  If it didn't, please report it
>> as a bug.

> If it wasn't to solve problems with "Printing" then what is this
> thread for?  Clearly you don't need more reports stacked away
> in some tracker.

Sorry, I just wanted to help,


        Stefan