all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* patch: handle PS/PDF in Gnus
@ 2007-07-06 15:21 Sean O'Rourke
  2007-07-06 15:27 ` Sean O'Rourke
  0 siblings, 1 reply; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-06 15:21 UTC (permalink / raw)
  To: emacs-devel

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)

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:21 patch: handle PS/PDF in Gnus Sean O'Rourke
@ 2007-07-06 15:27 ` Sean O'Rourke
  2007-07-06 15:34   ` David Kastrup
  0 siblings, 1 reply; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-06 15:27 UTC (permalink / raw)
  To: emacs-devel

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.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:27 ` Sean O'Rourke
@ 2007-07-06 15:34   ` David Kastrup
  2007-07-06 15:52     ` David Reitter
  2007-07-06 15:53     ` Sean O'Rourke
  0 siblings, 2 replies; 26+ messages in thread
From: David Kastrup @ 2007-07-06 15:34 UTC (permalink / raw)
  To: Sean O'Rourke; +Cc: emacs-devel

"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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:34   ` David Kastrup
@ 2007-07-06 15:52     ` David Reitter
  2007-07-06 15:54       ` Sean O'Rourke
  2007-07-06 18:13       ` Stefan Monnier
  2007-07-06 15:53     ` Sean O'Rourke
  1 sibling, 2 replies; 26+ messages in thread
From: David Reitter @ 2007-07-06 15:52 UTC (permalink / raw)
  To: emacs- devel

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.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:34   ` David Kastrup
  2007-07-06 15:52     ` David Reitter
@ 2007-07-06 15:53     ` Sean O'Rourke
  1 sibling, 0 replies; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-06 15:53 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:52     ` David Reitter
@ 2007-07-06 15:54       ` Sean O'Rourke
  2007-07-06 16:31         ` David Reitter
  2007-07-06 18:13       ` Stefan Monnier
  1 sibling, 1 reply; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-06 15:54 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:54       ` Sean O'Rourke
@ 2007-07-06 16:31         ` David Reitter
  2007-07-08  3:15           ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 26+ messages in thread
From: David Reitter @ 2007-07-06 16:31 UTC (permalink / raw)
  To: emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 15:52     ` David Reitter
  2007-07-06 15:54       ` Sean O'Rourke
@ 2007-07-06 18:13       ` Stefan Monnier
  2007-07-06 19:32         ` Sean O'Rourke
  2007-07-06 20:44         ` Jason Rumney
  1 sibling, 2 replies; 26+ messages in thread
From: Stefan Monnier @ 2007-07-06 18:13 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 18:13       ` Stefan Monnier
@ 2007-07-06 19:32         ` Sean O'Rourke
  2007-07-08  5:13           ` Sean O'Rourke
  2007-07-06 20:44         ` Jason Rumney
  1 sibling, 1 reply; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-06 19:32 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: David Reitter, emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 18:13       ` Stefan Monnier
  2007-07-06 19:32         ` Sean O'Rourke
@ 2007-07-06 20:44         ` Jason Rumney
  2007-07-08  4:52           ` Sean O'Rourke
  1 sibling, 1 reply; 26+ messages in thread
From: Jason Rumney @ 2007-07-06 20:44 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: David Reitter, emacs- devel

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.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 16:31         ` David Reitter
@ 2007-07-08  3:15           ` YAMAMOTO Mitsuharu
  2007-07-08  3:22             ` Eli Zaretskii
  0 siblings, 1 reply; 26+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-07-08  3:15 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08  3:15           ` YAMAMOTO Mitsuharu
@ 2007-07-08  3:22             ` Eli Zaretskii
  2007-07-08 13:41               ` YAMAMOTO Mitsuharu
  2007-07-08 14:31               ` Stefan Monnier
  0 siblings, 2 replies; 26+ messages in thread
From: Eli Zaretskii @ 2007-07-08  3:22 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: david.reitter, emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 20:44         ` Jason Rumney
@ 2007-07-08  4:52           ` Sean O'Rourke
  0 siblings, 0 replies; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-08  4:52 UTC (permalink / raw)
  To: Jason Rumney; +Cc: David Reitter, Stefan Monnier, emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-06 19:32         ` Sean O'Rourke
@ 2007-07-08  5:13           ` Sean O'Rourke
  2007-07-08 10:19             ` Jason Rumney
  0 siblings, 1 reply; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-08  5:13 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: David Reitter, emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08  5:13           ` Sean O'Rourke
@ 2007-07-08 10:19             ` Jason Rumney
  2007-07-08 13:03               ` Sean O'Rourke
  0 siblings, 1 reply; 26+ messages in thread
From: Jason Rumney @ 2007-07-08 10:19 UTC (permalink / raw)
  To: Sean O'Rourke; +Cc: David Reitter, Stefan Monnier, emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08 10:19             ` Jason Rumney
@ 2007-07-08 13:03               ` Sean O'Rourke
  2007-07-08 13:14                 ` Sean O'Rourke
  0 siblings, 1 reply; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-08 13:03 UTC (permalink / raw)
  To: Jason Rumney; +Cc: David Reitter, Stefan Monnier, emacs- devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08 13:03               ` Sean O'Rourke
@ 2007-07-08 13:14                 ` Sean O'Rourke
  0 siblings, 0 replies; 26+ messages in thread
