On August 11, I replied to Robert Wheelock:
>> I remember that a website that has tables for certain PUA precomposed
>> accented characters that aren’t yet in Unicode (thing like:
>> Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital H-
>> underbar, acute
On 8/14/2019 7:49 PM, James Kass via
Unicode wrote:
On 2019-08-15 12:25 AM, Asmus Freytag via Unicode wrote:
Empirically, it has been observed that
some distinctions that are claimed by
users, standards developers or impl
On Wed, 14 Aug 2019 23:32:37 +
James Kass via Unicode wrote:
> U+0149 has a compatibility decomposition. It has been deprecated and
> is not rendered identically on my system.
> 'n ʼn
> ( ’n )
Compatibility decompositions are quite a mix, but are generally
expected to render differently. If
On 2019-08-15 12:25 AM, Asmus Freytag via Unicode wrote:
Empirically, it has been observed that some distinctions that are claimed by
users, standards developers or implementers were de-facto not honored by type
developers (and users selecting fonts) as long as the native text doesn't
contain m
On 8/14/2019 2:05 AM, James Kass via
Unicode wrote:
This
presumes that the premise of user communities feeling strongly
about the unacceptable aspect of the variants is valid. Since it
has been reported and nothing seems to be happening, perhaps the
On 8/14/2019 4:32 PM, James Kass via Unicode wrote:
If a character gets deprecated, can its decomposition type be changed
from canonical to compatibility?
Simple answer: No.
--Ken
On 2019-08-14 7:50 PM, Richard Wordingham via Unicode wrote:
I think you'd also have to change the reference glyph of LATIN LOWER
CASE I WITH HEART to show a heart. That's valid because the UCD trumps
the code charts, and and no Unicode-compliant process may deliberately
render differently f
On Wed, 14 Aug 2019 09:05:02 +
James Kass via Unicode wrote:
> The solution is to deprecate "LATIN LOWER CASE I WITH HEART". It's
> only in there because of legacy. It's presence guarantees
> round-tripping with legacy data but it isn't needed for modern data
> or display. Urge Groups One
On 2019-08-12 8:30 AM, Andrew West wrote:
This issue was discussed at WG2 in 2013
(https://www.unicode.org/L2/L2013/13128-latvian-marshal-adhoc.pdf),
when there was a recommendation to encode precomposed letters L and N
with cedilla*with no decomposition*, but that solution does not seem
to hav
On Mon, 12 Aug 2019 at 02:27, James Kass via Unicode
wrote:
>
> On 2019-08-11 5:26 PM, [ Doug Ewell ] via Unicode wrote:
> > If you are thinking of these as potential future additions to the standard,
> > keep in mind that accented letters that can already be represented by a
> > combination of
On Mon, 12 Aug 2019 01:21:42 +
James Kass via Unicode wrote:
> There was a time when populating the PUA with precomposed glyphs was
> necessary for printing or display, but that time has passed.
There is still the issue that in pure X one can't put sequences of
characters on a
-standing principles Unicode has.
Good point.
There was a time when populating the PUA with precomposed glyphs was
necessary for printing or display, but that time has passed. Hopefully
anyone seeking charts is transcoding older data into proper Unicode.
This can be illustrated with the
Robert Wheelock wrote:
> I remember that a website that has tables for certain PUA precomposed
> accented characters that aren’t yet in Unicode (thing like:
> Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital H-
> underbar, acute accented Cyrillic vowels, Cyrillic
On 2019-08-11 4:07 AM, Robert Wheelock via Unicode wrote:
Hello!
I remember that a website that has tables for certain PUA precomposed
accented characters that aren’t yet in Unicode (thing like: Marshallese
M/m-cedilla, H/h-acute, capital T-dieresis, capital H-underbar, acute
accented
On Sun, 11 Aug 2019 00:07:05 -0400
Robert Wheelock via Unicode wrote:
> I remember that a website that has tables for certain PUA precomposed
> accented characters that aren’t yet in Unicode (thing like:
> Marshallese M/m-cedilla, H/h-acute, capital T-dieresis, capital
> H-und
Hello!
I remember that a website that has tables for certain PUA precomposed
accented characters that aren’t yet in Unicode (thing like: Marshallese
M/m-cedilla, H/h-acute, capital T-dieresis, capital H-underbar, acute
accented Cyrillic vowels, Cyrillic ER/er-caron, ...). Where was it at?! I
TrueType font file format which allows
you to add any number of custom tables. If the people responsible for
the OT, AAT & Graphite specs agreed on it amongst themselves, it might
be possible to specify an embedded table of properties for PUA
characters that all the different rendering e
Co}". This
would match ranges \uE000-\uF8FF only ― not all PUA characters there
are. However, it might be adequate for your job.
Regards,
Robert
On Thu, Aug 25, 2011 at 1:17 PM, Lorna Priest wrote:
> The recent discussion on PUA characters reminded me of a question I've had.
> I am wondering if anyone has a tool whereby we could search for all
> documents on a local computer (or server) that use PUA codepoints. I suppose
&
The recent discussion on PUA characters reminded me of a question I've
had. I am wondering if anyone has a tool whereby we could search for all
documents on a local computer (or server) that use PUA codepoints. I
suppose what I'd like is to be able to identify beginning and ending
>> As well, the small properties files can be embedded, in a very compact
>> form, in the PUA font.
>
> In one sense having data regarding PUA character properties embedded within a
> font could make sense since the interpretation of instances of those PUA
> characters will b
only thing I think
> I've explicitly spoken against in this thread is changing the default bidi
> category of PUA characters to ON.
Something that will break all existing implementations, but will not
solve the problem, it will just reduce the number of Bidi controls
needed in texts: BC=
to
>> render. Given our current situation, a default rendering implementation
>> would
>> resolve PUA characters to an even (LTR) level unless, of course, bidi
>> control
>> characters -- particularly RLO -- are used to override the directionality of
>> the
&
his thread is changing the default bidi
category of PUA characters to ON.
> In fact when Peter says that the Bidi processing and the OpenType layout
> engine are in separate layers (so that the OpenType layout works in a lower
> layer and all BiDi processing is done before any font
as a "lookup" table since
there is a distinct set of data structures in OpenType that are formally called
"Lookup" tables.
> Not all fonts need a "cmap"; for some of them, a default cmap may be implied
> or automatically constructed -- for example Symbo
mbedded, in a very compact
> form, in the PUA font.
In one sense having data regarding PUA character properties embedded within a
font could make sense since the interpretation of instances of those PUA
characters will be tied to particular fonts.
However, I don't see this as really
2011/8/24 John H. Jenkins :
>
> 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
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
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
le GSUB's only if they occur on the same font as the font
associated with the previous character. You can also easily select the
typographic variants of that font, for a single glyph.
- you can update the current Bidi level of the character, using the BC
property value overrides specified in th
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
shape
2011/8/24 John Hudson :
> 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 e
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 ass
2011/8/23 John Hudson :
> 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
>>> char
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
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. Switc
Asmus Freytag 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 one is much smaller and
the
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
Philippe Verdy 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 and font fallback (u
William_J_G Overington
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
>
> If pua_major.txt exists, then it is
On Monday 22 August 2011, William_J_G Overington
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.
>
> PUA.RTL="$E000-$E
like when subject to a
> right-to-left override.
Yes I know the case of preposed Indic vowels, e.g. vowel I in
Devanagari, as well of vowels that are splitted in two parts (one
before the consonnant cluster and one after it). However, this applies
here to an LTR script, for which we don
On Mon, 22 Aug 2011 20:58:23 +0200
Philippe Verdy 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 search and font fall
On 22 August 2011 22:40, John Hudson 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
> maleable. Th
e say
something if you have something to actually contribute instead of just
saying "I support Oriya OM" "I support PUA RTL" or such.
If you support PUA RTL, and since you are so interested in Grantha, you
should do a proposal for regions in the PUA to be allocated proper
IndicMa
On Sat, Aug 20, 2011 at 7:08 AM, Shriramana Sharma
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
>
Richard Wordingham 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 that in a multi-font docume
On Mon, 22 Aug 2011 07:51:22 -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
>
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 las
On Mon, 22 Aug 2011 23:00:49 +0530
Shriramana Sharma wrote:
> Since collation never
> cares about whether the script is LTR or RTL or Indic (with the
> except of Thai etc where the encoding is as per visual order and not
> logical order)
The latest collation standards handle Thai by treating th
2011/8/22 William_J_G Overington :
> 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... that, if clicked, opens
But I still maintain that there's more to proper handling of Unicode
characters, PUA or otherwise, than whether their directionality is LTR
or Arabic-RTL or non-Arabic-RTL or what have you. That's why all those
other properties exist. And I maintain that PUA users need a place to
store
Philippe Verdy 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 directionali
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 | www.face
William_J_G Overington 於 2011年8月22日 下午12:36 寫道：
> On Monday 22 August 2011, John H. Jenkins 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. W
2011/8/22 Shriramana Sharma :
> 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. A
hm is definitely not the first step needed before performing
glyph substitutions.
However the Bidi algorithm really needs to reorder the glyphs at least
relatively, for correct application of GPOS (glyph positionining). As
a consequence, the font to use will be completely known (all
"cmap'
2011/8/22 Doug Ewell :
> 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'
On Monday 22 August 2011, John H. Jenkins 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 use FontCreator
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.
>
> PUA.RTL="$E000-$E1FF,$E440-$E447,$E541,$E549,$E57C,$EA00-$EA0
characters, not to
define them. Tails shouldn’t be made wagging dogs.
True, but we are only trying to help those who find themselves unable to
even *display* PUA characters as RTL (or as Indic with reordering, which
can be handled by IndicMatraCategory). Since collation never cares about
whether the
> 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 an
Doug Ewell 於 2011年8月22日 上午10:59 寫道：
> Petr Tomasek 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
On Monday 22 August 2011, Philippe Verdy 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 Macintosh Roman
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, one-t
Petr Tomasek 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:
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 glyph
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 tab
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
Shriramana Sharma 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
On 08/22/2011 09:31 PM, Doug Ewell wrote:
Philippe Verdy 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
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 g
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 imagin
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
Philippe Verdy 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 thinking of somethin
overriding private use (or
> even standard if one is so inclined) characters’ properties.
> Introduction of unencoded scripts would therefore become a matter of
> distributing a small properties file and the corresponding fonts.
As well, the small properties files can be embedded, in a very
2011/8/22 Shriramana Sharma :
> 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 c
2011/8/22 Shriramana Sharma :
> 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. You incorrectl
orting that encoding).
Not all fonts need a "cmap"; for some of them, a default cmap may be
implied or automatically constructed -- for example Symbol fonts in
Windows, that are implicitly mapped in a PUA range; another example is
Type1 or CFF fonts that have a default "standardE
delimiters such as the dots in the domain name accordingly. Some of my blog
posts on http://blogs.msdn.com/b/murrays/ discuss this in greater detail.
So there's no need to change the properties of the PUA to establish PUA RTL
conventions. They won't be generally interchangeable, but th
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 in the latter category.
--
Doug Ewell | Thornton, Colorado, USA | RFC 5645
s permitted by Unicode and what is
available in major implementations is not always being observed in this
thread.
> The request being made to allocate BC=R areas in the PUA is sure to
> generate an impression that conformant implementations should consider
> such a property norm
On 08/22/2011 10:42 AM, Shriramana Sharma wrote:
The suggestion has been made that fonts should be able to carry some
additional custom tables specifying custom properties for PUA
characters, which seems reasonable.
Something like web-fonts which IIUC have some additional metadata or
such
at "some".
>
> Peter, given that both AAT and Graphite have provisions for assigning custom
> properties including BC to PUA characters, it seems Uniscribe is the only
> one missing out. Those advocating RTL PUA areas seem to reject AAT and
> Graphite as "hacks" or
2011/8/22 Shriramana Sharma :
> 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
2011/8/22 Peter Constable :
> 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
ring engine that uses OpenType
> _must_ resolve the bidi level of _all_ characters in a sequence that it is
> given to render. Given our current situation, a default rendering
> implementation would resolve PUA characters to an even (LTR) level unless, of
> course, bidi control char
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 A
> 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,
topic, the issue is should
Unicode specify an RTL PUA area, not whether some products, however
respectable, provide a bypass.
I don't see why you call it a *bypass*. Only if the road in front of you
presents obstacles and does not allow you to proceed further, you need
to take a bypass.
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 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 = A
ught to be included within that "some".
>
> Peter, given that both AAT and Graphite have provisions for assigning
> custom properties including BC to PUA characters, it seems Uniscribe is
> the only one missing out. Those advocating RTL PUA areas seem to reject
> AAT an
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 =
> ALEF_LAM
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 fr
I don't buy the assumption that all the world is either AAT, Graphite or
Uniscribe.
Anyhow, this discussion is going off topic, the issue is should Unicode specify
an RTL PUA area, not whether some products, however respectable, provide a
bypass.
Jony
> -Original Message
he same bidi context
as the presence of an Arabic Script (AL) character.)
A./
--
Doug Ewell • d...@ewellic.org
Sent via BlackBerry by AT&T
-Original Message-
From: Richard Wordingham
Sender: unicode-bou...@unicode.org
Date: Mon, 22 Aug 2011 03:19:39
To: Unicode Mailing List
Sub
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
have provisions for assigning
custom properties including BC to PUA characters, it seems Uniscribe is
the only one missing out. Those advocating RTL PUA areas seem to reject
AAT and Graphite as "hacks" or "wow *one* application" [*].
[* = LibreOffice is the *only* multipurpose appl
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
1 - 100 of 295 matches
Mail list logo
