Re: emojis for mouse buttons?

. -- John W. Kennedy "Compact is becoming contract, Man only earns and pays." -- Charles Williams. "Bors to Elayne: On the King's Coins" > On Jan 1, 2020, at 6:43 AM, Marius Spix via Unicode > wrote: > > Cecause the middle button of many mice is a scroll

Re: emojis for mouse buttons?

Operationally, one does not program for “left” or “right” buttons, because left-handed users are encouraged to set a switch that logically turns the mouse around, with “Button 1” being the button worked by the index finger, no matter what side of the mouse it’s on. -- John W. Kennedy "Co

Re: Memoji

Memoji are not merely animated emoji; they are personalized avatars. As for animated emoji, I expect that the UTC would consider them out-of-scope for plain text. Note that web pages can already contain animated or moving elements which cannot be represented in plain text. > On Jul 9, 2018,

Re: Unicode 11.0 and 12.0 Cover Design Art

Maybe we should just throw in the towel and put "DON'T PANIC" on the cover in big, friendly letters. 

Re: Support for Extension F

t year in Unicode 10. I have come across a number > of people saying they are having problems with Ext F. I was wondering what > the current support is for Ext F at OS level and in terms of fonts. > > Regards > John Knightley

Re: 0027, 02BC, 2019, or a new character?

In cold-metal days, many were driven to resort to “M‘Donald” for lack of a superscript “c”. > On Jan 26, 2018, at 11:47 AM, Richard Wordingham via Unicode > wrote: > > On Fri, 26 Jan 2018 09:08:51 + > Andre Schappo via Unicode wrote: > >> Ah!

Re: Emoji for major planets at least?

Well, you can go with Venus = white planet, Mercury = grey planet, Uranus = greenish planet, Neptune = bluish planet, Jupiter = striped planet. As you say, though, without a context, none of them convey much and Venus, at least, would just be a circle. Plus there's the question of the context

Re: Plane-2-only string

