2011/8/24 John Hudson j...@tiro.ca:
Philippe, I'll need to think about this some more and try to get a better
grasp of what you're suggesting. But some immediate thoughts come to mind:
If BiDi is to be applied to shaped glyph strings, surely that means needing
to step backwards through the
On Tuesday 23 August 2011, Doug Ewell d...@ewellic.org wrote:
Asmus Freytag asmusf at netcom dot com wrote:
Until then, I find further speculation rather pointless and would love if
it moved off this list (until such time).
+1
-0.7
It is harmless fun, indeed it is fun that assists
On Wed, 24 Aug 2011 07:34:05 +0200
Philippe Verdy verd...@wanadoo.fr wrote:
2011/8/24 Luke-Jr l...@dashjr.org:
On Tuesday, August 23, 2011 10:29:58 PM Philippe Verdy wrote:
Even the UTC could create its own PUA registry,
It won't. The best you can hope for is a list of registries.
Now
On 23 août 2011 21:44 Richard Wordingham
richard.wording...@ntlworld.com richard.wording...@ntlworld.com
wrote:
On Tue, 23 Aug 2011 07:18:21 +0200
Jean-François Colson j...@colson.eu j...@colson.eu wrote:
And what dou you think about (H1,H2,VS1,L3,L4)?
The L4 is unnecessary. The trick
Thank you to Doug and to Asmus for replying.
Originally I was thinking of the format simply being so as to help to level the
infrastructural ground as between a PUA (Private Use Area) application using
left-to-right characters and a PUA application using right-to-left characters.
However,
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
(1) a plain-text file
(2) using only plain-text conventions (i.e. not adding rich text)
(3) which contains the same PUA code point with two meanings
(4) using different fonts or other mechanisms
(5) in a platform-independent,
Luke-Jr luke at dashjr dot org wrote:
Too bad the Conscript registry is censoring assignments the maintainer
doesn't like for unspecified personal reasons, increasing the chances
of an overlap.
This isn't censorship, which would imply some sort of political,
ethical, or moral agenda. This is
John Hudson 於 2011年8月23日 下午9:08 寫道：
I think you may be right that quite a lot of existing OTL functionality
wouldn't be affected by applying BiDi after glyph shaping: logical order and
resolved order are often identical in terms of GSUB input. But it is in the
cases where they are not
Asmus Freytag 於 2011年8月23日 下午2:00 寫道：
Until then, I find further speculation rather pointless and would love if it
moved off this list (until such time).
That would be wonderful, because we could then turn our attention to more
urgent subjects, such as what to do when the sun reaches
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
Until then, I find further speculation rather pointless and would
love if it moved off this list (until such time).
It is harmless fun, indeed it is fun that assists learning and
understanding, and so as long as it
On Wed, 24 Aug 2011 08:02:42 -0700
Doug Ewell d...@ewellic.org wrote:
But some people seem to be dead serious about the need to go beyond
1.1 million code points, and are making dead-serious arguments that
we need to plan for it.
Those are two different claims. 'Never say never' is a useful
On Wed, 24 Aug 2011 08:35:48 -0700
Doug Ewell d...@ewellic.org wrote:
UAX #44, Table 13 (Bidi_Class Values) includes the following
descriptions:
R - Right_To_Left - any strong right-to-left (non-Arabic-type)
character AL - Arabic_Letter - any strong right-to-left (Arabic-type)
character
On 8/24/2011 10:48 AM, Richard Wordingham wrote:
Those are two different claims. 'Never say never' is a useful maxim.
So is Leave well enough alone.
The problem would be in using maxims instead
of an analysis of engineering requirements to drive architectural decisions.
The extension of
On Wed, Aug 24, 2011 at 12:35 PM, Richard Wordingham
richard.wording...@ntlworld.com wrote:
Expanding on Mark's answer, the basic difference is whether a character
of Bidi class ET (percentage-type and currency symbols) when stored
before or after European or Persian etc. digits goes to their
On Wed, 24 Aug 2011 12:40:54 -0700
Ken Whistler k...@sybase.com wrote:
On 8/24/2011 10:48 AM, Richard Wordingham wrote:
if, say,
code points are squandered.
Oh.
Well, in that case, the correct action is to work to ensure that code
points are not squandered.
Have there not already
It has ceased to be. It's expired and gone to meet its maker. It's a stiff.
Bereft of life, it rests in peace.…Its metabolic processes are now history.
It's off the twig. It's kicked the bucket, it's shuffled off its mortal coil,
run down the curtain and joined the bleedin' choir invisible.
2011/8/24 John H. Jenkins jenk...@apple.com:
John Hudson 於 2011年8月23日 下午9:08 寫道：
I think you may be right that quite a lot of existing OTL functionality
wouldn't be affected by applying BiDi after glyph shaping: logical order and
resolved order are often identical in terms of GSUB input.
On 8/24/2011 3:51 PM, Richard Wordingham wrote:
Well, in that case, the correct action is to work to ensure that code
points are not squandered.
Have there not already been several failures on that front? The BMP is
littered with concessions to the limitations of rendering systems -
2011/8/24 Doug Ewell d...@ewellic.org:
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
(1) a plain-text file
(2) using only plain-text conventions (i.e. not adding rich text)
(3) which contains the same PUA code point with two meanings
(4) using different fonts or other mechanisms
2011/8/25 Richard Wordingham richard.wording...@ntlworld.com:
It will only happen when the need becomes obvious, which may be never,
or may be 30 years hence. It's even conceivable that UTF-16 will
drop out of use.
Conceivable but extremely unlikely because it will remain used in
extremely
2011/8/24 Richard Wordingham richard.wording...@ntlworld.com:
On Tuesday, August 23, 2011 10:29:58 PM Philippe Verdy wrote:
Even the UTC could create its own PUA registry,
It won't. The best you can hope for is a list of registries.
I did not meant as a part of the standard itself, but as a
Philippe wrote:
But my initial suggestion implied that condition 3 was not part of it.
This is not me, but sriva that has modified the problem. The problem
was changed later by adding new conditions that I have never intended.
It is clear that this condition 3 is completely unsatisfiable in all
s/one font/one code point/
--
Doug Ewell • d...@ewellic.org
Sent via BlackBerry by ATT
-Original Message-
From: Doug Ewell d...@ewellic.org
Sender: unicode-bou...@unicode.org
Date: Thu, 25 Aug 2011 01:39:24
To: verd...@wanadoo.fr
Reply-To: d...@ewellic.org
Cc: unicode@unicode.org
2011/8/24 Doug Ewell d...@ewellic.org:
As Richard said, and you probably already know, there is no chance that
UTC will ever do anything with the PUA, especially anything that gives
the appearance of endorsing its use. I'm just thankful they haven't
deprecated it.
The appearance of endorsing
so you will end up with the CSUR AND the registry Pilippe is
suggesting AND all the existing uses of PUA that will not end up in
CSUR or the other registry.
sounds like it will be a mess.
its bad enough dealing with Unicode and pseudo-Unicode in the Myanmar
script, adding PUA potentially into
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
2011/8/22 Joó Ádám a...@jooadam.hu:
Speaking of actual implementation, I’m convinced that this format
should be the same as it is for encoded characters ...
As well, the small properties files can be embedded, in a
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On Behalf
Of Philippe Verdy
Lookup tables in fonts (at least OpenType) do not work at the character
level, but at the glyph level: they substitute glyph ids by other glyph ids.
That much is true.
Sequences of glyph ids
From: ver...@gmail.com [mailto:ver...@gmail.com] On Behalf Of Philippe Verdy
2011/8/22 Peter Constable peter...@microsoft.com:
Of course _OpenType_ cannot, but any rendering engine that uses OpenType
_must_ resolve the bidi level of _all_ characters in a sequence that it is
given to
2011/8/25 Andrew Cunningham lang.supp...@gmail.com:
so you will end up with the CSUR AND the registry Philippe is
suggesting AND all the existing uses of PUA that will not end up in
CSUR or the other registry.
sounds like it will be a mess.
its bad enough dealing with Unicode and
I fully agree with Doug. Citing the CLDR project as something similar is
totally wrong. CLDR affects a very large number of users, which justifies
the investment into the project, whereas PUA is of very little general
interest.
Sincerely, Erkki
-Alkuperäinen viesti-
Lähettäjä:
30 matches
Mail list logo
