help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Printing from WindowXP version of emacs


From: Peter Dyballa
Subject: Re: Printing from WindowXP version of emacs
Date: Thu, 5 Jan 2006 14:01:10 +0100


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]