From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <34fa0649f0edeb10b2f67a3a4f9f71fc@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Font behaviour From: "rob pike" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-mrupstnyamdkoforcyddmptxwx" Date: Tue, 5 Feb 2002 12:22:07 -0500 Topicbox-Message-UUID: 4cc871ec-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-mrupstnyamdkoforcyddmptxwx Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The library forbids zero-width characters because of two issues: 1) they introduce ambiguities into the selection and placement rules, in particular confusing the algorithm for character-at-position. 2) someone could print an unending stream of zero-width characters and fill up memory. One could argue that neither of these is a serious issue, and that both are raised somewhat by overstriking, which we do accept (badly, at least in rio), but I was troubled by them anyway. Plan 9's font code is quite primitive compared to what some systems do (and some languages require), but it's served well enough for our purposes. The solution I concocted for zero-width characters struck me as rather elegant, although I knew it would cause trouble for anyone who legitimately had a use for them. 1) characters absent from the font are by definition zero-width. 2) all zero width characters are rendered as PJWs. In a stroke, this made sparse Unicode fonts bearable. You can take out the code that does this, but I think you'll raise some other issues because of other code that depends on those properties. A better solution might be to write a special operator that always draws the character - it's a trivial call to draw(). The real solution is a complete redesign of the character handling model to deal with all languages, right-to-left, Arabic letter-form-mutations, etc. etc. It's beyond my knowledge. -rob --upas-mrupstnyamdkoforcyddmptxwx Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Feb 5 11:42:24 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Feb 5 11:42:23 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5F0A019A2D; Tue, 5 Feb 2002 11:42:19 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id AEE5019A31 for <9fans@cse.psu.edu>; Tue, 5 Feb 2002 11:41:48 -0500 (EST) Received: from acm.org ([144.135.25.87]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GR2JXF00.9TH for <9fans@cse.psu.edu>; Wed, 6 Feb 2002 02:46:27 +1000 Received: from CPE-144-136-80-227.nsw.bigpond.net.au ([144.136.80.227]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0h 125/7162407); 06 Feb 2002 02:39:13 Message-ID: <3C600AB2.128AC713@acm.org> From: Graham Gallagher X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: 9fans@cse.psu.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [9fans] Font behaviour Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 06 Feb 2002 03:39:14 +1100 I've been creating a range of fonts via a truetype to font(6) bitmap generator I wrote. One thing I noticed was that when trying to render characters possessing a zero width escapement value, they were transmogrified into PJW. This is really annoying because some glyphs, Thai vowels and tones for instance, are intentionally designed to have zero width escapement vectors for ease of placement. Investigation of loadchar() in libdraw/font.c (image/font.c under Inferno) reveals that indeed a test is made to check for zero width characters. Is there a reason why this test can't be removed? --upas-mrupstnyamdkoforcyddmptxwx--