Ʃ ̥ ́ Ӽ Մ ݭ ݹ ந ன ோ ௦ ௽ ఋ ల ు ూ ృ ౓ ౘ ౥ ౷ ౸ ಜ ೏ ೕ ೖ ക ര േ ൈ ൉ ൩ ൯ ർ ൾ ൿ ග ට ඲ ฉ That is an example of forty Cantonese-specific characters which are not obscene (that I'm aware of) from Extension B. For the curious, I've appended at the bottom the full list of 280 for all of Plane 2 which I was

Re: IBM 1620 invalid character symbol

; > That technology was then only two years in the future. > > Other typewriters used interchangeable type wheels for the same purpose, but > I believe that generally came later. > > A./ -- John W Kennedy "Harriet thanked Heaven, with grim amusement, for the scholar

Re: IBM 1620 invalid character symbol

The 56th page in the PDF, numbered 52. -- SKen Software, LLC Coming soon to an iPhone near you > On Sep 26, 2017, at 9:20 AM, Martin J. Dürst <due...@it.aoyama.ac.jp> wrote: > >> On 2017/09/26 22:03, John W Kennedy via Unicode wrote: >> I don’t know what your snippet i

Re: IBM 1620 invalid character symbol

I don’t know what your snippet is from, but the normally authoritative IBM manual, A26-5706-3, IBM 1620 CPU Model 1 (July, 1965) displays what is clearly the Cyrillic letter. Whether it should be regarded as that, or as a distinct character, is another question. See

Re: How to Add Beams to Notes

> On May 1, 2017, at 3:12 PM, Michael Bear via Unicode > wrote: > > I am trying to make a music notation font. It will use the Musical Symbols > block in Unicode (1D100-1D1FF), but, since that block has a bad rep for not > being very complete, I added some extra

Re: Standaridized variation sequences for the Desert alphabet?

> On Mar 29, 2017, at 4:12 AM, Martin J. Dürst wrote: > > Let me start with a short summary of where I think we are at, and how we got > there. > > - The discussion started out with two letters, > with two letter forms each. There is explicit talk of the > 40-letter

Re: Standaridized variation sequences for the Desert alphabet?

> On Mar 27, 2017, at 9:56 AM, John H. Jenkins <jenk...@apple.com> wrote: > > >> On Mar 27, 2017, at 2:04 AM, James Kass <jameskass...@gmail.com >> <mailto:jameskass...@gmail.com>> wrote: >> >>> >>> If we have any historic

Re: Standaridized variation sequences for the Desert alphabet?

> On Mar 27, 2017, at 2:04 AM, James Kass <jameskass...@gmail.com> wrote: > >> >> If we have any historic metal types, are there >> examples where a font contains both ligature >> variants? > > Apparently not. > > John H. Jenkins mentioned ear

Re: Standaridized variation sequences for the Desert alphabet?

My own take on this is "absolutely not." This is a font issue, pure and simple. There is no dispute as to the identity of the characters in question, just their appearance. In any event, these two letters were never part of the "standard" Deseret Alphabet used in printed materials. To the

Re: Superscript and Subscript Characters in General Use

:12 AM, Philippe Verdy <verd...@wanadoo.fr> wrote: > > This is the traditional use of the apostrophe to be used to marc an elision > at end of words. Nothing new. > > 2017-01-04 6:36 GMT+01:00 John W Kennedy <john.w.kenn...@gmail.com>: >> >> > On

Re: about China Font Bank

Language Log has a good article on this, including reactions from several sinographers: http://languagelog.ldc.upenn.edu/nll/?p=29034 - JB > On Oct 27, 2016, at 07:48, shi zhao wrote: > > from >

Re: Default character encoding for each operating system?

macOS, and its offspring, iOS, watchOS, and tvOS, use UTF-16LE for all internals, but readily import and export all versions of Unicode and a good many historic 8-bit and mixed-length codings. In the new Swift programming language, which is white-hot in the Apple community, Apple is moving

Re: Comment in a leading German newspaper regarding the way UTC and Apple handle Emoji as an attack on Free Speech

, John On Fri, Aug 26, 2016 at 5:26 AM Helena S Chapman <hchap...@us.ibm.com> wrote: > This is an interesting way of interpreting "speech". To understand that, > we need to look at what an emoji is: "A small digital image or icon used to > express an idea, emotion, etc

Re: Unicode Digest, Vol 22, Issue 9

As a response to all the issues I've learned from everyone, my immediate recommendation for my company's current policy is to constrain our passwords to printable ASCII now in order to buy time to learn more about all the issues that you and others have mentioned. I appreciate all the feedback on

Re: Accessing the WG2 document register

implementing Unicode. My recommendation is simply to ignore WG2 and act as if it doesn't exist. It already might as well not, and with its policies is only likely to become more and more irrelevant. JH -- John Hudson Tiro Typeworks Ltdwww.tiro.com Salish Sea, BCt...@tiro.com

Re: Another take on the English apostrophe in Unicode

of them is will.) Linguistically, don't and friends pass all the diagnostics that indicate they're single words. - John Burger English is taught as that squiggle being punctuation, not a letter. (Unlike, say, the Hawaiʻian ʻOkina.) You can't use simple regular expressions to find word

Re: Custom characters (was: Re: Private Use Area in Use)

It occurs to me that the existing DNS system was designed to map 32bit numbers to domain names. So a hypothetical UTF64 format, with 32 bits of provider ID could be co-opted into the DNS system under a different record domain (Similar to how there is A records, and MX records, there could be

Re: Private Use Area in Use (from Tag characters and in-line graphics (from Tag characters))

such embedding). Another reason may be that the font is marked as not embeddable within its exposed properties. Another reason may be that John tries to open the document with a software that does not handle embedded fonts, or that ignores it to use only the fonts preinstalled by John in his preferences

Re: Tag characters and in-line graphics (from Tag characters)

So what you’re saying is that the current situation where you see an empty square □ for unknown characters is better than seeing something useful? — Chris On Thu, Jun 4, 2015 at 12:59 AM, Doug Ewell d...@ewellic.org wrote: Chris idou747 at gmail dot com wrote: Right now, what happens if you

Re: Private Use Area in Use (from Tag characters and in-line graphics (from Tag characters))

Yep, I clicked on your document and saw an empty square where your character should be. F = FAIL. — Chris On Wed, Jun 3, 2015 at 6:30 PM, William_J_G Overington wjgo_10...@btinternet.com wrote: Private Use Area in Use (from Tag characters and in-line graphics (from Tag characters))

Re: Tag characters and in-line graphics (from Tag characters)

:06 PM, Asmus Freytag (t) asmus-...@ix.netcom.com wrote: John, reading this discussion, I agree with your reaductio ad absurdum of infinitely nested HTML. But I think you are onto something with your hypothetical example of the subset that works in ALL textual situations. There's clearly

Re: Tag characters and in-line graphics (from Tag characters)

the computing universe to actually exchange custom characters as if they were just any other text. Someone would actually have to  work on a standard to do that, not just point to html5. On Saturday, 30 May 2015 at 5:08 am, Philippe Verdy verd...@wanadoo.fr, wrote: 2015-05-29 4:37 GMT+02:00 John

Re: Tag characters and in-line graphics (from Tag characters)

Today the world goes very well with HTML(5) which is now the bext markup language for document (including for inserting embedded images that don’t require any external request” If I had a large document that reused a particular character thousands of times, would this HTML markup require

Re: Usage stats?

crawler. And it wouldn't include all the printed material that isn't on the web. Turning your question around, why would Unicode have this information? What would be the value, and how would it be worth the (considerable) effort required? - John Burger MITRE On Fri, Mar 27, 2015 at 1:07 PM

Re: Unicode block for programming related symbols and codepoints?

(for example as arrows, lines etc., using another color): Can’t good editors display tabs in a different color when required ? Lots of them already do, e.g. Emacs in various modes. - John Burger MITRE --- browsers could let the web page creator let decide the visual representation

Discrepancies between kTotalStrokes and kRSUnicode in the Unihan database - repost all ascii

will be glad to share the results of my heuristic test and the program (python) I used to produce them. John Armstrong Cambridge MA ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode

Re: Discrepancies between kTotalStrokes and kRSUnicode in the Unihan database

get tripped up in this way shows how fragile unification can be. -- John ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode

Re: Discrepancies between kTotalStrokes and kRSUnicode in the Unihan database - repost all ascii

. What do you think? Feel free to respond off-list if you prefer. -- John ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode

Draft of LDML Specification for CLDR release 24

in the text. A summary of the changes to specification can be found at: http://unicode.org/repos/cldr/trunk/specs/ldml/tr35.html#Modifications Regards, John C. Emmons Globalization Architect Unicode CLDR TC Chairman IBM Software Group Internet: e...@us.ibm.com

Common and Inheritied Unicode scripts

COMMON/INHERITED code points to a set of scripts? Any help is appreciated, -- John John Colosi Senior Manager of Product Development jcol...@verisign.com m: 703-967-4062 t: 703-948-3211 12061 Bluemont Way, Reston VA 20190 VerisignInc.comhttp://www.verisigninc.com/ [Description: Verisign

Re: Hanzi trad-simp folding and z-variants

). Not standardize does not mean totally beyond analysis or processing, or even necessarily that confusing to a native speaker, they are not random, though admittedly more complex than a standardized locale. Yes. And we both agree that standardization is desirable. Yes. John Stephan

Re: Hanzi trad-simp folding and z-variants

to be just BMP. Regards John Stephan

Re: Hanzi trad-simp folding and z-variants

be in widely known. With Zhuang Sawndip I have examining texts from different locations and eras, that there exists both evidence of transmission from generation to generation, of progression and also of unstability. Regards John Nonetheless, both type and token frequency of such syllable

Re: Hanzi trad-simp folding and z-variants

in Unicode. John Stephan

Re: Hanzi trad-simp folding and z-variants

basis. Regards John Knightley Stephan

Re: Hanzi trad-simp folding and z-variants

On Sat, Jun 8, 2013 at 4:02 PM, Stephan Stiller stephan.stil...@gmail.comwrote: http://www.unicode.org/**reports/tr38/http://www.unicode.org/reports/tr38/does a good summary of the possibilities. Which and where? Section 3.7.1 Simplified and Traditional Chinese Variants talks about

Re: Hanzi trad-simp folding and z-variants

in such things in recent years. One persons 'hand-tuned' of today can become the basis of a standard of tomorrow. John Stephan

Re: Hanzi trad-simp folding and z-variants

(!) to represent modern SHnese. Not standardize does not mean totally beyond analysis or processing, or even necessarily that confusing to a native speaker, they are not random, though admittedly more complex than a standardized locale. John Stephan

Re: Hanzi trad-simp folding and z-variants

Resending email: Originally sent by mistake just to sender and not to list. Dear John, Without looking at your texts it I can not say for certain, however it should be noted that simplified, perhaps better thought of as abbreviated, is a relative term, therefore a fully simplified passage

Hanzi trad-simp folding and z-variants

the mapping is unambiguous), but I'd be interested in opinions about this. Second, I just noticed the kZVariant field in the Unihan.zip file. It seems to me that it makes sense to fold these together as well, correct? Thanks for any information you care to provide. - John Burger MITRE

Re: Encoding localizable sentences (was: RE: UTC Document Register Now Public)

On 2013年4月19日, at 下午1:52, Stephan Stiller stephan.stil...@gmail.com wrote: But I'd argue that the distance of the information content of such low-quality translations to the information content conveyed by correct and polished language is often tolerable. Grammar isn't that important for

Re: In 2013, there are still programs with huge Unicode bugs :-(

But is how do we know whether the bug is there all the time! On Fri, Mar 22, 2013 at 4:45 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: This one is incredible: https://bugzilla.redhat.com/show_bug.cgi?id=922433

Re: pIqaD in actual use

On Sun, Mar 3, 2013 at 6:18 PM, Michael Everson ever...@evertype.com wrote: On 2 Mar 2013, at 23:24, Peter Constable peter...@microsoft.com wrote: Well, I suppose it's long enough since Klingon was invented that it's conceivable there are people that grew up as in homes with dedicated Klingon

Re: pIqaD in actual use

On Sun, Mar 3, 2013 at 8:12 PM, Michael Everson ever...@evertype.com wrote: On 3 Mar 2013, at 12:06, john knightley john.knight...@gmail.com wrote: When translating from one language to another there are always some words and expressions for which there exists no exact equivalents. Yes

Re: Text in composed normalized form is king, right? Does anyone generate text in decomposed normalized form?

On 2013年2月1日, at 上午6:07, Costello, Roger L. coste...@mitre.org wrote: So why would one ever generate text in decomposed form (NFD)? The Unihan database is stored in NFD because it makes the regular expressions used to qualify its contents much, *much* simpler. I imagine that things like

Re: Public Review Issue 232 Proposed Update UAX #9, Unicode Bidirectional Algorithm (Copy of email sent to the list; also posted by me to unicode feedback/public review issue-- but this has not yet po

in this and related issues. http://books.google.com/books/about/The_Linguistics_of_Punctuation.html?id=Sh-sruuKjJwC - John Burger MITRE

Re: Ideograms (was: Spiral symbol)

On 2013年1月30日, at 上午4:50, Andreas Stötzner a...@signographie.de wrote: Most ideographs in use are pictographs, for obvious reasons. But it would be nice indeed to have ideograms for “thanks”, 謝 “please”, 請 “yes”, 對 “no”, 不 “perhaps” 許 – all those common notions which cannot be

Re: Ideograms

://www.pinyin.info/readings/texts/ideographic_myth.html . Charlie * Tim Greenwood timo...@greenwood.name [2013-01-30 20:17]: A very accessible book on all this is The Chinese Language: Fact and Fantasy by John De Francis, published in 1984 by University of Hawaii Press. There is a brief synopsis

Re: I missed my self-imposed deadline for the Mayan numeral proposal

http://xkcd.com/998/ On 2012年12月21日, at 下午4:22, Doug Ewell d...@ewellic.org wrote: And as you've no doubt heard to death by now, real Maya don't believe in that apocalyptic mumbo-jumbo anyway. Today was a celebration. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org |

Re: ‮LTR

I double-checked *very* carefully, and I did't see anything wrong at all. :-) You got sharp eyes there, Doug. On 2012年11月28日, at 下午10:58, Doug Ewell d...@ewellic.org wrote: John H. Jenkins wrote: Or, if one prefers: http://www.井作恆.net/XKCD/1137.html In all the ensuing discussion

Re: First known use of the word, email (1978)

What has this to do with Unicode??? - John Burger MITRE On Nov 27, 2012, at 05:14 , N. Ganesan wrote: There are interviews in Tamil and English language media about V. A. Shiva Ayyadurai and his work in high school and later with respect to electronic mail. A statement issued by MIT

Re: xkcd: ‮LTR

Or, if one prefers: http://www.井作恆.net/XKCD/1137.html On 2012年11月21日, at 上午10:22, Deborah Goldsmith golds...@apple.com wrote: http://xkcd.com/1137/ Finally, an xkcd for Unicoders. :-) Debbie

Re: xkcd: LTR

browser cannot display it and its displays the Punycoded name instead without decoding it. This is strange because I do have Deseret fonts installed and I can view Unicoded HTML pages containing Deseret letters. 2012/11/26 John H. Jenkins jenk...@apple.com Or, if one prefers: http

Re: The rules of encoding (from Re: Missing geometric shapes)

Whilst using the PUA is far from perfect at the end of the day it is better than the alternative of not using the PUA. Regards John On 10 Nov 2012 17:37, William_J_G Overington wjgo_10...@btinternet.com wrote: On Thursday 8 November 2012, Philippe Verdy verd...@wanadoo.fr wrote: 2012/11/8

Re: The rules of encoding (from Re: Missing geometric shapes)

One key criteris for inclusion in Unicode is that a character or symbol be in circulation. Whether these are hand written, printed or electronic. If one creates a new a new character then one first must get others to use it, this takes time. John On 8 Nov 2012 14:57, William_J_G Overington

Re: texteditors that can process and save in different encodings

BBEdit and TextWrangler on OS X both do a good job at handling different encodings. On 2012年10月3日, at 下午10:58, Stephan Stiller stephan.stil...@gmail.com wrote: Dear all, In your experience, what are the best (plaintext) texteditors or word processors for Linux / Mac OS X / Windows that

Re: Character set cluelessness

Sad to say this seems to be close to the norm for all to many large organizations where if it isn't in the 1990's version of the Times Roman font then it's out. John On 3 Oct 2012 00:26, Doug Ewell d...@ewellic.org wrote: The United Nations Economic Commission for Europe (UNECE) has released

Re: (Informational only: UTF-8 BOM and the real life)

, Colorado, USA http://www.ewellic.org | @DougEwell ­ -- John W Kennedy Give up vows and dogmas, and fixed things, and you may grow like That. ...you may come to think a blow bad, because it hurts, and not because it humiliates. You may come to think murder wrong, because it is violent

Re: pre-HTML5 and the BOM

, will create, when saving). -- John W Kennedy If Bill Gates believes in intelligent design, why can't he apply it to Windows?

Re: BOM ambiguity?

little-endianness. Has this been pointed out and discussed beforehand? Because the set of BOMs in different encodings don't constitute a prefix-free code. Isn't this why UTF-32 is forbidden for HTML 5? -- John W Kennedy Having switched to a Mac in disgust at Microsoft's combination

Re: Romanized Singhala - Think about it again

of them will pay any more attention to you. - John Burger MITRE

Re: Unicode Core

of the documentation. = Hoani H. Tinikini John H. Jenkins jenk...@apple.com

Re: Offlist: complex rendering

semantics—that is, they behave differently. It has nothing to do with Unicode failing to specify shapes. = Siôn ap-Rhisiart John H. Jenkins jenk...@apple.com

Re: Flag tags

countries have currency symbols with decidated code points, other countries will make *new* currency symbols and demand that *they* get dedicated code points, too. We all know how unrealistic a scenario *that* is. /tongue-in-cheek = John H. Jenkins jenk...@apple.com

Re: Plese add a Chinese Hanzi

literature should be considered urgent use, in my opinion, and encoded sooner rather than later. = Hoani H. Tinikini John H. Jenkins jenk...@apple.com

Re: Plese add a Chinese Hanzi

blog: http://shizhao.org twitter: https://twitter.com/shizhao [[zh:User:Shizhao]] = Hoani H. Tinikini John H. Jenkins jenk...@apple.com

Re: A new character to encode from the Onion? :)

another goddamn fertility symbol.terminator.gif Make that: currency symbol and ship it. Maybe a turtle ideograph? = 井作恆 John H. Jenkins jenk...@apple.com

Re: Unihan database

Frist Campus Center, Room 314 Princeton University Princeton, NJ 08544 United States = John H. Jenkins 井作恆 Жбь А. ЖЩэпЮьц jenk...@apple.com

Re: OFL (RE: Code2000 on SourceForge)

means free is for the freedom to do what you want with a piece of software, hence not being allowed to sell restricts one's freedom. John Tim

Re: Code2000 on SourceForge

questions he claims to be unable to remember anything. It should be noted also that the person is using the information posted by others in this mailing list to try to impersonate James Kass. Regards John

Re: Upside Down Fu character

), the character would be included in the UTC's submission to the IRG for Extension F. Work on Extension F will likely start in 2013. Andre Schappo 於 2012年1月13日 上午8:36 寫道： On 12 Jan 2012, at 16:54, John H. Jenkins wrote: Kang-Hao (Kenny) Lu 於 2012年1月12日 上午12:13 寫道： * Three folks think this is rather

