What is needed is a way to specify the properties in a
platform-independent way, where platform means not only OS but also
font technology.
The font format used by all smart font technologies (OT, AAT,
Graphite) are all based on the TrueType font file format which allows
you to add any number
2011/8/25 Peter Constable peter...@microsoft.com:
From: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
Behalf Of Philippe Verdy
But I suspect that the strong opposition given by Peter Constable...
Yet again, I think you're putting words in my mouth. The only thing I think
2011/8/25 Peter Constable peter...@microsoft.com:
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,
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
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,
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
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.
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
On 22 August 2011 22:40, John Hudson j...@tiro.ca wrote:
Glyph ID inputs for OTL processing are according to reading/resolved order.
This is typically the same as logical order, but the term logical order
really applies to character strings, not glyph strings, which are much more
On Mon, 22 Aug 2011 20:58:23 +0200
Philippe Verdy verd...@wanadoo.fr wrote:
The computing order of features should not then be:
- BiDi algorithm for reordering grapheme clusters
(I trust you mean the ordering of clusters relative to one another, not
the ordering within clusters.)
- font
2011/8/23 Richard Wordingham richard.wording...@ntlworld.com:
The BiDi algorithm absolutely does not have to be changed.
But you have to remember that preposed combining marks (and
fragments) must inherit the BiDi class of the base letter. I'm glad
you know what a circumposed Indic vowel
On Monday 22 August 2011, William_J_G Overington wjgo_10...@btinternet.com
wrote:
Would a third option work?
In the Description section of the Macintosh Roman section of a TrueType font,
include a line of text in a plain text format of which the following line of
text is an example.
William_J_G Overington wjgo underscore 10009 at btinternet dot com
wrote:
Suppose that a a special researcher's edition of a wordprocessing
application or a desktop publishing application at start up looks in a
specified directory for a file with the following file name.
pua_major.txt
Philippe Verdy verd...@wanadoo.fr wrote:
The computing order of features should not then be:
- BiDi algorithm for reordering grapheme clusters
- font search and font fallback (using cmap)
- GSUB (lookups of ligatures or discretionary glyph variants)
- GPOS
but really:
- font lookup
On 8/23/2011 7:22 AM, Doug Ewell wrote:
Of all applications, a word processor or DTP application would want to
know more about the properties of characters than just whether they are
RTL. Line breaking, word breaking, and case mapping come to mind.
I would think the format used by standard UCD
Asmus Freytag asmusf at ix dot netcom dot com wrote:
The right answer would follow the XML format of the UCD.
Question: Since the ucdxml formats became available, has any consensus
emerged as to whether the flat or grouped formats are preferred?
Obviously they both contain the same data, but
Behdad Esfahbod wrote:
I can see the advantages of such an approach -- performing GSUB prior to BiDi
would enable cross-directional contextual substitutions, which are currently
impossible -- but the existing model in which BiDi is applied to characters
*not glyphs* isn't likely to change.
John Hudson 於 2011年8月23日 下午2:33 寫道：
Behdad Esfahbod wrote:
I can see the advantages of such an approach -- performing GSUB prior to
BiDi
would enable cross-directional contextual substitutions, which are currently
impossible -- but the existing model in which BiDi is applied to
2011/8/23 John Hudson j...@tiro.ca:
Behdad Esfahbod wrote:
I can see the advantages of such an approach -- performing GSUB prior to
BiDi
would enable cross-directional contextual substitutions, which are
currently
impossible -- but the existing model in which BiDi is applied to
characters
Philippe Verdy wrote:
Rereading closely the OpenType spec...
I suggest you read also the script-specific OT layout specifications.
http://www.microsoft.com/typography/SpecificationsOverview.mspx
You'll note, for example, that the Arabic font spec doesn't even mention
BiDi, because it is
2011/8/24 John Hudson j...@tiro.ca:
Philippe Verdy wrote:
Rereading closely the OpenType spec...
I suggest you read also the script-specific OT layout specifications.
http://www.microsoft.com/typography/SpecificationsOverview.mspx
You'll note, for example, that the Arabic font spec
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 processing that arrived at those
Script (AL) character.)
A./
--
Doug Ewell • d...@ewellic.org
Sent via BlackBerry by ATT
-Original Message-
From: Richard Wordinghamrichard.wording...@ntlworld.com
Sender: unicode-bou...@unicode.org
Date: Mon, 22 Aug 2011 03:19:39
To: Unicode Mailing Listunicode@unicode.org
Subject: Re: RTL
: unicode-bou...@unicode.org [mailto:unicode-bou...@unicode.org] On
Behalf Of Shriramana Sharma
Sent: Monday, August 22, 2011 8:12 AM
To: unicode@unicode.org
Subject: Re: RTL PUA?
On 08/22/2011 08:24 AM, Peter Constable wrote:
I'm not saying that there shouldn't be_some_ software that can do
On 22 Aug 2011, at 03:57, Peter Constable wrote:
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.
Which is why that
On 22 Aug 2011, at 05:53, Shriramana Sharma wrote:
While I don't know much about RTL scripts, if the logic order is ALEF +
LAMED, but the presentation order is LAMED + ALEF *because of the RTL nature*
do you write the rule as ALEF + LAMED = ALEF_LAMED_LIGATURE or LAMED + ALEF =
On Mon, Aug 22, 2011 at 10:42:05AM +0530, Shriramana Sharma wrote:
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.
On 08/22/2011 04:34 PM, Behdad Esfahbod wrote:
On 08/22/11 06:53, Shriramana Sharma wrote:
While I don't know much about RTL scripts, if the logic order is ALEF +
LAMED,
but the presentation order is LAMED + ALEF*because of the RTL nature* do you
write the rule as ALEF + LAMED =
On 08/22/2011 05:26 PM, Behdad Esfahbod wrote:
OpenType tables contain entries in the logical order of the script in
question. Ie. Arabic tables are always RTL.
Yes I understand, but still, to clarify:
The font tables themselves contain only ASCII characters I presume. In
it do you write:
On 08/22/2011 12:21 PM, Jonathan Rosenne wrote:
I don't buy the assumption that all the world is either AAT, Graphite
or Uniscribe.
Nobody asserted that either. It is only pointed out that major
implementations are able to provide what you seek.
Anyhow, this discussion is going off topic,
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.)
Sorry, I just can’t resist pointing out that difference between
hardware and software is only the fact that the former is material,
On 08/22/2011 08:26 AM, Shriramana Sharma wrote:
On 08/22/2011 05:26 PM, Behdad Esfahbod wrote:
OpenType tables contain entries in the logical order of the script in
question. Ie. Arabic tables are always RTL.
Yes I understand, but still, to clarify:
The font tables themselves contain only
2011/8/22 Peter Constable peter...@microsoft.com:
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
2011/8/22 Peter Constable peter...@microsoft.com:
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.
I also agree with
2011/8/22 Shriramana Sharma samj...@gmail.com:
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
It's actually quite easy to convince Uniscribe to treat specific characters as
RTL, others as LTR, and, in general, with whatever classifications you desire.
Pass a preprocessed string to Uniscribe's ScriptItemize(). RichEdit has used
that approach to some degree starting with RichEdit 3.0
2011/8/22 Mark E. Shoulson m...@kli.org:
I'm not certain I understand the question, but if I have it right... The
logic order is ALEF + LAMED, and the presentation... places those in a
right-to-left sequence, shall we say (since talking about the presentation
*order* is confusing here). The
2011/8/22 Shriramana Sharma samj...@gmail.com:
Hi Behdad. I only asked whether the OT *tables* would contain the entries in
the logical order or the visual order. Clearly it would still be the visual
order (but Philippe Verdy seemed to imagine/suggest otherwise).
No ! I've not imagined that.
2011/8/22 Shriramana Sharma samj...@gmail.com:
On 08/22/2011 05:26 PM, Behdad Esfahbod wrote:
OpenType tables contain entries in the logical order of the script in
question. Ie. Arabic tables are always RTL.
Yes I understand, but still, to clarify:
The font tables themselves contain only
2011/8/22 Joó Ádám a...@jooadam.hu:
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.)
Sorry, I just can’t resist pointing out that difference between
hardware and software is only
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
As well, the small properties files can be embedded, in a very compact
form, in the PUA font.
As soon as you embed all the information in the font, you require
different solutions for systems that use different font technologies.
I was
On 08/20/2011 10:54 AM, Shriramana Sharma wrote:
On 08/19/2011 10:05 PM, Mark Davis ☕ wrote:
All of the property assignments to PUA characters (except the GC) are
purely informative.
I just now noticed that you had excepted the GC in the above. Why is
that? How are applications supposed to
On 08/22/2011 05:20 PM, Shriramana Sharma wrote:
Hi Behdad. I only asked whether the OT *tables* would contain the
entries in the logical order or the visual order. Clearly it would still
be the visual order
My mistake: I should have said *logical* order.
(but Philippe Verdy seemed to
On 08/22/2011 09:00 PM, Philippe Verdy wrote:
The font tables themselves contain only ASCII characters I presume.
No. The lookup tables contain sequences of numeric glyph ids (16 bit
integers in TrueType and OpenType). Which are also not the code point
values, and not the character names or
On 08/22/2011 09:31 PM, Doug Ewell wrote:
Philippe Verdyverdy underscore p at wanadoo dot fr wrote:
As well, the small properties files can be embedded, in a very compact
form, in the PUA font.
As soon as you embed all the information in the font, you require
different solutions for systems
Shriramana Sharma samjnaa at gmail dot com wrote:
As soon as you embed all the information in the font, you require
different solutions for systems that use different font technologies.
Why? In the end all the systems base upon the character properties
specified by the standard. For the
On Mon, Aug 22, 2011 at 07:51:22AM -0700, Doug Ewell wrote:
Some PUA properties, like glyph shapes and maybe directionality, can be
stored in a font. Others, like numeric values and casing, might not or
cannot. An interchangeable format needs to be agreed upon for the
Why not?
P.T.
--
On 08/22/2011 10:12 PM, Doug Ewell wrote:
Right, so if you embed that table in an OT font, the information is not
available to a system that uses a font technology other than OT.
I don't understand why you would say so -- assuming we are all talking
about TrueType fonts, AAT just uses some
Shriramana Sharma wrote:
The font tables themselves contain only ASCII characters I presume.
OpenType Layout tables use Glyph IDs. OTL development tools typically
use glyph names, which may be particular to the tool or the same names
used in the post or CFF tables.
OTL tables work on
Petr Tomasek tomasek at etf dot cuni dot cz wrote:
Some PUA properties, like glyph shapes and maybe directionality, can
be stored in a font. Others, like numeric values and casing, might
not or cannot. An interchangeable format needs to be agreed upon for
Why not?
Where does one store
Shriramana Sharma wrote:
I was just noting
that the glyph tables themselves don't *use* the actual codepoints of
the characters getting ligated (while they *refer* to them).
Characters are mapped to glyph IDs in the font cmap tables.
Glyph IDs are mapped to other glyph IDs (one-to-one,
On Monday 22 August 2011, Philippe Verdy verd...@wanadoo.fr wrote:
So there are only two options:
[snipped]
... : this requires an approval either by the UTC WG2 (solution 1) or by
the OpenType working group (solution 2).
Would a third option work?
In the Description section of the
Doug Ewell 於 2011年8月22日 上午10:59 寫道：
Petr Tomasek tomasek at etf dot cuni dot cz wrote:
Some PUA properties, like glyph shapes and maybe directionality, can
be stored in a font. Others, like numeric values and casing, might
not or cannot. An interchangeable format needs to be agreed upon
True -- so if someone wanted a PUA script to be handled properly in sorting
etc one would have to prepare collation tables which would obviously go
*outside* the font.
If a proper definition of an unencoded script needs additional
properties which cannot be stored in the font anyway, why would
On 08/22/2011 10:55 PM, Joó Ádám wrote:
If a proper definition of an unencoded script needs additional
properties which cannot be stored in the font anyway, why would you
want to store part of it in OT tables? It’s just not the right place.
Fonts’ sole purpose is to display already defined
William_J_G Overington 於 2011年8月22日 上午10:49 寫道：
In the Description section of the Macintosh Roman section of a TrueType font,
include a line of text in a plain text format of which the following line of
text is an example.
On Monday 22 August 2011, John H. Jenkins jenk...@apple.com wrote:
Forgive my asking, but this reference to the description section of the
Macintosh Roman section of a TrueType font has me puzzled, because I don't
know what you're talking about. What table contains this string?
When I
2011/8/22 Doug Ewell d...@ewellic.org:
Depending on how you count, there are already two to four fonts that
support Ewellic in the PUA. There are probably many more that support
Tengwar or Cirth or Klingon.
First, these fonts can work fine with the default LTR directionality.
So there's no
2011/8/22 Shriramana Sharma samj...@gmail.com:
On 08/22/2011 09:00 PM, Philippe Verdy wrote:
The font tables themselves contain only ASCII characters I presume.
No. The lookup tables contain sequences of numeric glyph ids (16 bit
integers in TrueType and OpenType). Which are also not the
2011/8/22 Shriramana Sharma samj...@gmail.com:
True -- so if someone wanted a PUA script to be handled properly in sorting
etc one would have to prepare collation tables which would obviously go
*outside* the font.
Collation tables can aleady be tailored very easily with existing
technologies.
William_J_G Overington 於 2011年8月22日 下午12:36 寫道：
On Monday 22 August 2011, John H. Jenkins jenk...@apple.com wrote:
Forgive my asking, but this reference to the description section of the
Macintosh Roman section of a TrueType font has me puzzled, because I don't
know what you're talking
There is more to displaying characters than LTR versus RTL, and there is
more to handling characters than just displaying them. This point
continues to be lost on several people responding to this thread.
--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org |
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
Depending on how you count, there are already two to four fonts that
support Ewellic in the PUA. There are probably many more that
support Tengwar or Cirth or Klingon.
First, these fonts can work fine with the default LTR
Shriramana Sharma samjnaa at gmail dot com wrote:
Right, so if you embed that table in an OT font, the information is not
available to a system that uses a font technology other than OT.
I don't understand why you would say so -- assuming we are all talking
about TrueType fonts, AAT just
2011/8/22 William_J_G Overington wjgo_10...@btinternet.com:
Having selected a platform, one may view the text content of various fields
for that platform, such as font family name and copyright notice, version
string and postscript name. There is then a button that is labelled
Advanced...
On 8/21/2011 3:31 PM, Richard Wordingham wrote:
I expect ARABIC LANGUAGE MARK would not go down well
- has it already been proposed and rejected?.
ARABIC *LETTER* MARK, not *LANGUAGE* mark. (And suggested
to just be renamed to AL MARK.)
Proposed? Yes.
Discussed? Yes.
Rejected? No.
The last
On Mon, 22 Aug 2011 07:51:22 -0700
Doug Ewell d...@ewellic.org wrote:
Some PUA properties, like glyph shapes and maybe directionality, can
be stored in a font. Others, like numeric values and casing, might
not or cannot. An interchangeable format needs to be agreed upon for
the properties
Richard Wordingham richard dot wordingham at ntlworld dot com wrote:
One reason for associating properties with a font is that text that is
to be displayed is at that point tentatively associated with a font.
I thought John said fonts dealt with glyph IDs, not characters per se.
Another is
On Sat, Aug 20, 2011 at 7:08 AM, Shriramana Sharma samj...@gmail.com
wrote:
On 08/20/2011 01:57 PM, Martin Hosken wrote:
D49 states that all properties of PUA characters are overridable by a
higher protocol. But in 'normal' implementations, there are no higher
level protocols to override the
On 08/23/2011 03:29 AM, N. Ganesan wrote:
Hope a new proposal or a UTN from UC will make things clear, and RTL
community benefits.
Dear Ganesan,
I wonder if you have actually understood all the issues here. As usual
you have done your copy-paste from somebody else's post. Please say
2011/8/19 Michael Everson ever...@evertype.com:
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
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.
P.
2011/8/20 Ken Whistler k...@sybase.com:
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
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
Discussion List
Subject: Re: RTL PUA?
2011/8/19 Michael Everson ever...@evertype.com:
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
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 using
On Sun, 21 Aug 2011 01:44:02 +
Doug Ewell d...@ewellic.org 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
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 that
Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell
-Original Message-
From: Richard Wordingham
Sent: Sunday, August 21, 2011 9:48
To: unicode@unicode.org
Subject: Re: RTL PUA?
On Sun, 21 Aug 2011 01:44:02 +
Doug
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
2011/8/21 Peter Constable peter...@microsoft.com:
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
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
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 has
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.
JH
Not
2011/8/21 Peter Constable peter...@microsoft.com:
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
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
2011/8/21 Peter Constable peter...@microsoft.com:
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
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 BiDi
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 to
2011/8/21 Peter Constable peter...@microsoft.com:
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
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
On Sun, 21 Aug 2011 11:00:26 -0600
Doug Ewell d...@ewellic.org 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
2011/8/21 Doug Ewell d...@ewellic.org:
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
On 8/21/2011 3:31 PM, Richard Wordingham wrote:
On Sun, 21 Aug 2011 11:00:26 -0600
Doug Ewelld...@ewellic.org 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,
@unicode.org
Subject: Re: RTL PUA?
On Sun, 21 Aug 2011 11:00:26 -0600
Doug Ewell d...@ewellic.org 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
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
On Sun, 21 Aug 2011 23:55:46 +
Doug Ewell d...@ewellic.org 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
On Sun, 21 Aug 2011 16:37:34 -0700
Asmus Freytag asm...@ix.netcom.com 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
1 - 100 of 159 matches
Mail list logo
