patch: handle PS/PDF in Gnus

patch: handle PS/PDF in Gnus

[Sean O'Rourke]

The following patch makes Gnus handle Postscript and PDF
attachments on Mac OS X.  Something similar should probably be
done for a bunch of other attachment types, but these are the
ones I have needed.

/s,
browsing the accumulated diff between his sources and CVS...

Index: mailcap.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/mailcap.el,v
retrieving revision 1.16
diff -u -r1.16 mailcap.el
--- mailcap.el	21 Jan 2007 02:54:13 -0000	1.16
+++ mailcap.el	6 Jul 2007 15:20:50 -0000
@@ -137,6 +137,11 @@
       (type   . "application/zip")
       ("copiousoutput"))
      ("pdf"
+      (viewer . "open %s")
+      (type . "application/pdf")
+      (test . (eq window-system 'mac))
+      ("print" . ,(concat "pdf2ps %s - | " mailcap-print-command)))
+     ("pdf"
       (viewer . "gv -safer %s")
       (type . "application/pdf")
       (test . window-system)
@@ -157,6 +162,11 @@
       ("print" . ,(concat "pdftops %s - | " mailcap-print-command))
       ("copiousoutput"))
      ("postscript"
+      (viewer . "open %s")
+      (type . "application/postscript")
+      (test . (eq window-system 'mac))
+      ("print" . ,(concat mailcap-print-command " %s")))
+     ("postscript"
       (viewer . "gv -safer %s")
       (type . "application/postscript")
       (test   . window-system)

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

2007-07-06  Sean O'Rourke  <sorourke@cs.ucsd.edu> (tiny change)

	* mailcap.el (mailcap-mime-data): handle Postscript and PDF on Mac OS
	  X.

Re: patch: handle PS/PDF in Gnus

[David Kastrup]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> 2007-07-06  Sean O'Rourke  <sorourke@cs.ucsd.edu> (tiny change)
>
> 	* mailcap.el (mailcap-mime-data): handle Postscript and PDF on Mac OS
> 	  X.

Why wouldn't one want to leave the handling to what is written in
/etc/mailcap?

-- 
David Kastrup

Re: patch: handle PS/PDF in Gnus

[David Reitter]

On 6 Jul 2007, at 16:34, David Kastrup wrote:
>> 	* mailcap.el (mailcap-mime-data): handle Postscript and PDF on  
>> Mac OS
>> 	  X.
>
> Why wouldn't one want to leave the handling to what is written in
> /etc/mailcap?

/etc/mailcap doesn't exist on OS X. Mapping from file types to  
handler application is done via the LaunchServices database, which is  
most easily accessed via the "open" tool:

  (viewer . "open %s")
+      (type . "application/pdf")

As for the patch, calling pdf2ps and pdftops is not a good idea since  
this stuff isn't installed unless the user explicitly installs them  
(e.g. Ghostscript, which is mostly useless on the Mac).

What works, however, is to just use "open" with the PS files and let  
LaunchServices deal with it. Current systems come with a preview.app  
(which is what is normally launched for PDFs) that will automatically  
convert PS to PDF and display that.

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

David Kastrup <dak@gnu.org> writes:

> "Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:
>
>> 2007-07-06  Sean O'Rourke  <sorourke@cs.ucsd.edu> (tiny change)
>>
>> 	* mailcap.el (mailcap-mime-data): handle Postscript and PDF on Mac OS
>> 	  X.
>
> Why wouldn't one want to leave the handling to what is written in
> /etc/mailcap?

I have no idea.  I made this change because I wanted attachments
to work, and this is how mailcap.el already handles them under X.
So if /etc/mailcap is the right solution on Unix-like systems,
mailcap-mime-data probably needs to go away.

/s

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

David Reitter <david.reitter@gmail.com> writes:
> As for the patch, calling pdf2ps and pdftops is not a good idea since
> this stuff isn't installed unless the user explicitly installs them
> (e.g. Ghostscript, which is mostly useless on the Mac).

This is for printing.  Do you know of a better way to print
something without first displaying it?  (Maybe applescript?) 

/s

Re: patch: handle PS/PDF in Gnus

[David Reitter]

On 6 Jul 2007, at 16:54, Sean O'Rourke wrote:

> David Reitter <david.reitter@gmail.com> writes:
>> As for the patch, calling pdf2ps and pdftops is not a good idea since
>> this stuff isn't installed unless the user explicitly installs them
>> (e.g. Ghostscript, which is mostly useless on the Mac).
>
> This is for printing.  Do you know of a better way to print
> something without first displaying it?  (Maybe applescript?)

The Carbon framework has APIs for printing. You would have to output  
things on that end (i.e., implemented in C) and then you can call the  
standard print dialogs that will handle everything from outputting to  
PDF, choosing a printer and using the right driver, choosing a layout  
for the pages, etc.
That would be the correct way, and everything else is more or less a  
hack. It probably not worth implementing in Carbon, given that the  
Cocoa port is in the works.

That said, "lpr" should work for PS, PDF, plain text or standard  
image files even if the default printer is not PostScript capable  
(from OS X 10.4). So that's what I would try.

You can also print via AppleScript using the Preview application (it  
can bring up the print dialog directly), and that would work for  
PostScript files as well. But that's relatively hack-y...

- David

Re: patch: handle PS/PDF in Gnus

[Stefan Monnier]

>> Why wouldn't one want to leave the handling to what is written in
>> /etc/mailcap?

> /etc/mailcap doesn't exist on OS X. Mapping from file types to  handler
> application is done via the LaunchServices database, which is  most easily
> accessed via the "open" tool:

Indeed, and instead of adding umpteen entries that pass the file to `open' we
should change the code to default to `open' under Mac OS X.


        Stefan

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Indeed, and instead of adding umpteen entries that pass the
> file to `open' we should change the code to default to `open'
> under Mac OS X.

Agreed.  Unless someone else gets to it first, I'll go ahead and
do this.

/s

Re: patch: handle PS/PDF in Gnus

[Jason Rumney]

Stefan Monnier wrote:
> Indeed, and instead of adding umpteen entries that pass the file to `open' we
> should change the code to default to `open' under Mac OS X.
>   

Opening unknown files from an untrusted source is not a good default.
Does the "open" method on a Mac make its own decisions about what type
of file it is being given based on file content? If so, using it even
for known file types is too much of a risk.

Re: patch: handle PS/PDF in Gnus

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 6 Jul 2007 17:31:32 +0100, David Reitter <david.reitter@gmail.com> said:

> The Carbon framework has APIs for printing. You would have to output
> things on that end (i.e., implemented in C) and then you can call
> the standard print dialogs that will handle everything from
> outputting to PDF, choosing a printer and using the right driver,
> choosing a layout for the pages, etc.  That would be the correct
> way, and everything else is more or less a hack. It probably not
> worth implementing in Carbon, given that the Cocoa port is in the
> works.

As for the standard print dialogs in Carbon, I've tried an
experimental implementation before (for Mac OS X 10.3 and later).  The
function looks like:

  DEFUN ("mac-file-print-dialog", Fmac_file_print_dialog, Smac_file_print_dialog, 1, 3, 0,
	 doc: /* Print file named FILENAME using the standard print dialog.
  The optional second argument NPAGES specifies the total number of
  pages; it will appear as the default in the To field of the dialog.
  The optional third argument MIME-TYPE specifies the mime type of the
  file.  It must be either a string, nil (auto-typed) or t (synonym of
  \"application/postscript\").  */)
       (filename, npages, mime_type)
       Lisp_Object filename, npages, mime_type;

and can be used as:

  (defun mac-ps-print-region (start end program
				    &optional delete buffer display
				    &rest args)
    (let (pages file)
      (save-excursion
	(goto-char start)
	(if (and (re-search-forward "^%%Trailer" nil end)
		 (re-search-forward "^%%Pages:\\s-*\\([0-9]+\\)" nil end))
	    (setq pages (string-to-number (match-string 1)))))
      (setq file (make-temp-file "mac-ps-print"))
      (write-region start end file nil 'nomessage)
      (unwind-protect
	  (mac-file-print-dialog file pages t)
	(delete-file file))))

  (setq ps-print-region-function 'mac-ps-print-region)

Of course, we need to discuss the specification of the function so
that it can be common to the platforms that support print dialogs (in
particular, recent Gtk+) in order to include such a feature in Emacs.

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

Re: patch: handle PS/PDF in Gnus

[Eli Zaretskii]

> Date: Sun, 08 Jul 2007 12:15:09 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> As for the standard print dialogs in Carbon, I've tried an
> experimental implementation before (for Mac OS X 10.3 and later).  The
> function looks like:
> 
>   DEFUN ("mac-file-print-dialog", Fmac_file_print_dialog, Smac_file_print_dialog, 1, 3, 0,
> 	 doc: /* Print file named FILENAME using the standard print dialog.
>   The optional second argument NPAGES specifies the total number of
>   pages; it will appear as the default in the To field of the dialog.
>   The optional third argument MIME-TYPE specifies the mime type of the
>   file.  It must be either a string, nil (auto-typed) or t (synonym of
>   \"application/postscript\").  */)
>        (filename, npages, mime_type)
>        Lisp_Object filename, npages, mime_type;
> 
> and can be used as:
> 
>   (defun mac-ps-print-region (start end program
> 				    &optional delete buffer display
> 				    &rest args)
>     (let (pages file)
>       (save-excursion
> 	(goto-char start)
> 	(if (and (re-search-forward "^%%Trailer" nil end)
> 		 (re-search-forward "^%%Pages:\\s-*\\([0-9]+\\)" nil end))
> 	    (setq pages (string-to-number (match-string 1)))))
>       (setq file (make-temp-file "mac-ps-print"))
>       (write-region start end file nil 'nomessage)
>       (unwind-protect
> 	  (mac-file-print-dialog file pages t)
> 	(delete-file file))))
> 
>   (setq ps-print-region-function 'mac-ps-print-region)
> 
> Of course, we need to discuss the specification of the function so
> that it can be common to the platforms that support print dialogs (in
> particular, recent Gtk+) in order to include such a feature in Emacs.

I think we need to discuss a platform-independent interface to a
printer dialog, before we implement platform-dependent
implementations.  Carbon and Gtk+ are not the only platforms that have
such dialogs built into the OS APIs.

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

Jason Rumney <jasonr@gnu.org> writes:
> Opening unknown files from an untrusted source is not a good
> default.  Does the "open" method on a Mac make its own
> decisions about what type of file it is being given based on
> file content?

AFAIK, it does the same thing as a double-click.  Since we're
talking about what Emacs does in response to an explicit user
action here (e.g. pressing RET), I don't see this as a problem.
I believe "opening untrusted files..." with the least-painful
explicit confirmation is the best that can be done.

/s

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

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

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Indeed, and instead of adding umpteen entries that pass the
>> file to `open' we should change the code to default to `open'
>> under Mac OS X.
>
> Agreed.  Unless someone else gets to it first, I'll go ahead and
> do this.

Here's a patch that does what I think is "the right thing"
w.r.t. opening MIME types on the Mac.  It veers towards the
"umpteen" side of things because there are some types that should
be opened within Emacs, and some entries for other platforms that
interfere with types that should be handled by "open."  The patch
also fixes the undocumented "default" feature, that didn't appear
to work before.

/s

ps -- this uses "lpr" (== CUPS) for printing, independent of the
      ongoing discussion.
pps -- I need to return copyright papers.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 4355 bytes --]

Index: mailcap.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/gnus/mailcap.el,v
retrieving revision 1.16
diff -u -r1.16 mailcap.el
--- mailcap.el	21 Jan 2007 02:54:13 -0000	1.16
+++ mailcap.el	8 Jul 2007 04:58:29 -0000
@@ -74,10 +74,6 @@
 ;; files for the rest?  -- fx
 (defvar mailcap-mime-data
   `(("application"
-     ("vnd.ms-excel"
-      (viewer . "gnumeric %s")
-      (test   . (getenv "DISPLAY"))
-      (type . "application/vnd.ms-excel"))
      ("x-x509-ca-cert"
       (viewer . ssl-view-site-cert)
       (test . (fboundp 'ssl-view-site-cert))
@@ -86,21 +82,6 @@
       (viewer . ssl-view-user-cert)
       (test . (fboundp 'ssl-view-user-cert))
       (type . "application/x-x509-user-cert"))
-     ("octet-stream"
-      (viewer . mailcap-save-binary-file)
-      (non-viewer . t)
-      (type . "application/octet-stream"))
-     ("dvi"
-      (viewer . "xdvi -safer %s")
-      (test   . (eq window-system 'x))
-      ("needsx11")
-      (type   . "application/dvi")
-      ("print" . "dvips -qRP %s"))
-     ("dvi"
-      (viewer . "dvitty %s")
-      (test   . (not (getenv "DISPLAY")))
-      (type   . "application/dvi")
-      ("print" . "dvips -qRP %s"))
      ("emacs-lisp"
       (viewer . mailcap-maybe-eval)
       (type   . "application/emacs-lisp"))
@@ -131,11 +112,39 @@
       (viewer . texinfo-mode)
       (test   . (fboundp 'texinfo-mode))
       (type   . "application/tex"))
+     ("sieve"
+      (viewer . sieve-mode)
+      (test   . (fboundp 'sieve-mode))
+      (type   . "application/sieve"))
      ("zip"
       (viewer . mailcap-save-binary-file)
       (non-viewer . t)
       (type   . "application/zip")
       ("copiousoutput"))
+     ("octet-stream"
+      (viewer . mailcap-save-binary-file)
+      (non-viewer . t)
+      (type . "application/octet-stream"))
+     (".*"
+      (viewer . "open %s")
+      (type . "application/*")
+      (test . (eq window-system 'mac))
+      ("print" . "lpr %s"))
+     ("vnd.ms-excel"
+      (viewer . "gnumeric %s")
+      (test   . (getenv "DISPLAY"))
+      (type . "application/vnd.ms-excel"))
+     ("dvi"
+      (viewer . "xdvi -safer %s")
+      (test   . (eq window-system 'x))
+      ("needsx11")
+      (type   . "application/dvi")
+      ("print" . "dvips -qRP %s"))
+     ("dvi"
+      (viewer . "dvitty %s")
+      (test   . (not (getenv "DISPLAY")))
+      (type   . "application/dvi")
+      ("print" . "dvips -qRP %s"))
      ("pdf"
       (viewer . "gv -safer %s")
       (type . "application/pdf")
@@ -174,15 +183,16 @@
       (test . (not (getenv "DISPLAY")))
       ("print" . ,(concat mailcap-print-command " %s"))
       ("copiousoutput"))
-     ("sieve"
-      (viewer . sieve-mode)
-      (test   . (fboundp 'sieve-mode))
-      (type   . "application/sieve"))
      ("pgp-keys"
       (viewer . "gpg --import --interactive --verbose")
       (type   . "application/pgp-keys")
       ("needsterminal")))
     ("audio"
+     (".*"
+      (viewer . "open %s")
+      (type . "audio/*")
+      (test . (eq window-system 'mac))
+      ("print" . "lpr %s"))
      ("x-mpeg"
       (viewer . "maplay %s")
       (type   . "audio/x-mpeg"))
@@ -207,6 +217,11 @@
       (viewer . view-mode)
       (type   . "message/rfc822")))
     ("image"
+     (".*"
+      (viewer . "open %s")
+      (type . "image/*")
+      (test . (eq window-system 'mac))
+      ("print" . "lpr %s"))
      ("x-xwd"
       (viewer  . "xwud -in %s")
       (type    . "image/x-xwd")
@@ -271,7 +286,12 @@
      ("tar"
       (viewer . tar-mode)
       (type . "archive/tar")
-      (test . (fboundp 'tar-mode)))))
+      (test . (fboundp 'tar-mode))))
+    ("default"
+     (".*"
+      (viewer . "open %s")
+      (test . (eq window-system 'mac))
+      ("print" . "lpr %s"))))
   "The mailcap structure is an assoc list of assoc lists.
 1st assoc list is keyed on the major content-type
 2nd assoc list is keyed on the minor content-type (which can be a regexp)
@@ -762,7 +782,7 @@
 	(setq viewer (car passed)))
       (cond
        ((and (null viewer) (not (equal major "default")) request)
-	(mailcap-mime-info "default" request))
+	(mailcap-mime-info "default/*" request))
        ((or (null request) (equal request ""))
 	(mailcap-unescape-mime-test (cdr (assq 'viewer viewer)) info))
        ((stringp request)

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: patch: handle PS/PDF in Gnus

[Jason Rumney]

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

Sean O'Rourke wrote:
> Here's a patch that does what I think is "the right thing"
> w.r.t. opening MIME types on the Mac.
What does it do for the following attachment?


[-- Attachment #2: test.pdf --]
[-- Type: application/pdf, Size: 3444 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

Jason Rumney <jasonr@gnu.org> writes:

> Sean O'Rourke wrote:
>> Here's a patch that does what I think is "the right thing"
>> w.r.t. opening MIME types on the Mac.
> What does it do for the following attachment?

"File error: couldn't open the file."  (I assume you tried to
hack/crash my machine?)

/s

Re: patch: handle PS/PDF in Gnus

[Sean O'Rourke]

"Sean O'Rourke" <sorourke@cs.ucsd.edu> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> Sean O'Rourke wrote:
>>> Here's a patch that does what I think is "the right thing"
>>> w.r.t. opening MIME types on the Mac.
>> What does it do for the following attachment?
>
> "File error: couldn't open the file."  (I assume you tried to
> hack/crash my machine?)

This error is produced by the standard PDF-viewing program,
Preview.app.  Saving it, renaming it to test.jpg, and opening it
then shows an image with the word "vulnerable" and nasty edge
effects.

/s

Re: patch: handle PS/PDF in Gnus

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 08 Jul 2007 06:22:27 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> Date: Sun, 08 Jul 2007 12:15:09 +0900 From: YAMAMOTO Mitsuharu

>> Of course, we need to discuss the specification of the function so
>> that it can be common to the platforms that support print dialogs
>> (in particular, recent Gtk+) in order to include such a feature in
>> Emacs.

> I think we need to discuss a platform-independent interface to a
> printer dialog, before we implement platform-dependent
> implementations.  Carbon and Gtk+ are not the only platforms that
> have such dialogs built into the OS APIs.

I think we are saying the same thing.  I just implemented an
experimental one to see what is possible on Carbon, but I don't think
it can be added as it is.

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

Re: patch: handle PS/PDF in Gnus

[Stefan Monnier]

> I think we need to discuss a platform-independent interface to a
> printer dialog, before we implement platform-dependent
> implementations.  Carbon and Gtk+ are not the only platforms that have
> such dialogs built into the OS APIs.

Maybe the best solution for that goes as follows:
1 - each platform implementer writes a C DEFUN that provides the most
    obvious and direct interface to the underlying API.
2 - we then compare the various resulting interfaces and come up with a Lisp
    library written on top of it which unifies them into
    a platform-independent interface.
3 - most likely along the way, the unification effort showed that some of
    the platform-specific implementations can be improved or need to be
    changed.

The idea here is that number 1 can be done by each implementer without
knowing anything else, whereas number 2 can be done by people like myself
who lack the platform-specific knowledge.


        Stefan

Re: patch: handle PS/PDF in Gnus

[Jan Djärv]

Stefan Monnier skrev:
>> I think we need to discuss a platform-independent interface to a
>> printer dialog, before we implement platform-dependent
>> implementations.  Carbon and Gtk+ are not the only platforms that have
>> such dialogs built into the OS APIs.
> 
> Maybe the best solution for that goes as follows:
> 1 - each platform implementer writes a C DEFUN that provides the most
>     obvious and direct interface to the underlying API.
> 2 - we then compare the various resulting interfaces and come up with a Lisp
>     library written on top of it which unifies them into
>     a platform-independent interface.
> 3 - most likely along the way, the unification effort showed that some of
>     the platform-specific implementations can be improved or need to be
>     changed.
> 
> The idea here is that number 1 can be done by each implementer without
> knowing anything else, whereas number 2 can be done by people like myself
> who lack the platform-specific knowledge.
> 

For Gtk+ we can use the GtkPrintDialog, but it requires Gtk+ 2.10 or newer.
It is a bit involved as it needs Emacs to render the data to be printed with
cairo.

	Jan D.

Re: patch: handle PS/PDF in Gnus

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:


> For Gtk+ we can use the GtkPrintDialog, but it requires Gtk+ 2.10 or
> newer.  It is a bit involved as it needs Emacs to render the data to
> be printed with cairo.

Is cairo a possible road into bidirectional rendering, or does it not
actually involve the screen?

-- 
David Kastrup

Re: patch: handle PS/PDF in Gnus

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
> 
>> For Gtk+ we can use the GtkPrintDialog, but it requires Gtk+ 2.10 or
>> newer.  It is a bit involved as it needs Emacs to render the data to
>> be printed with cairo.
> 
> Is cairo a possible road into bidirectional rendering, or does it not
> actually involve the screen?
> 

I don't really know, but I think it is possible.

Cairo draws to different backends, called surfaces. X11 is one surface, others 
are PNG, PDF, PostScript, W32, Quartz, OpenGL, SVG.  So depending on the 
surface you draw to, it may involve a screen.  The printing dialog returns a 
suitable surface for the selected printer, and the application is supposed to 
render into that surface.

	Jan D.

Re: patch: handle PS/PDF in Gnus

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 09 Jul 2007 12:52:22 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

> For Gtk+ we can use the GtkPrintDialog, but it requires Gtk+ 2.10 or
> newer.  It is a bit involved as it needs Emacs to render the data to
> be printed with cairo.

Though I'm not familiar with the actual implementation and just
scratched the surface of the API list, I was thinking about more
low-level stuff.  That is, let the user choose a printer using
GtkPrintUnixDialog, and create and send a file-printing job using
GtkPrintJob that has gtk_print_job_set_source_file.

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

Re: patch: handle PS/PDF in Gnus

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:
>>>>>> On Mon, 09 Jul 2007 12:52:22 +0200, Jan Djärv <jan.h.d@swipnet.se> said:
> 
>> For Gtk+ we can use the GtkPrintDialog, but it requires Gtk+ 2.10 or
>> newer.  It is a bit involved as it needs Emacs to render the data to
>> be printed with cairo.
> 
> Though I'm not familiar with the actual implementation and just
> scratched the surface of the API list, I was thinking about more
> low-level stuff.  That is, let the user choose a printer using
> GtkPrintUnixDialog, and create and send a file-printing job using
> GtkPrintJob that has gtk_print_job_set_source_file.
> 


I guess it could work, I haven't used the API myself.

	Jan D.

Re: patch: handle PS/PDF in Gnus

[Jason Rumney]

Stefan Monnier wrote:
> Maybe the best solution for that goes as follows:
> 1 - each platform implementer writes a C DEFUN that provides the most
>     obvious and direct interface to the underlying API.
> 2 - we then compare the various resulting interfaces and come up with a Lisp
>     library written on top of it which unifies them into
>     a platform-independent interface.
> 3 - most likely along the way, the unification effort showed that some of
>     the platform-specific implementations can be improved or need to be
>     changed.


On Windows, there are two dialogs involved in printing. The "Page Setup"
dialog for choosing papertype, margins, features like 2-up etc, and the
Print Dialog, where you can choose the printer, print quality, and other
features.

Due to the number of things you can set in both these dialogs, I think
the interface could be a function that takes a list of properties to use
for initialising the dialog, and returns a list of properties reflecting
the user's choices. If some options are not supported on some platforms,
they can just be ignored, or defaults returned.

Page Setup Dialog
  :units [hundredths-of-mm|thousandths-of-inch]
  :paper-dimensions (x y)
  :min-margins [(left top right bottom)|default]
  :margins [(left top right bottom)|disable]
  :device (driver-name printer-name port-name)
  :enable-network [nil|t]
  :device-mode (:printer-friendly-name
                :orientation [portrait|landscape|disable]
                :paper-size [letter|legal|a4....|disable]
                :paper-length
                :paper-width
                :scale-percent
                :copies
                :paper-source [auto|cassette|envelope|first|upper|lower...]
                :print-quality [high|medium|low|draft]
                :color [t|nil]
                :duplex [t|nil]
                :y-dpi
                :font [bitmap|download|download-outline|substitute]
                :collate [t|nil]
                :form-name
                :n-up [spooler|application]
                :icm-method [none|system|driver|device]
                :icm-intent
[abs-color-imetric|color-imetric|contrast|saturate]
                :media [plain|glossy|transparency|driver defined integer]
                :dither
[none|coarse|fine|line-art|error-diffusion|grayscale]

Print Dialog
  :device (driver-name printer-name port-name)
  :device-mode (see above)
  :enable-pages [nil|t]
  :enable-selection [nil|t]
  :pages (from to)|all|selection
  :enable-print-to-file [nil|t]
  :to-file [nil|t]
  :enable-network [nil|t]
  :copies
  :collate [nil|t]

Re: patch: handle PS/PDF in Gnus

[Jan Djärv]

Jason Rumney skrev:
> 
> On Windows, there are two dialogs involved in printing. The "Page Setup"
> dialog for choosing papertype, margins, features like 2-up etc, and the
> Print Dialog, where you can choose the printer, print quality, and other
> features.
> 

Gtk+ has this also.

> Due to the number of things you can set in both these dialogs, I think
> the interface could be a function that takes a list of properties to use
> for initialising the dialog, and returns a list of properties reflecting
> the user's choices. If some options are not supported on some platforms,
> they can just be ignored, or defaults returned.

Since the setup and print dialog are platform specific, why not just keep the
settings in data structures in the C code?  That would simplify things.  On
the other hand, it would probably be harder to save/restore between Emacs
sessions, if that is what we want.

	Jan D.

> 
> Page Setup Dialog
>   :units [hundredths-of-mm|thousandths-of-inch]
>   :paper-dimensions (x y)
>   :min-margins [(left top right bottom)|default]
>   :margins [(left top right bottom)|disable]
>   :device (driver-name printer-name port-name)
>   :enable-network [nil|t]
>   :device-mode (:printer-friendly-name
>                 :orientation [portrait|landscape|disable]
>                 :paper-size [letter|legal|a4....|disable]
>                 :paper-length
>                 :paper-width
>                 :scale-percent
>                 :copies
>                 :paper-source [auto|cassette|envelope|first|upper|lower...]
>                 :print-quality [high|medium|low|draft]
>                 :color [t|nil]
>                 :duplex [t|nil]
>                 :y-dpi
>                 :font [bitmap|download|download-outline|substitute]
>                 :collate [t|nil]
>                 :form-name
>                 :n-up [spooler|application]
>                 :icm-method [none|system|driver|device]
>                 :icm-intent
> [abs-color-imetric|color-imetric|contrast|saturate]
>                 :media [plain|glossy|transparency|driver defined integer]
>                 :dither
> [none|coarse|fine|line-art|error-diffusion|grayscale]
> 
> Print Dialog
>   :device (driver-name printer-name port-name)
>   :device-mode (see above)
>   :enable-pages [nil|t]
>   :enable-selection [nil|t]
>   :pages (from to)|all|selection
>   :enable-print-to-file [nil|t]
>   :to-file [nil|t]
>   :enable-network [nil|t]
>   :copies
>   :collate [nil|t]
>    
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel