Does ps-print-buffer-with-faces give the correct colors?

Does ps-print-buffer-with-faces give the correct colors?

[Mathias Dahl]

I made a small hack today while playing wirh Ghostscript. It creates a
PDF file of the current buffer in Emacs. The problem is that the
colors of the faces become strange.

Here is the code:

;;;;

(defcustom ps2pdf-gs-program "C:/Program Files/GPLGS/gswin32c.exe"
  "Path to GhostView program."
  :type 'string
  :group 'ps2pdf)

(defun ps2pdf-convert (file)
  (let* ((pdf-file (concat (file-name-sans-extension file) ".pdf"))
         (result
          (call-process ps2pdf-gs-program nil nil t
                       "-q" "-dNOPAUSE" "-sDEVICE=pdfwrite" 
                       (concat "-sOutputFile=" pdf-file)
                       file)))
    (if (eq 0 result)
        pdf-file
      (error "PDF creation failed"))))

(defun ps2pdf (file)
  (interactive "fSelect Postscript file: ")
  (let ((pdf-file (ps2pdf-convert file)))
    (message "PDF file %s created successfully" pdf-file)))

(defun ps2pdf-from-buffer ()
  (let ((fname (make-temp-file "ps2pdf-buffer" nil ".ps"))
         (pdf-file))
    (ps-print-buffer-with-faces fname)
    (message "Postscript file %s created" fname)
    (setq pdf-file (ps2pdf-convert fname))
    (message "PDF file %s created successfully" pdf-file)
    pdf-file))

(defun w32-ps2pdf-from-buffer ()
  (interactive)
  (w32-shell-execute "Open" (ps2pdf-from-buffer)))

(provide 'ps2pdf)

;;;;

How does `ps-print-buffer-with-faces' calculate the colors from the
faces in the buffer? Something is clearly wrong. I took a screenshot
of the Emacs buffer and used Gimp to check the color values of a
specific text on the screen. The values were: Red: 63%, Green: 13%,
Blue: 94%. In the ps file that Emas generates, I can see the
following:

...
0.686 0.933 0.933 FG
(lambda) S
...

I don't know what kind of values those are but clearly two of the
values are the same, which is not the case when I checked the color in
Gimp.

You can see the screenshots here:

http://www.flickr.com/photos/klibb/303651087/ (Emacs buffer)

http://www.flickr.com/photos/klibb/303651103/ (PDF in Acrobat)

I tested this on Windows XP with a quite recent (November 2006) CVS
Emacs and the newest GPL Ghostscript version.

/Mathias

Re: Does ps-print-buffer-with-faces give the correct colors?

[Peter Dyballa]

Am 22.11.2006 um 19:25 schrieb Mathias Dahl:

> I made a small hack today while playing wirh Ghostscript. It creates a
> PDF file of the current buffer in Emacs. The problem is that the
> colors of the faces become strange.

Have you tried Lennart Borgman's htmlize-view.el? Together with  
Hrvoje Niksic's htmlize.el (http://fly.srk.fer.hr/~hniksic/emacs/ 
htmlize.el) it converts the buffer into HTML first, which is then  
displayed in your WWW browser, which should allow to "print" into a  
PDF file. This way encodings are saved (which PS cannot), and colours  
as well.


On Mac OS X Ghostscript 8.54 produces PDF with the right colours. I  
used list-colors-display.

--
Greetings

   Pete

One doesn't expect governments to obey the law because of some higher  
moral development.  One expects them to obey the law because they  
know that if they don't, those who aren't shot will be hanged.
                                                  --Michael Shirley

Re: Does ps-print-buffer-with-faces give the correct colors?

[Mathias Dahl]

Mathias Dahl <brakjoller@gmail.com> writes:

> ...
> 0.686 0.933 0.933 FG
> (lambda) S
> ...

I also tested this at home, on GNU/Linux, latest CVS Emacs build,
aaaaand... it works perfectly!

Here is the same part from the .ps file:

...
0.627 0.125 0.941 FG
(lambda) S
...

Could there be a flaw in how `ps-print-buffer-with-faces' calculates
colors under Windows or was the Windows build broken until recently
(the build I used at work is from some week ago). Hmm, there was some
problem with images that I discussed with Lennart, could this have to
do with that...

/Mathias

Re: Does ps-print-buffer-with-faces give the correct colors?

[Eli Zaretskii]

> From: Peter Dyballa <Peter_Dyballa@Web.DE>
> Date: Wed, 22 Nov 2006 23:35:02 +0100
> Cc: help-gnu-emacs@gnu.org
> 
> Have you tried Lennart Borgman's htmlize-view.el? Together with  
> Hrvoje Niksic's htmlize.el (http://fly.srk.fer.hr/~hniksic/emacs/ 
> htmlize.el) it converts the buffer into HTML first, which is then  
> displayed in your WWW browser, which should allow to "print" into a  
> PDF file. This way encodings are saved (which PS cannot), and colours  
> as well.

What encodings can't PS preserve, and why?

> On Mac OS X Ghostscript 8.54 produces PDF with the right colours. I  
> used list-colors-display.

Last time I tried, Ghostscript produced good colors on Windows as
well.

Re: Does ps-print-buffer-with-faces give the correct colors?

[Eli Zaretskii]

> From: Mathias Dahl <mathias.dahl@gmail.com>
> Date: Thu, 23 Nov 2006 01:43:03 +0100
> 
> Could there be a flaw in how `ps-print-buffer-with-faces' calculates
> colors under Windows or was the Windows build broken until recently
> (the build I used at work is from some week ago). Hmm, there was some
> problem with images that I discussed with Lennart, could this have to
> do with that...

FWIW, last time I checked ps-print-buffer-with-faces was producing
very good colors for me on Windows.  Cannot test right now with the
latest version, though, for some uninteresting reasons.

Re: Does ps-print-buffer-with-faces give the correct colors?

[Mathias Dahl]

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Have you tried Lennart Borgman's htmlize-view.el? Together with
> Hrvoje Niksic's htmlize.el (http://fly.srk.fer.hr/~hniksic/emacs/
> htmlize.el) it converts the buffer into HTML first, which is then
> displayed in your WWW browser, which should allow to "print" into a
> PDF file. This way encodings are saved (which PS cannot), and
> colours as well.

I have used htmlize.el and I like it. I have also made a hack for w32
that lets me get the fontified text from Emacs, with colors, onto the
w32 clipboard.

Re: Does ps-print-buffer-with-faces give the correct colors?

[Peter Dyballa]

Am 23.11.2006 um 05:08 schrieb Eli Zaretskii:

> What encodings can't PS preserve, and why?

Utf-8. To be more specific: everything non ISO Latin-1 is a problem  
for the PS print routines in GNU Emacs:

These characters in the buffer can't be printed:
Ą, ą, Ł, €, „, Š, š, Ș, Ź, ź, Ż, Č, ł, Ž, ”, and  
more...
Click them to jump to the buffer position,
or C-u C-x = will give information about them.

Please don't mention PS Mule and BDF fonts! The reason why it fails  
lies in the PostScript fonts: they can only provide up to 256 glyphs.  
CID type PS fonts for use with CJK scripts can provide more glyphs.  
Right now there is no PostScript "fontset" defined that supports the  
planes defined in Unicode, not even for the first 64 K positions in  
the BMP, the Basic Multilingual Plane.

It is clever to use the operating system's knowledge.

--
Greetings

   Pete

There's something the technicians need to learn from the artists. If  
it isn't aesthetically pleasing, it's probably wrong.

Re: Does ps-print-buffer-with-faces give the correct colors?

[Mathias Dahl]

Mathias Dahl <brakjoller@gmail.com> writes:

> I made a small hack today while playing wirh Ghostscript. It creates
> a PDF file of the current buffer in Emacs. The problem is that the
> colors of the faces become strange.

Problem solved! :)

I read the comments in ps-print.el and found this section:

    ;; ps-print keeps internal lists of which fonts are bold and which
    ;; are italic; these lists are built the first time you invoke
    ;; ps-print.

AHA!

    ;; For the sake of efficiency, the lists are built only once; the
    ;; same lists are referred in later invocations of ps-print.

And there seem to exist a cure too:

    ;; Because these lists are built only once, it's possible for them
    ;; to get out of sync, if a face changes, or if new faces are
    ;; added.  To get the lists back in sync, you can set the variable
    ;; `ps-build-face-reference' to t, and the lists will be rebuilt
    ;; the next time ps-print is invoked.  If you need that the lists
    ;; always be rebuilt when ps-print is invoked, set the variable
    ;; `ps-always-build-face-reference' to t.

In my case I had first tested my hack using one color-theme and then I
switched and it kept the colors that the old theme had. Testing from a
newly started Emacs solved the problem. And I also tested setting the
variable `ps-build-face-reference' mentioned above right now, and it
also solved the problem.

So, move along, nothing to see here... :)

