From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: Displaying LRM and RLM Date: Sat, 20 Dec 2008 22:57:12 +0800 Message-ID: <494D07C8.7040507@f2s.com> References: <20081220104506.GV11238@rzlab.ucr.edu> <494CED8A.9010600@f2s.com> <494CF4E1.5010701@f2s.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1229785085 26833 80.91.229.12 (20 Dec 2008 14:58:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Dec 2008 14:58:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 20 15:59:10 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LE3IK-00087T-6I for ged-emacs-devel@m.gmane.org; Sat, 20 Dec 2008 15:59:09 +0100 Original-Received: from localhost ([127.0.0.1]:53996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LE3H7-0004O6-OC for ged-emacs-devel@m.gmane.org; Sat, 20 Dec 2008 09:57:53 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LE3H3-0004O1-J4 for emacs-devel@gnu.org; Sat, 20 Dec 2008 09:57:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LE3H1-0004Np-1H for emacs-devel@gnu.org; Sat, 20 Dec 2008 09:57:48 -0500 Original-Received: from [199.232.76.173] (port=44765 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LE3H0-0004Nm-Rv for emacs-devel@gnu.org; Sat, 20 Dec 2008 09:57:46 -0500 Original-Received: from ti-out-0910.google.com ([209.85.142.189]:22697) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LE3Gz-0002GK-6n; Sat, 20 Dec 2008 09:57:45 -0500 Original-Received: by ti-out-0910.google.com with SMTP id u5so978851tia.10 for ; Sat, 20 Dec 2008 06:57:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QvwYXBwvu26NT36b0ke4VQyY5I2xc9nkyGkFVTm+RF0=; b=nnraDha0CoX0PxJQqfhqiuGsHCer+tjtRpi6TohWnlFCA89TRTVg9rZkgTcykhXry3 9YMswTa7BYPGPF/wVgGnZtFVVPKU6EsJxYtLaqEoWxdziM72u8jObDx8S3UmJPBX2NaB mZBI4US0OWTg0JP57as3pvDYVaLyZtMbTEVlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jOPxZH8V0JEKBagRlKLO1H9NTzSbmNcLS6k622OEYqK68ZN6AGVmwJO5pGbw+QorQv V36LdX7oK57GK4fm5y3cDl9AiVUF+SqPjwkcWr1JEhzEWooXNR6i3nHlEMVRhFxmRvUE 36jj0oUSKt6sGJokqx4RQrpB1e4Tr/bjqhloM= Original-Received: by 10.110.2.2 with SMTP id 2mr6575542tib.29.1229785062855; Sat, 20 Dec 2008 06:57:42 -0800 (PST) Original-Received: from ?192.168.1.3? ([118.101.181.97]) by mx.google.com with ESMTPS id 22sm4642158tim.35.2008.12.20.06.57.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Dec 2008 06:57:41 -0800 (PST) User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:107123 Archived-At: Eli Zaretskii wrote: > Does Emacs support display of zero-width characters? should it? > I think the answer to this last questions is yes. Another question is HOW should Emacs support zero width characters - should it be stripping them before they are sent to the font backend for display, and doing the right thing with them itself, or should it be up to the font backends to support them? If it is the latter, I think we need to redesign the font backend API to allow extra information to be attached in the encode_char function in the backends. Checking just now, we do actually have the information that this character is zero-width at that point, but once we have returned the encoded glyph, that information is lost.