From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM Date: Mon, 01 Nov 2010 17:15:13 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1288599340 32249 80.91.229.12 (1 Nov 2010 08:15:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 1 Nov 2010 08:15:40 +0000 (UTC) Cc: emacs-bidi@gnu.org, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Mon Nov 01 09:15:36 2010 Return-path: Envelope-to: gnu-emacs-bidi@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PCpYE-0006U9-KK for gnu-emacs-bidi@m.gmane.org; Mon, 01 Nov 2010 09:15:34 +0100 Original-Received: from localhost ([127.0.0.1]:59942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCpYE-0000jC-0F for gnu-emacs-bidi@m.gmane.org; Mon, 01 Nov 2010 04:15:34 -0400 Original-Received: from [140.186.70.92] (port=45025 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCpY6-0000fg-U4 for emacs-bidi@gnu.org; Mon, 01 Nov 2010 04:15:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCpY1-0007kK-IX for emacs-bidi@gnu.org; Mon, 01 Nov 2010 04:15:26 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:48899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCpY1-0007jp-0C; Mon, 01 Nov 2010 04:15:21 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id oA18FEhA004536; Mon, 1 Nov 2010 17:15:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id oA18FEp4005576; Mon, 1 Nov 2010 17:15:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id oA18FDt1006799; Mon, 1 Nov 2010 17:15:14 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.71) (envelope-from ) id 1PCpXt-00034p-Qk; Mon, 01 Nov 2010 17:15:13 +0900 In-Reply-To: (message from Kenichi Handa on Thu, 19 Aug 2010 11:49:14 +0900) X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of Emacs support for multi-directional text." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bidi:839 gmane.emacs.devel:132230 Archived-At: In article , Kenichi Handa writes: > I'd like to extend the elements of a display table. > Currently only a glyph vector or nil is allowed. It seems > good to extend it so that it can completely control the > displaying of a character (like by face and display text > properties). > At least, for (2), I want to specify a space width (relative > or absolute), and for (4) I want to specify a special form > (list?) containing a mnemonic label. I've just committed a basic infrastructure for displaying non-graphic and no-font characters. For that, instead of extending the current display table, I implemented a new char table glyphless-char-display. ------------------------------------------------------------ Char-table to control displaying of glyphless characters. Each element, if non-nil, is an ASCII acronym string (displayed in a box) or one of these symbols: hexa-code: display with hexadecimal character code in a box empty-box: display with an empty box thin-space: display with 1-pixel width space zero-width: don't display It has one extra slot to control the display of a character for which no font is found. The value of the slot is `hexa-code' or `empty-box'. The default is `empty-box'. ------------------------------------------------------------ It is easy to merge such functionality to a display table later if we decide to do so. But, there left these works. (1) As it is not convenient for a user to specify each element of glyphless-char-display, I made variables char-acronym-table and glyphless-char-control. The former is a simple char-table that contains acronym strings. The latter is as this: ------------------------------------------------------------ glyphless-char-control is a variable defined in `characters.el'. Its value is ((format-control . thin-space) (no-font . hexa-code)) Documentation: List of directives to control displaying of glyphless characters. Each element has the form (TARGET . METHOD), where TARGET is a symbol specifying the target character group to control, and METHOD is a symbol specifying the method of displaying them. TARGET must be one of these symbols: `c0-control': U+0000..U+001F. `c1-control': U+0080..U+009F. `format-control': Characters of Unicode General Category `Cf'. Ex: U+200C (ZWNJ), U+200E (LRM)), but don't include characters that have graphic image such as U+00AD (SHY). `no-font': characters for which no suitable font is found. METHOD must be one of these symbols: `zero-width': don't display. `thin-space': display a thin space (1-pixel width). `empty-box': display an empty box. `acronym': display an acronum string in a box. `hexa-code': display a hexadecimal character code in a box. Just setting this variable does not take effect. Call the function `update-glyphless-char-display' (which see) after setting this variable. ------------------------------------------------------------ When acronum is specified, the function update-glyphless-char-display sets elements in glyphless-char-display to acronyms stored in char-acronym-table. Actually, glyphless-char-control should be a customizable variable with proper set: function. But, I don't know how to write the correct 'defcustom' form. Could someone DTRT? (2) For Windows port: I wrote x_draw_glyphless_glyph_string_foreground (in w32term.c) by referring to x_draw_glyph_string_foreground in the same file. But, it doesn't draw acronym nor hexa-code. I couldn't figure out what is wrong. Please someone who knows Windows code fix it. (3) For mac port: As I have no idea how to write a code for mac, the 'case GLYPHLESS_GLYPH:' part in ns_draw_glyph_string (in nsterm.m) is not finished. Please fill in the correct code by referring to x_draw_glyph_string_foreground in xterm.c. --- Kenichi Handa handa@m17n.org