Re: Does ps-print-buffer-with-faces give the correct colors?

[Kim F. Storm]

Mathias Dahl <brakjoller@gmail.com> writes:

> Mathias Dahl <brakjoller@gmail.com> writes:
>
>> I made a small hack today while playing wirh Ghostscript. It creates
>> a PDF file of the current buffer in Emacs. The problem is that the
>> colors of the faces become strange.
>
> Problem solved! :)
>
> I read the comments in ps-print.el and found this section:
>
>     ;; ps-print keeps internal lists of which fonts are bold and which
>     ;; are italic; these lists are built the first time you invoke
>     ;; ps-print.
>
> AHA!
>
>     ;; For the sake of efficiency, the lists are built only once; the
>     ;; same lists are referred in later invocations of ps-print.
>
> And there seem to exist a cure too:
>
>     ;; Because these lists are built only once, it's possible for them
>     ;; to get out of sync, if a face changes, or if new faces are
>     ;; added.  To get the lists back in sync, you can set the variable
>     ;; `ps-build-face-reference' to t, and the lists will be rebuilt
>     ;; the next time ps-print is invoked.  If you need that the lists
>     ;; always be rebuilt when ps-print is invoked, set the variable
>     ;; `ps-always-build-face-reference' to t.
>
> In my case I had first tested my hack using one color-theme and then I
> switched and it kept the colors that the old theme had. Testing from a
> newly started Emacs solved the problem. And I also tested setting the
> variable `ps-build-face-reference' mentioned above right now, and it
> also solved the problem.
>
> So, move along, nothing to see here... :)

I don't know how often people print files, but to me it seems more
user-friendly if the default for ps-always-build-face-reference is t,
so users don't have to wade through lots of documentation to find out
why things doesn't work -- just because of an optimization.
Is the time used to build that list noticable at all?

People who do read the "fine print" may still set that variable to nil
if they want the optimization.

-- 
Kim F. Storm  http://www.cua.dk

Re: Does ps-print-buffer-with-faces give the correct colors?

[Lennart Borgman]

Kim F. Storm wrote:
> I don't know how often people print files, but to me it seems more
> user-friendly if the default for ps-always-build-face-reference is t,
> so users don't have to wade through lots of documentation to find out
> why things doesn't work -- just because of an optimization.

Agree. Seems like a better optimization.

Re: Does ps-print-buffer-with-faces give the correct colors?

[Eli Zaretskii]

> Date: Sat, 25 Nov 2006 00:15:39 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: help-gnu-emacs@gnu.org, Mathias Dahl <brakjoller@gmail.com>
> 
> Kim F. Storm wrote:
> > I don't know how often people print files, but to me it seems more
> > user-friendly if the default for ps-always-build-face-reference is t,
> > so users don't have to wade through lots of documentation to find out
> > why things doesn't work -- just because of an optimization.
> 
> Agree. Seems like a better optimization.

This is really not the right place to discuss such changes.  IIRC, the
reason for that variable being nil is the fact that it's time
consuming, or maybe was time consuming when the machines were slow.

Re: Does ps-print-buffer-with-faces give the correct colors?

[Mathias Dahl]

no-spam@cua.dk (Kim F. Storm) writes:

> I don't know how often people print files, but to me it seems more
> user-friendly if the default for ps-always-build-face-reference is
> t, so users don't have to wade through lots of documentation to find
> out why things doesn't work -- just because of an optimization.  Is
> the time used to build that list noticable at all?

Well, at least for me it would have saved quite some time of mine, and
the time of people in this group :)