From rick@unicode.org Fri Jun 3 15:10:34 2005 Received: with ECARTIS (v1.0.0; list hebrew); Fri, 03 Jun 2005 16:48:15 -0500 (CDT) Received: from izanami (ip-216-36-75-240.sjc.megapath.net [216.36.75.240]) by unicode.org (8.12.11/8.12.11) with SMTP id j53K9VEd007718; Fri, 3 Jun 2005 15:09:31 -0500 Message-Id: <200506032009.j53K9VEd007718@unicode.org> To: unicode@unicode.org Subject: [hebrew] CLDR Version 1.3 Released Date: Fri, 3 Jun 2005 13:09:30 -0700 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 2971 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: hebrew The Unicode Consortium announced on 2005-06-02 the release of new versions of the Common Locale Data Repository (CLDR 1.3) and the Locale Data Markup Language specification (LDML 1.3), providing key building blocks for software to support the world's languages. CLDR is by far the largest standard repository of locale data. This new release contains data for 296 locales: 96 languages and 130 territories. For the first time in CLDR, POSIX formatted data is also available. For the press release, see: http://www.unicode.org/press/pr-cldr1.3.html For version information, see: http://www.unicode.org/cldr/version/1.3.html For a list of contributors, see: http://www.unicode.org/reports/tr35/#Acknowledgments From rick@unicode.org Mon Jun 20 15:50:19 2005 Received: with ECARTIS (v1.0.0; list hebrew); Mon, 20 Jun 2005 15:52:26 -0500 (CDT) Received: from izanami (ip-216-36-75-240.sjc.megapath.net [216.36.75.240]) by unicode.org (8.12.11/8.12.11) with SMTP id j5KKoDL0011169 for ; Mon, 20 Jun 2005 15:50:16 -0500 Message-Id: <200506202050.j5KKoDL0011169@unicode.org> To: hebrew@unicode.org Subject: [hebrew] New Public Review Issues Date: Mon, 20 Jun 2005 13:50:13 -0700 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 2972 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: hebrew The Unicode Technical Committee has posted two new issues for public review and comment. Details are on the following web page: http://www.unicode.org/review/ Review periods for the new items close on August 9, 2005. Please see the page for links to discussion and relevant documents. Briefly, the new issues are: 72 Stability of the Bidi Mirrored Property In a bidirectional context, the images of many characters need to be oriented depending on the writing direction of the text in which they occur. The Bidi Mirrored property defines this behavior, but the model it implements has a few inconsistencies. Ideally, these would be corrected, but doing so will destabilize all documents containing the affected characters. A stability policy would freeze future changes, but should one last round of improvements be carried out? Your input on the range of possible actions is solicited, whether you are a language expert, user. or implementer. 73 Representative Glyphs for Arabic Characters U+06DF, U+06E0, and U+06E1 The representative glyphs for several Arabic characters used to annotate the Koran have been reported as being possibly incorrect. The UTC has tentatively decided to revise them as explained in the accompanying document. The UTC invites anyone knowledgeable in their use to provide additional information or recommendations. If you have comments for official UTC consideration, please post them by submitting your comments through our feedback & reporting page: http://www.unicode.org/reporting.html If you wish to discuss issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as input to the UTC. You must use the reporting link above to generate comments for UTC consideration. http://www.unicode.org/consortium/distlist.html Regards, Rick McGowan Unicode, Inc. From rick@unicode.org Mon Jun 27 15:02:14 2005 Received: with ECARTIS (v1.0.0; list hebrew); Mon, 27 Jun 2005 16:58:55 -0500 (CDT) Received: from izanami (ip-216-36-75-240.sjc.megapath.net [216.36.75.240]) by unicode.org (8.12.11/8.12.11) with SMTP id j5RK2ChV007562; Mon, 27 Jun 2005 15:02:13 -0500 Message-Id: <200506272002.j5RK2ChV007562@unicode.org> To: unicode@unicode.org Subject: [hebrew] Notification re UTR #36, Security Issues Date: Mon, 27 Jun 2005 13:02:13 -0700 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 2973 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk X-list: hebrew Due to computer security issues, a set of guidelines is being drafted that can impact the use of future International Domain Names (i.e., http://müller.de/ ) and identifiers. The computer security issues that have arisen involve spoofing of letters or numbers (e.g., in a recent case, unsuspecting users were sending credit card information to "PayPal.com" which was spelled with a capital "I" in place of lowercase "L", because the two are not visibly distinct in some fonts). Similarly Cyrillic or Greek letters could be used in lieu of similar looking Latin letters in domain names. The current draft Unicode Technical Report #36 contains guidelines that suggest restricting a variety of characters; they would only be permitted under lenient security settings. See http://www.unicode.org/draft/reports/tr36/tr36.html. The document is a working draft, and both it and the data files it points to may be edited up to the time it is released. Because of the subject matter, this draft will be released very soon, but there is still some time for feedback. Comments received by the end of this week (July 1) can be considered for this version of the document, while those after that point will be considered for the next version. Comments should be sent via http://unicode.org/reporting.html . You many find it useful to look at the characters listed in the following file: http://unicode.org/draft/reports/tr36/data/draft-restrictions.txt . These lists include a representation of the characters, but the image may not appear on your screen depending on the fonts installed on your machine; you may need to use the character code numbers [or names] and refer to the code charts at http://www.unicode.org/charts/.) From tiro@tiro.com Wed Jun 29 10:37:07 2005 Received: with ECARTIS (v1.0.0; list hebrew); Wed, 29 Jun 2005 13:31:17 -0500 (CDT) Received: from priv-edtnes63.telusplanet.net (defout.telus.net [199.185.220.240]) by unicode.org (8.12.11/8.12.11) with ESMTP id j5TFb79P032729; Wed, 29 Jun 2005 10:37:07 -0500 Received: from [154.5.24.36] by priv-edtnes51.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050629082725.RUQY18656.priv-edtnes51.telusplanet.net@[154.5.24.36]>; Wed, 29 Jun 2005 02:27:25 -0600 Message-ID: <42C25B6D.3030209@tiro.com> Date: Wed, 29 Jun 2005 01:27:25 -0700 From: John Hudson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Unicode Mailing List , Hebrew List Subject: [hebrew] Baseline level line? References: <42C21ACF.2020006@adobe.com> <42C2299C.9090100@tiro.com> In-Reply-To: <42C2299C.9090100@tiro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2974 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: tiro@tiro.com Precedence: bulk X-list: hebrew Some academic works on Hebrew show vowel and cantillation marks independently of Hebrew letters by placing them relative to a line which indicates the position of the baseline. Others use the dotted circle, as the Unicode Standard does, while others use a ring, square or simply a blank space. I'm aiming to support all of these conventions in the new version of my SBL Hebrew font. There doesn't seem to be in Unicode a character that is a line positioned on the baseline. The closest I've found is the underscore (U+005F LOW LINE), which typically sits below the baseline. I can perform a contextual substitution to raise this line when it is immediately followed by a Hebrew mark, but I'm wondering if there might be a more ideal candidate. Obviously, I'm looking for an immediate solution, but if there is nothing better than U+005F, I'd also be interested to know if anyone thinks it would be worthwhile to propose a baseline level line character for this purpose. John Hudson -- Tiro Typeworks www.tiro.com Vancouver, BC tiro@tiro.com Currently reading: Truth and tolerance, by Benedict XVI, Cardinal Ratzinger as was An autobiography from the Jesuit underground, by William Weston SJ War (revised edition), by Gwynne Dyer From dean.snyder@jhu.edu Thu Jun 30 01:08:20 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 06:22:31 -0500 (CDT) Received: from ipex3.johnshopkins.edu (ipex3.johnshopkins.edu [128.220.2.141]) by unicode.org (8.13.4/8.12.11) with ESMTP id j5U68JLK007458; Thu, 30 Jun 2005 01:08:20 -0500 Received: from jhuml3.jhu.edu (128.220.2.66) by ipex3.johnshopkins.edu with ESMTP; 29 Jun 2005 19:06:14 -0400 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,243,1115006400"; d="scan'208"; a="69727426:sNHT19865520" Received: from [192.168.1.100] (railroadpa-bsr1_eycb01-00-rlrd-67-23-89-15.chvlva.adelphia.net [67.23.89.15]) by jhuml3.jhu.edu (PMDF V6.2-X20 #30840) with ESMTPA id <0IIV00I1EC6K0J@jhuml3.jhu.edu>; Wed, 29 Jun 2005 19:06:21 -0400 (EDT) Date: Wed, 29 Jun 2005 19:06:19 -0400 From: Dean Snyder Subject: [hebrew] Re: Baseline level line? In-reply-to: <42C25B6D.3030209@tiro.com> To: Unicode List , Hebrew List Message-id: <20050629230619.23651@smtp.jhu.edu> MIME-version: 1.0 X-Mailer: CTM PowerMail version 5.2.1 build 4397 English Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <42C21ACF.2020006@adobe.com> <42C2299C.9090100@tiro.com> <42C25B6D.3030209@tiro.com> X-archive-position: 2975 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: dean.snyder@jhu.edu Precedence: bulk X-list: hebrew John Hudson wrote at 1:27 AM on Wednesday, June 29, 2005: >I'd also be interested to know if anyone >thinks it would be worthwhile to propose a baseline level line character >for this purpose. If it were a combining character it could be useful for indicating the baseline in all sorts of contexts. Respectfully, Dean A. Snyder Assistant Research Scholar Manager, Digital Hammurabi Project Computer Science Department Whiting School of Engineering 218C New Engineering Building 3400 North Charles Street Johns Hopkins University Baltimore, Maryland, USA 21218 office: 410 516-6850 cell: 717 817-4897 www.jhu.edu/digitalhammurabi/ http://users.adelphia.net/~deansnyder/ From tiro@tiro.com Thu Jun 30 02:01:05 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 06:22:52 -0500 (CDT) Received: from priv-edtnes57.telusplanet.net (outbound01.telus.net [199.185.220.220]) by unicode.org (8.13.4/8.12.11) with ESMTP id j5U714am026605; Thu, 30 Jun 2005 02:01:05 -0500 Received: from [154.5.24.36] by priv-edtnes57.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050630070058.GFTM19474.priv-edtnes57.telusplanet.net@[154.5.24.36]>; Thu, 30 Jun 2005 01:00:58 -0600 Message-ID: <42C398A6.9040301@tiro.com> Date: Thu, 30 Jun 2005 00:00:54 -0700 From: John Hudson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Unicode List , Hebrew List Subject: [hebrew] Re: Baseline level line? References: <42C21ACF.2020006@adobe.com> <42C2299C.9090100@tiro.com> <42C25B6D.3030209@tiro.com> <20050629230619.23651@smtp.jhu.edu> In-Reply-To: <20050629230619.23651@smtp.jhu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2976 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: tiro@tiro.com Precedence: bulk X-list: hebrew Dean Snyder wrote: > If it were a combining character it could be useful for indicating the > baseline in all sorts of contexts. I'm specifically looking for a base, not a combining mark. The tablua accentum on the handy bookmark that came with my BHS uses the convention to which I refer: a line relative to which the nikud and te'amim are positioned. Personally, I think it is a lousy convention: the dotted circle or some other generic mark that approximates the proportions of an actual letter is better than this line. An application should be able to indicate the baseline, if that is a desirable feature. Having a baseline indicator as a combining character is unnecessarily complex. John Hudson -- Tiro Typeworks www.tiro.com Vancouver, BC tiro@tiro.com Currently reading: Truth and tolerance, by Benedict XVI, Cardinal Ratzinger as was An autobiography from the Jesuit underground, by William Weston SJ War (revised edition), by Gwynne Dyer From everson@evertype.com Thu Jun 30 05:00:33 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 06:23:14 -0500 (CDT) Received: from ni-mail2.dna.utvinternet.net (ni-mail2.u.tv [194.46.8.26] (may be forged)) by unicode.org (8.13.4/8.12.11) with ESMTP id j5UA0Rbp006375; Thu, 30 Jun 2005 05:00:32 -0500 Received: from [10.0.1.2] (unverified [195.218.107.140]) by ni-mail2.dna.utvinternet.net (Vircom SMTPRS 4.1.361.18) with ESMTP id ; Thu, 30 Jun 2005 11:00:21 +0100 Mime-Version: 1.0 X-Sender: evr001@mail.dna.ie Message-Id: In-Reply-To: <42C25B6D.3030209@tiro.com> References: <42C21ACF.2020006@adobe.com> <42C2299C.9090100@tiro.com> <42C25B6D.3030209@tiro.com> Date: Thu, 30 Jun 2005 10:59:10 +0100 To: Unicode Mailing List , Hebrew List From: Michael Everson Subject: [hebrew] Re: Baseline level line? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-archive-position: 2977 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: everson@evertype.com Precedence: bulk X-list: hebrew At 01:27 -0700 2005-06-29, John Hudson wrote: >I'm looking for an immediate solution, but if there is nothing >better than U+005F, I'd also be interested to know if anyone thinks >it would be worthwhile to propose a baseline level line character >for this purpose. One would have to show it contrasting with LOW LINE, I suspect. -- Michael Everson * * Everson Typography * * http://www.evertype.com From petercon@microsoft.com Thu Jun 30 09:53:37 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 11:42:12 -0500 (CDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by unicode.org (8.13.4/8.12.11) with ESMTP id j5UErTXl029182; Thu, 30 Jun 2005 09:53:37 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 07:53:29 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 07:53:28 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [hebrew] Re: Baseline level line? Date: Thu, 30 Jun 2005 07:53:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [hebrew] Baseline level line? Thread-Index: AcV9RHq+zHA5kyLuRMGH4JG9eG6dbgANCFzw From: "Peter Constable" To: "Unicode List" , "Hebrew List" X-OriginalArrivalTime: 30 Jun 2005 14:53:28.0766 (UTC) FILETIME=[79CE05E0:01C57D83] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id j5UErTXl029182 X-archive-position: 2978 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: petercon@microsoft.com Precedence: bulk X-list: hebrew > From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org] On > Behalf Of John Hudson > > If it were a combining character it could be useful for indicating the > > baseline in all sorts of contexts. > > I'm specifically looking for a base, not a combining mark. If there was an invisible base letter for it to sit on, then the baseline could be a combining mark. (It's not clear to me, though, how useful it would be to have a combining basesline mark in all sorts of contexts. I'd need to see some examples.) While I supported the invisible letter proposal, what I really favoured was an ellipsis base letter -- that is, a character that functions like a surrogate base when an actual base is not present, and that can take alternate visual realizations, such as a blank, a line or an x-height asterisk. Peter Constable From everson@evertype.com Thu Jun 30 11:25:25 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 11:43:35 -0500 (CDT) Received: from ni-mail1.dna.utvinternet.net (ni-mail1.u.tv [194.46.8.62] (may be forged)) by unicode.org (8.13.4/8.12.11) with ESMTP id j5UGPOqU031384; Thu, 30 Jun 2005 11:25:25 -0500 Received: from [10.0.1.2] (unverified [195.218.107.244]) by ni-mail1.dna.utvinternet.net (Vircom SMTPRS 4.1.361.20) with ESMTP id ; Thu, 30 Jun 2005 17:25:18 +0100 Mime-Version: 1.0 X-Sender: evr001@mail.dna.ie Message-Id: In-Reply-To: References: Date: Thu, 30 Jun 2005 17:25:13 +0100 To: "Unicode List" , "Hebrew List" From: Michael Everson Subject: [hebrew] Re: Baseline level line? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-archive-position: 2979 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: everson@evertype.com Precedence: bulk X-list: hebrew At 07:53 -0700 2005-06-30, Peter Constable wrote: > > I'm specifically looking for a base, not a combining mark. > >If there was an invisible base letter for it to sit on, then the >baseline could be a combining mark. > >While I supported the invisible letter proposal, what I really favoured >was an ellipsis base letter -- that is, a character that functions like >a surrogate base when an actual base is not present, and that can take >alternate visual realizations, such as a blank, a line or an x-height >asterisk. I don't quite understand what you mean by the latter is, but I certainly still do support the invisible letter proposal. -- Michael Everson * * Everson Typography * * http://www.evertype.com From petercon@microsoft.com Thu Jun 30 11:57:57 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 14:31:12 -0500 (CDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by unicode.org (8.13.4/8.12.11) with ESMTP id j5UGvqJH003437; Thu, 30 Jun 2005 11:57:56 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 09:57:52 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 09:57:51 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [hebrew] Re: Baseline level line? Date: Thu, 30 Jun 2005 09:57:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [hebrew] Re: Baseline level line? Thread-Index: AcV9k27Ud8rYcAZxTGW780fO4mVTOQAAK3HA From: "Peter Constable" To: "Unicode List" , "Hebrew List" X-OriginalArrivalTime: 30 Jun 2005 16:57:51.0614 (UTC) FILETIME=[DA0241E0:01C57D94] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id j5UGvqJH003437 X-archive-position: 2980 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: petercon@microsoft.com Precedence: bulk X-list: hebrew > From: hebrew-bounce@unicode.org [mailto:hebrew-bounce@unicode.org] On Behalf > Of Michael Everson > >While I supported the invisible letter proposal, what I really favoured > >was an ellipsis base letter -- that is, a character that functions like > >a surrogate base when an actual base is not present, and that can take > >alternate visual realizations, such as a blank, a line or an x-height > >asterisk. > > I don't quite understand what you mean by the latter is I mean a character with a general category Lo and other character properties typical of a letter, though with neutral directionality. The representative glyph would have advance but no ink; valid font implementations could have ink -- e.g. a hyphen or asterisk -- and could offer alternate glyphs (using font features). Because glyphs *could* have ink, I would not call this "invisible letter"; something like "ellipsis letter" would be more appropriate. Peter Constable From peterkirk@qaya.org Thu Jun 30 12:54:54 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 14:32:57 -0500 (CDT) Received: from pan.hu-pan.com ([67.15.6.3]) by unicode.org (8.13.4/8.12.11) with ESMTP id j5UHspTA016935 for ; Thu, 30 Jun 2005 12:54:54 -0500 Received: from 213-162-124-237.peterk253.adsl.metronet.co.uk ([213.162.124.237] helo=[10.0.0.1]) by pan.hu-pan.com with esmtpa (Exim 4.50) id 1Do3E1-00039x-D1; Thu, 30 Jun 2005 18:54:48 +0100 Received: from 127.0.0.1 (AVG SMTP 7.0.323 [267.8.7]); Thu, 30 Jun 2005 18:53:20 +0100 Message-ID: <42C4318F.2000009@qaya.org> Date: Thu, 30 Jun 2005 18:53:19 +0100 From: Peter Kirk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-gb, en, en-us, az, ru, tr, he, el, fr, de To: Peter Constable CC: Hebrew List Subject: [hebrew] Re: Baseline level line? References: In-Reply-To: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pan.hu-pan.com X-AntiAbuse: Original Domain - unicode.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - qaya.org X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 2981 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: peterkirk@qaya.org Precedence: bulk X-list: hebrew On 30/06/2005 17:57, Peter Constable wrote: >>From: hebrew-bounce@unicode.org [mailto:hebrew-bounce@unicode.org] On >> >> >Behalf > > >>Of Michael Everson >> >> > > > > >>>While I supported the invisible letter proposal, what I really >>> >>> >favoured > > >>>was an ellipsis base letter -- that is, a character that functions >>> >>> >like > > >>>a surrogate base when an actual base is not present, and that can >>> >>> >take > > >>>alternate visual realizations, such as a blank, a line or an x-height >>>asterisk. >>> >>> >>I don't quite understand what you mean by the latter is >> >> > >I mean a character with a general category Lo and other character >properties typical of a letter, though with neutral directionality. The >representative glyph would have advance but no ink; valid font >implementations could have ink -- e.g. a hyphen or asterisk -- and could >offer alternate glyphs (using font features). Because glyphs *could* >have ink, I would not call this "invisible letter"; something like >"ellipsis letter" would be more appropriate. > > > It strikes me that this would simply confuse the issue. Users who wanted a "no ink" glyph for carrying a spacing diacritical mark would not be sure of getting what they wanted, whereas those who wanted a glyph to indicate the relative position of the mark would also not be sure of getting that. It seems to me that there is a need here for two distinct characters. But with the recent changes NBSP more or less does what is required for the "no ink" glyph. And for users who actually want a glyph it makes sense to allow them to choose their glyph, from the 100,000 plus already defined (!), rather than offer them some kind of lottery. Meanwhile John is proposing a specific form of glyph, which should always be visible, which is required to represent a specific text. I would support such a proposal. But maybe we should check that there are not already suitable characters defined, e.g. 2E0F, 0640. In fact I am surprised to see very nothing much which could be suitable. -- Peter Kirk peter@qaya.org (personal) peterkirk@qaya.org (work) http://www.qaya.org/ -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.7/34 - Release Date: 29/06/2005 From petercon@microsoft.com Thu Jun 30 13:39:06 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 14:34:23 -0500 (CDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by unicode.org (8.13.4/8.12.11) with ESMTP id j5UId537011820 for ; Thu, 30 Jun 2005 13:39:06 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 11:39:02 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Jun 2005 11:39:01 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Subject: [hebrew] Re: Baseline level line? Date: Thu, 30 Jun 2005 11:38:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [hebrew] Re: Baseline level line? Thread-Index: AcV9nNHoeq4y+4AoSruVea6KSa8uFgABdEjA From: "Peter Constable" To: "Hebrew List" X-OriginalArrivalTime: 30 Jun 2005 18:39:01.0620 (UTC) FILETIME=[FC03AB40:01C57DA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id j5UId537011820 X-archive-position: 2982 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: petercon@microsoft.com Precedence: bulk X-list: hebrew > From: Peter Kirk [mailto:peterkirk@qaya.org] > >I mean a character with a general category Lo and other character > >properties typical of a letter, though with neutral directionality. The > >representative glyph would have advance but no ink; valid font > >implementations could have ink -- e.g. a hyphen or asterisk -- and could > >offer alternate glyphs (using font features). Because glyphs *could* > >have ink, I would not call this "invisible letter"; something like > >"ellipsis letter" would be more appropriate. > It strikes me that this would simply confuse the issue. Users who wantedý ý> a "no ink" glyph for carrying a spacing diacritical mark would not be ý> sure of getting what they wanted, whereas those who wanted a glyph to ý> indicate the relative position of the mark would also not be sure of ý> getting that. It seems to me that there is a need here for two distinct ý> characters. ý You're probably right. > But with the recent changes NBSP more or less does what is > required for the "no ink" glyph. Yes, except for word-boundary behaviour. Peter Constable From mark@kli.org Thu Jun 30 22:39:07 2005 Received: with ECARTIS (v1.0.0; list hebrew); Thu, 30 Jun 2005 22:43:20 -0500 (CDT) Received: from pi.meson.org (h-66-134-26-207.nycmny83.covad.net [66.134.26.207]) by unicode.org (8.13.4/8.12.11) with SMTP id j613csiO030868 for ; Thu, 30 Jun 2005 22:39:07 -0500 Received: (qmail 17698 invoked from network); 1 Jul 2005 03:38:49 -0000 Received: from nagas.meson.org (HELO ?192.168.1.101?) (1000@192.168.1.101) by pi.meson.org with SMTP; 1 Jul 2005 03:38:49 -0000 Message-ID: <42C4BAC8.2080405@kli.org> Date: Thu, 30 Jun 2005 23:38:48 -0400 From: "Mark E. Shoulson" User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Hudson CC: Unicode List , Hebrew List Subject: [hebrew] Re: Baseline level line? References: <42C21ACF.2020006@adobe.com> <42C2299C.9090100@tiro.com> <42C25B6D.3030209@tiro.com> <20050629230619.23651@smtp.jhu.edu> <42C398A6.9040301@tiro.com> In-Reply-To: <42C398A6.9040301@tiro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2983 X-Approved-By: jcowan@reutershealth.com X-ecartis-version: Ecartis v1.0.0 Sender: hebrew-bounce@unicode.org Errors-to: hebrew-bounce@unicode.org X-original-sender: mark@kli.org Precedence: bulk X-list: hebrew John Hudson wrote: > Dean Snyder wrote: > >> If it were a combining character it could be useful for indicating the >> baseline in all sorts of contexts. > > > I'm specifically looking for a base, not a combining mark. The tablua > accentum on the handy bookmark that came with my BHS uses the > convention to which I refer: a line relative to which the nikud and > te'amim are positioned. Personally, I think it is a lousy convention: > the dotted circle or some other generic mark that approximates the > proportions of an actual letter is better than this line. > Baseline works okay with under-the-letter vowels or accents; it's lousy for things positioned anywhere else. > An application should be able to indicate the baseline, if that is a > desirable feature. Having a baseline indicator as a combining > character is unnecessarily complex. > That's the thing, Dean has a good point. It would seem to be a Useful Thing to be able to show the baseline, not necessarily with a character involved (i.e. I don't think such a baseline character should necessarily be combining; it would be good as a base). Such a thing wouldn't/shouldn't be peculiar to Hebrew; baseline is a common feature in much of typesetting. Is it really character-worthy? Ummmmm... maybe. The world isn't going to come to a screeching halt without one, but the idea has some merit. Might be better to find some support for it in print. (is 0640 good for it, as suggested?) ~mark