From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Print eight-bit-* characters with ps-print Date: Mon, 20 May 2002 09:32:50 +0900 (JST) Sender: emacs-devel-admin@gnu.org Message-ID: <200205200032.JAA01545@etlken.m17n.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1021854957 13683 127.0.0.1 (20 May 2002 00:35:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 20 May 2002 00:35:57 +0000 (UTC) Cc: emacs-devel@gnu.org, vinicius@cpqd.com.br Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 179b9Z-0003Ya-00 for ; Mon, 20 May 2002 02:35:57 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 179bNG-0006uC-00 for ; Mon, 20 May 2002 02:50:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 179b9o-0000zd-00; Sun, 19 May 2002 20:36:12 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 179b6s-0000my-00 for ; Sun, 19 May 2002 20:33:10 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g4K0WoV15821; Mon, 20 May 2002 09:32:50 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g4K0WoC08379; Mon, 20 May 2002 09:32:50 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id JAA01545; Mon, 20 May 2002 09:32:50 +0900 (JST) Original-To: eliz@is.elta.co.il In-Reply-To: "eliz@is.elta.co.il"'s message of Fri, 17 May 2002 17:21:38 +0300 User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4152 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4152 "Eli Zaretskii" writes: >> Please try to add more delq for eight-bit-* here, and set >> ps-print-control-characters to `8-bit' (the default is >> `8-bit-control'). Then all eight-bit-* should be printed in >> octal form. Isn't it what you want? > Well, having eight-bit-* characters printed as octal escapes is less > than optimal. The code I posted does slightly better: it prints them > in the default font built into the PostScript printer (usually > Latin-1). > As I said, this is not 100% correct, but in many cases it matches what > you see on the screen. And it certainly is nicer than the octal > escapes. Ah, I think I see your point. Printing such a character by octal or a glyph of the same code of ASCII font should be controlled by ps-print-control-characters. But, in the latter case, the ASCII font should by the builtin font found in ps-font-info-database, not what specified in ps-mule-font-info-database (e.g. "lt1-24-etl.bdf" if ps-multibyte-buffer is bdf-font). Is that what you mean? Then, I agree with your change. But, anyway, we must delete eight-bit-* from `charset' variable because we should avoid that unnecessary warning "Font for some characters not found, ..." even if ps-multibyte-buffer is nil. >> > (Btw, it looks like iso-safe can safely encode eight-bit-* characters. >> > If that's true, I think we should update its doc string. Handa-san, >> > can you please comment on this?) >> >> This is a difficult part. Currently, as far as I remember >> all coding-systems encode them as is. They are treated as >> special bytes that should be written out as is. I'm not >> sure whether or not we should make iso-safe as an exception. >> Instead, how about documenting clearly that there's a super >> rule that any coding system encodes eight-bit-* as is? > I will look for a proper place, thanks. Thank you. --- Ken'ichi HANDA handa@etl.go.jp