On 8/21/2011 7:34 PM, Doug Ewell wrote:
So what you are asking about is a directional control character that would
assign subsequent characters a BC of 'AL', right?
You don't want to call this a LANGUAGE MARK or anything else that implies language
identification, because of the existence of "r
On 08/22/2011 12:53 AM, Shriramana Sharma wrote:
On 08/22/2011 12:01 AM, Peter Constable wrote:
If you mean a rule to substitute [g1 g2] with [g3] won't apply if the
sequence processed by the OpenType Layout lookup processor is [g2
g1],
Peter, actually I suspect Philippe is thinking that in th
On 08/22/2011 08:24 AM, Peter Constable wrote:
I'm not saying that there shouldn't be_some_ software that can do
what you expect. But there will likely be some different views on
what ought to be included within that "some".
Peter, given that both AAT and Graphite have provisions for assigning
On 08/22/2011 12:01 AM, Peter Constable wrote:
If you mean a rule to substitute [g1 g2] with [g3] won't apply if the
sequence processed by the OpenType Layout lookup processor is [g2
g1],
Peter, actually I suspect Philippe is thinking that in the case of RTL,
the *glyphs* are placed in reverse
Um... Computers are hardware, and don't understand a thing. What I think you
mean is computer _software_. (I know, I'm being pedantic, but with good
reason.)
The question is, whether you need a protocol that can be understood by _all_
computer software, or by _some_ computer software. Obviousl
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Asmus Freytag
> Treating PUA characters as ON is very problematic
As would be changing the default property of PUA characters from L to ON.
Peter
So what you are asking about is a directional control character that would
assign subsequent characters a BC of 'AL', right?
You don't want to call this a LANGUAGE MARK or anything else that implies
language identification, because of the existence of "real" language
identification mechanisms a
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>> As I explained in an earlier message, the layout engine doesn't use
>> the "default" property value but the resolved bidi level.
>
> Once again, you refuse to understand my arguments.
I don't think I'm refusing to u
On Sun, 21 Aug 2011 16:37:34 -0700
Asmus Freytag wrote:
> Treating PUA characters as ON is very problematic - their display
> would become context sensitive in unintended ways. No users of CJK
> characters would think of using LRM characters, but if text is
> inserted or viewed in RTL context, it
On Sun, 21 Aug 2011 23:55:46 +
"Doug Ewell" wrote:
> What's a LANGUAGE MARK?
There are *three* strong directionalities - 'L' left-to-right, 'AL'
right-to-left as in Arabic, 'R' right-to-left (as in Hebrew, I
suspect). 'AL' and 'R' have different effects on certain characters
next to digits
On 22 Aug 2011, at 00:37, Asmus Freytag wrote:
> If your implementation supported the directional overrides, it would be
> possible to use these to lay out any RTL text in a portable manner. Just
> enclose any RTL run with RLO and PDF (pop directional formatting).
>
> No impact on any existing
I suggested 'R' for Plane 16, not 'ON'.
What's a LANGUAGE MARK?
--
Doug Ewell • d...@ewellic.org
Sent via BlackBerry by AT&T
-Original Message-
From: Richard Wordingham
Sender: unicode-bou...@unicode.org
Date: Sun, 21 Aug 2011 23:31:58
To:
Subject: Re: RTL PUA?
On Sun, 21 Aug 2011 11
On 8/21/2011 3:31 PM, Richard Wordingham wrote:
On Sun, 21 Aug 2011 11:00:26 -0600
"Doug Ewell" wrote:
I think as soon as we start talking about this many scenarios, we are
no longer talking about what the *default* bidi class of the PUA (or
some part of it) should be. Instead, we are talking
2011/8/21 Doug Ewell :
> For once, I am in strong agreement with something Philippe had to say:
>
>> We really need a raliable way to transport a PUA agreement in such a
> way that it can be understood by a computer.
>
> I don't necessarily agree that fonts, or (especially) any particular font
> t
On Sun, 21 Aug 2011 11:00:26 -0600
"Doug Ewell" wrote:
> I think as soon as we start talking about this many scenarios, we are
> no longer talking about what the *default* bidi class of the PUA (or
> some part of it) should be. Instead, we are talking about being able
> to specify private custom
2011/8/21 Arno Schmitt :
> Philippe,
> Philippe> The rule relative to the shadda is so strong that this is even one
> of
> Philippe> the very first thing you're taught in some didactic tutorials on how
> Philippe> to read Arabic.
>
> the rule is not valid for most orthographies of the Koran
OK, b
For once, I am in strong agreement with something Philippe had to say:
> We really need a raliable way to transport a PUA agreement in such a
way that it can be understood by a computer.
I don't necessarily agree that fonts, or (especially) any particular font
technology, are the one and only wa
2011/8/21 Peter Constable :
> From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>
>> A GSUB operation will only be used if it is specified in the correct feature
>> table. The problem here is which feature to use: "rtlm" or "ltrm" ? It's
>> impossible to know because it f
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
> A GSUB operation will only be used if it is specified in the correct feature
> table. The problem here is which feature to use: "rtlm" or "ltrm" ? It's
> impossible to know because it first depend on the layout engine
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>> In the OpenType specification
> In addition, this specification highly depends on two things:
> - the layout engine fully knows the properties of all characters in
> order to implement BiDi reordering as well as
2011/8/21 Peter Constable :
>> Exactly, but mirroring data for remapping glyphs will not be be part of that
>> font.
>
> Um... Why not? If the mirroring isn't in reflected in
> http://www.unicode.org/Public/5.1.0/ucd/BidiMirroring.txt, then it must be
> handled by glyph substitution in the font a
Petr Tomasek wrote:
Not in Hebrew. The only common ligature is the aleph_lamed, a
post-classical import from Judaeo-Arabic.
Not true. See:
Collete Sirat. Hebrew Manuscripts of the Middle Ages. Cambridge University
Press 2002,
fig. 114 (p. 176) or fig. 127 (p. 189) or fig. 134 (p. 193).
I w
2011/8/21 Peter Constable :
> In the OpenType specification, the only data related to glyph mirroring that
> a rendering engine is assumed to have is the bidi mirroring data from TUS
> 5.1. (See http://www.microsoft.com/typography/otspec/TTOCHAP1.htm#ltrrtl.)
> All other glyph mirroring is to be
On Sun, Aug 21, 2011 at 10:09:22AM -0700, John Hudson wrote:
> Jonathan Rosenne wrote:
>
> >People do all kinds of fancy things. I guess old manuscripts contain many
> >ligatures...
>
> Not in Hebrew. The only common ligature is the aleph_lamed, a
> post-classical import from Judaeo-Arabic.
>
>
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
>> I agree that OpenType font tables cannot to glyph re-ordering. But totally
>> incorrect in saying that it cannot handle ligatures.
> I meant "recognizing and generating ligatures in the context where
> re-ordering h
On 08/21/2011 01:09 PM, John Hudson wrote:
Jonathan Rosenne wrote:
People do all kinds of fancy things. I guess old manuscripts contain
many
ligatures...
Not in Hebrew. The only common ligature is the aleph_lamed, a
post-classical import from Judaeo-Arabic.
Closest you might have to "ligatu
mmarx wrote:
I am so pleased that there are some people on
the list interested in RTL scripts after all.
encoded are
ARABIC LETTER YEH (U+064A) with two dots under the
main part of the letter
ييي ي
ARABIC LETTER FARSI YEH (U+06CC) wit
2011/8/21 Peter Constable :
> From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
> Behalf Of Philippe Verdy
>
>> Hmmm Given the current standard in OpenType, and the fact that
>> OpenType fonts cannot reorder glyphs to support the BiDi algorithm
>> and correctly handle fea
Perhaps it would help for you to do a quick survey of applications that
already make use of the existing C0 control pictures, and include the
results in your argument. That might help convince some of us who feel
the C0 pictures are only there for compatibility with previous character
encoding
Jonathan Rosenne wrote:
People do all kinds of fancy things. I guess old manuscripts contain many
ligatures...
Not in Hebrew. The only common ligature is the aleph_lamed, a
post-classical import from Judaeo-Arabic.
JH
--
Tiro Typeworkswww.tiro.com
Gulf Islands, BC t...@tiro.
Philippe,
what you say about "no exception" is wrong,
as you can see from the attachments.
Philippe> I was told long ago that the normative placement of kasra below the
Philippe> letter was also requiring it to go below the shadda (above the letter)
Philippe> when there was one, and this suffered
I think as soon as we start talking about this many scenarios, we are no
longer talking about what the *default* bidi class of the PUA (or some
part of it) should be. Instead, we are talking about being able to
specify private customizations, so that one can have 'AL' runs and 'ON'
runs and so
Hi Ken et. al.,
On Aug 17, 2011, at 2:49 PM, Ken Whistler wrote:
>
> Further comments:
>
> On 8/13/2011 10:48 AM, Sean Leonard wrote:
>> In accordance with this and other text in the Standard, it is not really
>> possible to assign glyphs uniformly and interchangeably to the code points
>> in
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
> Hmmm Given the current standard in OpenType, and the fact that
> OpenType fonts cannot reorder glyphs to support the BiDi algorithm
> and correctly handle featues like ligatures...
I agree th
On Sun, 21 Aug 2011 01:44:02 +
"Doug Ewell" wrote:
>> The more I think of it, the more I like the idea of reassigning the
>> default BC of Plane 16 to 'R'. What would the arguments against this
>> be?
>> BC of 'AL'?
> Would that really be a better default? I thought the main RTL needs
> fo
From: unicore-boun...@unicode.org [mailto:unicore-boun...@unicode.org] On
Behalf Of Michael Everson
>> Yeah OK maybe simply base+diacritic stuff or even ligatures would be
>> easy to do via simple substitution rules in tables, but how about glyph
>> reordering?
> No problem unless you are usi
On 08/21/2011 08:19 AM, Asmus Freytag wrote:
The best default would be an explicit "PU" - undefined behavior in the
absence of a private agreement.
Hm -- but really this would only serve to allay concerns like Michael's
stemming from a presumption that the BC is "deeper" than other
characters
People do all kinds of fancy things. I guess old manuscripts contain many
ligatures, but I don't think this kind of joining should be required for the
RTL PUA.
Jony
> -Original Message-
> From: unicore-boun...@unicode.org [mailto:unicore-boun...@unicode.org] On
> Behalf Of Michael Everson
On 21 Aug 2011, at 10:43, Jonathan Rosenne wrote:
> Yes, this is why an RTL etc. PUA area is quite useful.
>
> BTW, I am not aware of joining in properly written cursive Hebrew.
I've seen a nice shin-lamed ligature in some styles.
Michael Everson * http://www.evertype.com/
Yes, this is why an RTL etc. PUA area is quite useful.
BTW, I am not aware of joining in properly written cursive Hebrew.
Jony
> -Original Message-
> From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe
> Verdy
> Sent: Sunday, August 21, 2011 12:16 PM
> To: Jonathan Ros
2011/8/21 Jonathan Rosenne :
> Several RTL scripts do not require shaping nor ligatures.
Yes but they still require BiDi reordering by the layout engine...
Something that is not specified by OpenType fonts because it is
implicit (and in fact mandatory) for the known RTL scripts assigned in
non-PUA
2011/8/20 mmarx :
> In the Qur'an the hamza is not always above:
> if there is kasra on the letter, the hamza
> is below too.
>
> Is there someone preparing a proposal for
> missing Quranic characters or should one
> do it one by one?
I was told long ago that the normative placement of kasra belo
Several RTL scripts do not require shaping nor ligatures.
Jony
> -Original Message-
> From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
> Behalf Of Philippe Verdy
> Sent: Sunday, August 21, 2011 10:29 AM
> To: Michael Everson
> Cc: unicore UnicoRe Discussion; Unicode
On 21 Aug 2011, at 02:44, Doug Ewell wrote:
> Would that really be a better default? I thought the main RTL needs for the
> PUA would be for unencoded scripts, not for even more Arabic letters.
Could easily be for work on new Arabic-script orthographies which use new
letters. Or for similar scr
2011/8/20 Ken Whistler :
> There are 131,068 private use code points in the standard. That is all there
> ever will be.
I also fully agree (sorry then to Michael Everson support for such new
RTL PUA assignments).
All that can be done is to fix the softwares. Notably the font formats
where you'll
On Sun, Aug 21, 2011 at 12:21:28AM +, Doug Ewell wrote:
> The more I think of it, the more I like the idea of reassigning the default
> BC of Plane 16 to 'R'. What would the arguments against this be?
>
I found a font ("Asana Math") installed on my system that occupies
U+10fddf..U+10fffd.
2011/8/19 Michael Everson :
> There is plenty of space. There would be no difficulty in assigning some rows
> to a RTL PUA. Mucking about with the directionality of the existing PUA would
> be extremely unwise.
>
>> Conceivably certain closed user-groups could be using closed-distribution
>> ren
47 matches
Mail list logo
