Re: Printing from WindowXP version of emacs

[Peter Dyballa <Peter_Dyballa@web.de>]

Am 05.01.2006 um 02:56 schrieb BRUCE INGALLS:

>> You are using the usual ps-print functions and then ps2pdf to convert
>> PS output to PDF. This is OK for US-ASCII and ISO Latin-1/ISO 8859-1,
>> but it fails already in ISO Latin-9/ISO 8859-15, ISO Latin with €.
>
> Thanks for the info. I wonder if the shortcoming is in the PS  
> generation, or
> in the PDF conversion. I'm sure you could `gsview foo.ps` to find out.

The problem is encoding of the PostScript fonts used to set the  
document. ps-print.el uses ISO 8859-1, independent from the buffer  
contents' encoding. If you have a buffer contents that uses more than  
192 different characters (256 less two times 32 control characters, 7  
bit and 8 bit), you need to provide special PostScript fonts that  
encode so many characters (CID coded fonts for CJK use), or use the  
same font with different encodings to have Latin plus some extended  
Latin (a technique that's used in TeX). The final step of converting  
PS to PDF only fixes these limitations, it can't change anything  
since it's still PostScript. It's just of an improved structure  
embedding all fonts used in the document (leaving out a set of  
mandatory PS fonts) and this way giving a guarantee that this  
document will print everywhere and exactly the same.

>
>> htmlize.el is a great tool, yes!
>>
>> For 'Carbon Emacs' on Mac OS X this seems to
>> become the standard printing interface ... although some users and
>> developers seem to have a 'strange' feeling when using this! And it
>> does not need third party software (ps2pdf from Ghostview).
>
> Well, it did not take much convincing, to tell me that ps2pdf is  
> not a good
> solution.
> Unfortunately, while the htmlview.el printing approach is  
> appealing, it does
> rely on 3rd party software, namely the web browser (unless you use the
> lower quality w3.el, which is an optional package).
>
> Fortunately, w32, osx & linux/gnome have default browsers, that Emacs
> can detect. I have included browser detection software in EMacro  
> (ach, weh!)
> which can help with console mode and other platforms, such as  
> Solaris, bsd,
> etc.

I never worked on a BSD UNIX other than SunOS or Mac OS X, but I  
can't imagine that FreeBSD or NetBSD come without a (kind of third  
party) browser on their installation disks, and OpenBSD is secure  
enough that it can afford an Internet browser. They probably have  
Mozilla, Firefox, Seamonkey well integrated as a native application.  
Solaris once had HotJava (and OpenWindows) and now uses GNOME as GUI,  
so it could be viewed as a Linux variant. AIX, Irix and HP-UX will  
have some sort of Internet browser provided by the manufacturer too.  
A somehow improved version of printing a htmlize'd buffer or  
selection contents could be to use print engines in KDE or GNOME,  
which probably exist. In Mac OS X 10.2 ("Jaguar") Apple 'contributed'  
kind of a generic 'convertor' for CUPS to convert different input  
formats (JPEG, GIF, PICT, TIFF, RTF, plain text in MacRoman) to PDF  
(or PS):

	Usage: /System/Library/Printers/Libraries/convert [-f <input  
filename>] [-o <output filename>] [-i <input mimetype>] [-j <output  
mimetype>] [-P <PPD filename>] [-u] [-a <attribute string>] [-U  
<username>] [-J <jobname] [-c <copies>] [-D]

convert can optimise its PS or PDF output for the printer used via  
the PPD file, it even uses the user's system default monospaced font  
-- but only accepted plain text input is MacRoman! And it has to be a  
file -- no pipe allowed! To convert other text encodings you would  
have to use lossy iconv -c (otherwise no output at all!) to a file  
and feed this file to convert. But -- htmlize'ing first, convert now  
makes no fault with "-i text/html" and everything is printed fine!  
(Some optimisation in fonts and sizes might be fine, in a personal  
CSS file.) Using this 'Unicode encoded' HTML file all is preserved:  
the font used in Emacs, the font faces, its colours (the line breaks  
are not great yet). All that's needed is an efficient convertor from  
HTML to the printing systems native input format ... and maybe a  
button to open the system's native print dialogue!

--
Greetings

   Pete

I obviously had too much to dream last night ...