From: Sean O'Rourke @ 2007-07-08 13:14 UTC (permalink / raw)
  To: Jason Rumney; +Cc: David Reitter, Stefan Monnier, emacs- devel

"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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08  3:22             ` Eli Zaretskii
@ 2007-07-08 13:41               ` YAMAMOTO Mitsuharu
  2007-07-08 14:31               ` Stefan Monnier
  1 sibling, 0 replies; 26+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-07-08 13:41 UTC (permalink / raw)
  To: eliz; +Cc: david.reitter, emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08  3:22             ` Eli Zaretskii
  2007-07-08 13:41               ` YAMAMOTO Mitsuharu
@ 2007-07-08 14:31               ` Stefan Monnier
  2007-07-09 10:52                 ` Jan Djärv
  2007-07-11 21:51                 ` Jason Rumney
  1 sibling, 2 replies; 26+ messages in thread
From: Stefan Monnier @ 2007-07-08 14:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: david.reitter, YAMAMOTO Mitsuharu, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08 14:31               ` Stefan Monnier
@ 2007-07-09 10:52                 ` Jan Djärv
  2007-07-09 12:39                   ` David Kastrup
  2007-07-09 18:03                   ` YAMAMOTO Mitsuharu
  2007-07-11 21:51                 ` Jason Rumney
  1 sibling, 2 replies; 26+ messages in thread
From: Jan Djärv @ 2007-07-09 10:52 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: david.reitter, Eli Zaretskii, YAMAMOTO Mitsuharu, emacs-devel

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.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-09 10:52                 ` Jan Djärv
@ 2007-07-09 12:39                   ` David Kastrup
  2007-07-09 14:17                     ` Jan Djärv
  2007-07-09 18:03                   ` YAMAMOTO Mitsuharu
  1 sibling, 1 reply; 26+ messages in thread
From: David Kastrup @ 2007-07-09 12:39 UTC (permalink / raw)
  To: Jan Djärv; +Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-09 12:39                   ` David Kastrup
@ 2007-07-09 14:17                     ` Jan Djärv
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Djärv @ 2007-07-09 14:17 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel



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.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-09 10:52                 ` Jan Djärv
  2007-07-09 12:39                   ` David Kastrup
@ 2007-07-09 18:03                   ` YAMAMOTO Mitsuharu
  2007-07-09 19:57                     ` Jan Djärv
  1 sibling, 1 reply; 26+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-07-09 18:03 UTC (permalink / raw)
  To: jan.h.d; +Cc: david.reitter, eliz, monnier, emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-09 18:03                   ` YAMAMOTO Mitsuharu
@ 2007-07-09 19:57                     ` Jan Djärv
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Djärv @ 2007-07-09 19:57 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: david.reitter, eliz, monnier, emacs-devel



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.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-08 14:31               ` Stefan Monnier
  2007-07-09 10:52                 ` Jan Djärv
@ 2007-07-11 21:51                 ` Jason Rumney
  2007-07-12  9:35                   ` Jan Djärv
  1 sibling, 1 reply; 26+ messages in thread
From: Jason Rumney @ 2007-07-11 21:51 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: david.reitter, Eli Zaretskii, YAMAMOTO Mitsuharu, emacs-devel

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]

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: patch: handle PS/PDF in Gnus
  2007-07-11 21:51                 ` Jason Rumney
@ 2007-07-12  9:35                   ` Jan Djärv
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Djärv @ 2007-07-12  9:35 UTC (permalink / raw)
  To: Jason Rumney
  Cc: david.reitter, Eli Zaretskii, Stefan Monnier, YAMAMOTO Mitsuharu,
	emacs-devel

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

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2007-07-12  9:35 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-06 15:21 patch: handle PS/PDF in Gnus Sean O'Rourke
2007-07-06 15:27 ` Sean O'Rourke
2007-07-06 15:34   ` David Kastrup
2007-07-06 15:52     ` David Reitter
2007-07-06 15:54       ` Sean O'Rourke
2007-07-06 16:31         ` David Reitter
2007-07-08  3:15           ` YAMAMOTO Mitsuharu
2007-07-08  3:22             ` Eli Zaretskii
2007-07-08 13:41               ` YAMAMOTO Mitsuharu
2007-07-08 14:31               ` Stefan Monnier
2007-07-09 10:52                 ` Jan Djärv
2007-07-09 12:39                   ` David Kastrup
2007-07-09 14:17                     ` Jan Djärv
2007-07-09 18:03                   ` YAMAMOTO Mitsuharu
2007-07-09 19:57                     ` Jan Djärv
2007-07-11 21:51                 ` Jason Rumney
2007-07-12  9:35                   ` Jan Djärv
2007-07-06 18:13       ` Stefan Monnier
2007-07-06 19:32         ` Sean O'Rourke
2007-07-08  5:13           ` Sean O'Rourke
2007-07-08 10:19             ` Jason Rumney
2007-07-08 13:03               ` Sean O'Rourke
2007-07-08 13:14                 ` Sean O'Rourke
2007-07-06 20:44         ` Jason Rumney
2007-07-08  4:52           ` Sean O'Rourke
2007-07-06 15:53     ` Sean O'Rourke

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.