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
On Tue, 23 Aug 2011 10:02:05 +0800
li bo libo@gmail.com wrote:
...But I don't know why user must take
a paragraph as a unit to determine the embedding levels. Why can't i
shape the text first and then wrapping the line, and determining the
embedding levels for characters within a line.
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
On Mon, 22 Aug 2011 16:18:56 -0700
Ken Whistler k...@sybase.com wrote:
How about Clause 12.5 of ISO/IEC 10646:
001B, 0025, 0040
You escape out of UTF-16 to ISO 2022, and then you can do whatever
the heck you want, including exchange and processing of complete
4-byte forms, with all the
On 8/23/2011 12:00 PM, Richard Wordingham wrote:
On Mon, 22 Aug 2011 16:18:56 -0700
Ken Whistlerk...@sybase.com wrote:
How about Clause 12.5 of ISO/IEC 10646:
001B, 0025, 0040
You escape out of UTF-16 to ISO 2022, and then you can do whatever
the heck you want, including exchange and
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.
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
--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell
srivas sinnathurai sisrivas at blueyonder dot co dot uk wrote:
If same codes within PUA becomes standard for different purposes,
They aren't standard. Two different private agreements could assign
different characters to the same PUA code points.
how to get both working using same font?
You
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
2011/8/23 Doug Ewell d...@ewellic.org:
srivas sinnathurai sisrivas at blueyonder dot co dot uk wrote:
If same codes within PUA becomes standard for different purposes,
They aren't standard. Two different private agreements could assign
different characters to the same PUA code points.
how
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
There's no standard way to specify even one font or private agreement in
plain text, let alone how to switch between them within the same
document. This is not an intended use of the PUA.
There exists such standard in the context
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
2011/8/24 Doug Ewell d...@ewellic.org:
Coordinating private agreements so they don't conflict is clearly the
ideal situation. But many different people and organizations have
already claimed the same chunk of PUA space, as Richard exemplified
yesterday with his Taiwan/Hong Kong example.
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
On Tuesday, August 23, 2011 10:29:58 PM Philippe Verdy wrote:
2011/8/24 Doug Ewell d...@ewellic.org:
(3) which contains the same PUA code point with two meanings
The only numbered item to sacifice is number (3) here. that's the case
where separate PUA agreements are still coordinated so that
2011/8/24 Luke-Jr l...@dashjr.org:
On Tuesday, August 23, 2011 10:29:58 PM Philippe Verdy wrote:
2011/8/24 Doug Ewell d...@ewellic.org:
(3) which contains the same PUA code point with two meanings
The only numbered item to sacifice is number (3) here. that's the case
where separate PUA
24 matches
Mail list logo