Re: Upside Down Fu character

. In either case, somebody other than me (that is, somebody who wants them added to Unicode) needs to write a document/proposal to the UTC justifying that and giving the options for encoding. = John H. Jenkins 井作恆 Жбь А. ЖЩэпЮьц jenk...@apple.com

Re: Upside Down Fu character

/proposals.html. For hanzi, the characters need to be added to UTR #45 first, but I'm going to propose that for both the upside-down fuk1—er, fu, and the upside-down chun, since they have been discussed. UTR #45 lets us track such discussions. = 井作恆 John H. Jenkins jenk...@apple.com

Re: Upside Down Fu character

There are really three choices: 1) Don't encode it at all and rely on higher-level protocols to display it. (After all, it's only used in specialized contexts and does not have a distinct meaning or pronunciation from the regular 福.) 2) Use a registered ideographic variation sequence to

Re: missing characters: combining marks above runs of more than 2 base letters

seem pretty quixotic to me. (And before anybody accuses me of being overly cynical, I should point out that I'm probably the person putting in the greatest effort to get the Deseret Alphabet to be actually *used*. How quixotic is *that*?) = 井作恆 John H. Jenkins jenk...@apple.com

Re: [indic] Re: Lack of Complex script rendering support on Android

Mahesh T. Pai wrote PUA isn't necessary, and a font technology that handles elements of complex script shaping by referencing PUAs isn't fundamentally any different from one that uses glyph names or another identifier and leaves the glyph unencoded. Does one exist? Does it work? (we

Re: [indic] Re: Lack of Complex script rendering support on Android

Christopher Fynn wrote: OpenType is an openly available specification for fonts which anyone can use without paying a licence to adobe or microsoft who maintain the specification While Microsoft and Adobe maintain the OT specification, it should be noted that the OT spec is in synch with the

Re: [indic] Re: Lack of Complex script rendering support on Android

Mahesh T. Pai wrote: It is another matter that no font actually uses a non-opentype layout, which basically requires putting the non-encoded glyphs in the Private Use Area (PUA), and then call the glyphs by a name. PUA isn't necessary, and a font technology that handles elements of complex

Re: Unihan data for U+2B5B8 error

Andrew West 於 2011年10月20日 上午3:25 寫道： On 19 October 2011 18:41, John H. Jenkins jenk...@apple.com wrote: U+613F kDefinition (variant/simplification of U+9858 願) desire, want, wish; (archaic) prudent, cautious U+613F kSemanticVariant U+9858kFenn:T U+613F kSpecializedSemanticVariant U

Re: Unihan data for U+2B5B8 error

. This is a known (and, alas, long-standing) problem. We really do intend to get it fixed, but it's impossible to say when. = John H. Jenkins jenk...@apple.com

Re: Unihan data for U+2B5B8 error

you can't count on there being anybody reading this mailing list who can make the change. When you do so, *please* include a source for your information. We get all kinds of offered corrections to the Unihan data which we can't use because there's no authoritative source. = 井作恆 John H

Re: New version of UTR #45 published

of interest to people who are tracking IRG work. = Siôn ap-Rhisiart John H. Jenkins jenk...@apple.com

Re: Controls, gliphs, flies, lemonade

, some else in another (a_a / aa_ - double comb. char., sure you seen that), so we have no standard at all. Off course, i can learn this complex standard, but what for? Most of them i never use. There must be a simpler system, not so many aprior data for it work. 2011/9/13, John H. Jenkins

Re: RTL PUA?

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

Re: Code pages and Unicode

its red giant stage and threatens to engulf the Earth. ☺ = Siôn ap-Rhisiart John H. Jenkins jenk...@apple.com

Re: Code pages and Unicode

. This is an ex-possibility. And even if that *weren't* true, there are nowhere *near* enough kanji to have a serious impact on Ken's analysis. Richard Wordingham 於 2011年8月24日 下午4:51 寫道： Has Japanese disunification been completely killed, or merely scotched? = 井作恆 John H. Jenkins jenk

Re: RTL PUA?

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

Re: RTL PUA?

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.

Re: RTL PUA?

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

Re: RTL PUA?

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

Re: RTL PUA?

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

Re: Code pages and Unicode

that would be practical. = John H. Jenkins jenk...@apple.com

Re: RTL PUA?

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

  1   2   3   4   5   6   7   8   9   10   >