Re: Encoding italic

Oh, the crystal ball is pure solid state, no moving or hot parts. A magic 8-ball on the other hand can easily get jammed... (Now, enough of that...) /K Den 2019-02-12 02:57, skrev "James Kass via Unicode" : > > On 2019-02-11 6:42 PM, Kent Karlsson wrote: > >>

Re: Encoding colour (from Re: Encoding italic)

Den 2019-02-12 03:20, skrev "Mark E. Shoulson via Unicode" : > On 2/11/19 5:46 PM, Kent Karlsson via Unicode wrote: >> Continuing too look deep into the crystal ball, doing some more >> hand swirls... >> >> ... >> >> ... >> >> The

Re: Encoding italic

Den 2019-02-11 10:55, skrev "wjgo_10...@btinternet.com via Unicode" : > Doug Ewell wrote: > >> Š, just as next to nobody is using the proposed VS14 mechanism Š > > Well, of course not because use of VS14 in a plain text document to > record a request for an italic glyph version is not at the

Re: Encoding italic

Den 2019-02-10 16:31, skrev "James Kass via Unicode" : > > Philippe Verdy wrote, > >>> ...[one font file having both italic and roman]... For OpenType fonts, there is a "design axis" called "ital". Value 0 on that axis would be roman (upright, normally), and value 1 on that axis would be

Re: Encoding italic

Den 2019-02-08 21:53, skrev "Doug Ewell via Unicode" : > I'd like to propose encoding italics and similar display attributes in > plain text using the following stateful mechanism: Note that these do NOT nest (no stack...), just state changes for the relevant PART of the "graphic" (i.e. style)

Re: Encoding italic

Den 2019-02-08 22:29, skrev "Egmont Koblinger via Unicode" : > (Mind you, I don't find it a good idea to add italic and whatnot > formatting support to Unicode at all... but let's put aside that now.) I don't think Doug mean to "add it to the Unicode standard", just to have a summary of "handy

Re: Proposal for BiDi in terminal emulators

Den 2019-02-02 16:12, skrev "Richard Wordingham via Unicode" : > On Sat, 02 Feb 2019 14:01:46 +0100 > Kent Karlsson via Unicode wrote: > >> Well, I guess you may need to put some (practical) limit to the number >> of non-spacing marks (like max two abo

Re: Proposal for BiDi in terminal emulators

Den 2019-02-02 12:17, skrev "Egmont Koblinger" : > the font. It's taken from EastAsianWidth (or other means, which we're > working on: https://gitlab.freedesktop.org/terminal-wg/specifications/issues/9 Yes, that too: FE0F ? VARIATION SELECTOR-16 = emoji variation selector But the issue you

Re: Proposal for BiDi in terminal emulators

Den 2019-02-01 19:57, skrev "Richard Wordingham via Unicode" : > On Fri, 1 Feb 2019 13:02:45 +0200 > Khaled Hosny via Unicode wrote: > >> On Thu, Jan 31, 2019 at 11:17:19PM +, Richard Wordingham via >> Unicode wrote: >>> On Thu, 31 Jan 2019 12:46:48 +0100 >>> Egmont Koblinger wrote: >>>

Re: Encoding italic

her differences as well, but those are the major ones with regard to text styling. (I don't know those standards to a tee. I've just looked at the "m" control sequences for text styling. And yes, I looked at the free copies...) /Kent Karlsson PS If people insist on that EACH character in "

Re: Encoding italic

een around for decades and is still alive and well. I see absolutely no need for a "bold" new concept here; the one below is not better in any significant way. /Kent Karlsson Den 2019-01-29 23:35, skrev "Andrew West via Unicode" : > On Mon, 28 Jan 2019 at 01:55, James Kass via

Re: Encoding italic

Den 2019-01-28 02:53, skrev "James Kass via Unicode" : > plain-text and are uncomfortable using the math alphanumerics for this, > although the math alphanumerics seem well qualified for the purpose.  It "works" basically only for English (note that any diacritics would be placed suitable for

Re: Encoding italic

Apart from that control sequences for (some) styling is standardised (since decades by now), and the "tag characters" approach is not: For the control sequences for styling, there is no pretence of nesting, just setting/unsetting an aspect of styling. For etc. (in tag characters) there is at

Re: Encoding italic (was: A last missing link)

Den 2019-01-24 03:21, skrev "Mark E. Shoulson via Unicode" : > On 1/22/19 6:26 PM, Kent Karlsson via Unicode wrote: >> Ok. One thing to note is that escape sequences (including control sequences, >> for those who care to distinguish those) probably should be "def

Re: Encoding italic (was: A last missing link)

lementation-defined) There are some more (including some that assume a small font palette, for changing font). But far enough for now. Maybe too far already. But do not allow interpreting multiple style attribute codes in one control sequence; quite unnecessary. /Kent K Den 2019-01-21 21:46, skre

Re: Encoding italic (was: A last missing link)

-paste operation could auto-insert an esc-sequence that sets the the style after the paste to the one before the paste...) Had HTML (somehow, magically) been invented before terminals, maybe terminals (terminal emulators) would have used some kind of "mini-HTML" instead. But things

Re: Unicode 11 Georgian uppercase vs. fonts

I know it is too late now, but... Could have added the characters, without adding the case mappings. Just as it was done for the LATIN CAPITAL LETTER SHARP S (ẞ), where the proper case mapping was relegated to "special purpose software" (or just a special setting in common software). The (proper)

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-12 06:12, skrev "Garth Wallace" : > Shogi diagrams are uncheckered (as Shogi boards are), with grid-lines to > separate the spaces; traditionally, chess diagrams use the contrast of dark > and light squares to distinguish spaces with no grid lines. They may, but do

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-12 05:14, skrev "Garth Wallace" : > One salient feature the Block Elements have that the Box Drawing characters do > not: distinct LEFT and RIGHT verticals, and LOWER and UPPER horizontals. The > double frame typically consists of a thin line and a thicker line,

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-10 12:19, skrev "Michael Everson" : > I believe the box drawing characters are for drawing boxes Which is exactly what you are doing. > and grids on > computer terminals, which is not the same thing as scoring a line around a set > of 64 graphic images. No,

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-06 01:25, skrev "Michael Everson" : > Oh, here. This is what I would add. > > 2581 FE00; Chessboard box drawing; # LOWER ONE EIGHTH BLOCK > 258F FE00; Chessboard box drawing; # LEFT ONE EIGHTH BLOCK > 2594 FE00; Chessboard box drawing; # UPPER ONE EIGHTH BLOCK

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-06 03:05, skrev "Michael Everson" <ever...@evertype.com>: > On 6 Apr 2017, at 01:54, Kent Karlsson <kent.karlsso...@telia.com> wrote: > >>>> - some bidi fix [preferably making the box/border drawing characters bidi &

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-06 03:08, skrev "Michael Everson" <ever...@evertype.com>: > On 6 Apr 2017, at 02:05, Kent Karlsson <kent.karlsso...@telia.com> wrote: > >>> Do generic font makers intend to support both graphic terminal emulation and >>> chess? >&g

Re: Proposal to add standardized variation sequences for chess notation

ot matter (as long as no-one insist on using it for terminal emulation). All that is needed for that is a manoeuvre to copy a few glyphs within the font (when creating the font). I guess that is not very hard... /Kent K >> On 6 Apr 2017, at 01:31, Kent Karlsson <kent.karlsso...@telia

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-06 01:25, skrev "Michael Everson" : >> - some bidi fix [preferably making the box/border drawing characters bidi >> "L", if possible; otherwise a caveat that >>if there is an expectation to paste in such a board into an RTL document, >> bidi controls need

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-06 01:25, skrev "Michael Everson" : > Oh, you misunderstood me. I knew it was raw HTML. I didn¹t expect it to > render. But it was meaningless code. It was a response to Marcus, in that HTML might be used (with existing characters and no VSs) to format chess

Re: Proposal to add standardized variation sequences for chess notation

Exactly. /K Den 2017-04-06 01:25, skrev "Michael Everson" : > 2581 FE00; Chessboard box drawing; # LOWER ONE EIGHTH BLOCK > 258F FE00; Chessboard box drawing; # LEFT ONE EIGHTH BLOCK > 2594 FE00; Chessboard box drawing; # UPPER ONE EIGHTH BLOCK > 2595 FE00; Chessboard box

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-05 16:48, skrev "Michael Everson" : Kent, I can¹t read this in a plain-text e-mail. Well, it was SUPPOSED to be explicit HTML code in the email. It was NOT the intent that the given example was to be rendered directly in the email (even if you have HTML

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-04 00:35, skrev "Michael Everson" : >> What I am saying is that the glyphs for the two new variants you are >> proposing need to harmonise with the block elements such as U+2581 >> LOWER ONE EIGHTH BLOCK. > > NoŠ in a chess font the font designer has to draw

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-04 03:12, skrev "Michael Everson" : > It *is* important that there be an even number of characters in every row of 8 > squares for fallback display to be better rather than worse, I think. I agree. (Though *at present*, I happen to get a visible display of the

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-04 03:21, skrev "Asmus Freytag" : > would look like this, if you base your proposal on ligatures rather than > variation selectors (minimal case A above): > > ▕□︀▨︁□︀▨︁♙︁□︀♛︀▨︁□︀▨︁▏ That line has a lot of VSs in it... (I see them, since they happen to be

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-04 02:10, skrev "Michael Everson" <ever...@evertype.com>: > On 4 Apr 2017, at 00:45, Kent Karlsson <kent.karlsso...@telia.com> wrote: >> >> Book formatting? Old style book formatting still cannot use as sophisticated >> layouts

Re: Proposal to add standardized variation sequences for chess notation

I can well imagine people deeply interested in chess, to want to exchange chess board layouts in plain text emails (or at least not use quite hard-to-handle HTML code), and even parse them (programmatically) for analysis by a program, not wanting to bother with quite complex HTML/CSS stuff.

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-03 20:46, skrev "Kent Karlsson" <kent.karlsso...@telia.com>: > > Den 2017-04-03 19:51, skrev "markus@gmail.com" <markus@gmail.com>: > >> > It seems to me that higher-level layout (e.g, HTML+CSS) is appropriate for >>

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-03 19:51, skrev "markus@gmail.com" : > It seems to me that higher-level layout (e.g, HTML+CSS) is appropriate for the > board layout (e.g., via a table), board frame style, and cell/field shading. > In each field, the existing characters should suffice. > >

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-03 14:50, skrev "Michael Everson" : > On 2 Apr 2017, at 18:52, Richard Wordingham > wrote: >> >> You forgot the most important setting though - that the higher-order >> protocols allow symbols to be displayed left-to-right.

Re: Proposal to add standardized variation sequences for chess notation

Den 2017-04-02 01:33, skrev "Michael Everson" : >> but isn't the convention that one "always" start with FE00 for each character >> that may have variation selectors applied? > > I don¹t know what you mean by this. > 25A8 FE01; Black chessboard square; # SQUARE WITH

Re: Proposal to add standardized variation sequences for chess notation

In addition, not directly related to your proposal, why aren't chess pieces listed in http://unicode.org/emoji/charts/emoji-variants.html. It seems to me that chess pieces would be very well suited to have each an emoji variant (not to be used for the chess boards, maybe). /Kent K PS Remember

Re: Proposal to add standardized variation sequences for chess notation

2654 FE00; Chesspiece on white; # WHITE CHESS KING Why do the ones with white background need a variation selector? 25A1 FE00; White chessboard square; # WHITE SQUARE 25A8 FE01; Black chessboard square; # SQUARE WITH UPPER RIGHT TO LOWER LEFT FILL I see that you want a fallback in case the

Re: IJ with accent

Den 2016-09-28 22:48, skrev "Richard Wordingham" : > On Wed, 28 Sep 2016 12:30:04 -0700 > "Doug Ewell" wrote: > >>> Technically I see one, as bíj́na shound never break between í and >>> j́, >> >> These wor- >> ds should not bre- >> ak at

Re: IJ with accent

Den 2016-09-29 00:12, skrev "Alex Plantema" : > Op woensdag 28 september 2016 09:59 schreef a.lukyanov: > >> Dutch language writing uses the ligature ij (U+0132, U+0133). When accented, >> it should take an accent on each component, like this: >> >> If one uses two

Re: Swapcase for Titlecase characters

Den 2016-03-19 17:40, skrev "Doug Ewell" : > As one anecdote (which is even less like "data" than two anecdotes), I > could not find any of the characters IJ ij DŽ Dž dž LJ Lj lj NJ Nj nj or their hex (You missed the DZ "ligature" (which aren't really ligatures).) As mentioned, for the IJ

Re: N'Ko - which character? 02BC vs. 2019

Den 2015-02-02 19:36, skrev Michael Everson ever...@evertype.com: Hawaiian Hobbit, U+02BB has been drawn 133% taller, but of the same width, as U+2018. I believe this really must be considered good practice. In these I think you mean 33 % taller, i.e. height 133 % relative to its normal

Re: Contrastive use of kratka and breve

Sounds to me that what you really want is to have two different breve characters (assuming that the distinction is real and intentional, and not a happenstance). That would require encoding a new combining character, AFAICT... /Kent K Den 2014-07-02 20:48, skrev Leo Broukhis l...@mailcom.com:

Re: Unicode organization is still anti-Serbian and anti-Macedonian

Den 2014-02-17 10:33, skrev Gerrit Ansmann gansm...@uni-bonn.de: I don't like the idea, but one possibility would be to define Serbian glyph styles by adding variation selectors. Variation selectors are already 'defined' for the decimal digits U+0030 to U+0039. It would, however, mess up

Re: Why blackletter letters?

Den 2013-09-10 20:34, skrev Whistler, Ken ken.whist...@sap.com: Items listed there in green are still under ballot in ISO, while items listed in yellow are not yet in ballot in ISO. For those, input is still useful. If the entry is listed in white, forget it. Those items are already too

Re: Why blackletter letters?

Den 2013-09-10 19:01, skrev Asmus Freytag asm...@ix.netcom.com: Good question, Jean-François. I seem to recall that typographers may make a distinction between black-letter and fraktur forms, but even if they, the differences are typographical, not essential. For the purpose of *character*

Re: Shaping Hangul text with U+115F and/or U+1160

, are are no longer interpreted) and format controls (they should not render, whether you can interpret them or not). It goes also for the Hangul filler characters, because they are there for syntactic reasons, and should not render whether you can support them properly or not. /Kent Karlsson Den

Re: Missing geometric shapes

Den 2012-11-11 23:08, skrev Doug Ewell d...@ewellic.org: Personal opinions follow. It looks like the only actual use case we have, exemplified by the xkcd strip, is for a star with the left half black and the right half white. There *might* also be a case for the left-white, right-black

Re: Missing geometric shapes

Den 2012-11-08 14:34, skrev Asmus Freytag asm...@ix.netcom.com: On 11/8/2012 2:27 AM, Martin J. Dürst wrote: On 2012/11/08 19:15, Michael Everson wrote: On 8 Nov 2012, at 09:59, Simon Montagusmont...@smontagu.org wrote: Please take into account that the half-stars should be

Re: Missing geometric shapes

Den 2012-11-09 00:09, skrev Michael Everson ever...@evertype.com: On 8 Nov 2012, at 22:54, Kent Karlsson kent.karlsso...@telia.com wrote: 2605;BLACK STAR;So;0;ON;N; 2606;WHITE STAR;So;0;ON;N; The *chart* glyphs for these aren't same-sized (outer outline)Š So

Re: Missing geometric shapes

Den 2012-11-09 01:22, skrev Asmus Freytag asm...@ix.netcom.com: On 11/8/2012 3:40 PM, Philippe Verdy wrote: Usually, we see the high ratings displayed as multiple stars, that are either present or absent, but rarely half filled. Half filled stars are relatively common, whenever there are

Re: Small i with/out dot and with arrow

characters, and some combining characters are not diacritics. Leo On Wed, Aug 1, 2012 at 11:53 AM, Kent Karlsson kent.karlsso...@telia.com wrote: Den 2012-08-01 19:41, skrev Andreas Prilop prilop4...@trashmail.net: Is it correct that U+0069 U+20D7 U+006A U+20D7 should have a dot

Re: Small i with/out dot and with arrow

Den 2012-08-01 19:41, skrev Andreas Prilop prilop4...@trashmail.net: Is it correct that   U+0069 U+20D7   U+006A U+20D7 should have a dot No, they are soft-dotted: 0069..006A; Soft_Dotted # L [2] LATIN SMALL LETTER I..LATIN SMALL LETTER J which means that the inherent dot should

Re: Unicode 6.2 to Support the Turkish Lira Sign

Somebody wrote: For the ₤ we can define EXACTLY what it is: a scriptive capital Latin L with a double crossbar, in this very combination standing in for the term “Lira” (derived from Latin “libra”), meaning a monetary unit of that same name. ₤ (and £, which should have been the same

Re: Kaktovik Inupiaq numerals

Den 2012-04-28 12:50, skrev Richard Wordingham richard.wording...@ntlworld.com: On Fri, 27 Apr 2012 13:50:15 -0700 Ken Whistler k...@sybase.com wrote: On 4/27/2012 10:45 AM, Richard Wordingham wrote: If they are to be adopted by the CLDR, the digits need to be coded consecutively. I

Re: Sorting and German (was: Sorting and Volapük)

Except that MacOS X *applications* (as apart from more POSIXy programs, and Terminal.app) should not use the POSIX locales, but should use the CLDR locales (via an Apple API or via ICU)... (Yes, I know, CLDR have POSIX locales format files covering **some** of the CLDR data...) And ISO 8859-15?

Re: Sorting and German (was: Sorting and Volapük)

Not sure why this discussion is on the Unicode list instead of the cldr-users list... Anyhow... While I do find (in CLDR's collation de.xml) a collation type=phonebook I don't find any variant doing the Austrian phonebook variant you mention. Maybe you could file a ticket for adding that to

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

Den 2011-11-20 20:50, skrev Peter Constable peter...@microsoft.com: Note that UTR 20 discusses semantic and presentation effects that are suitable for representation as characters versus markup and makes the point that, in XML, effects that involve spans of text should be represented using

Re: N4106

Den 2011-11-07 10:34, skrev vanis...@boil.afraid.org vanis...@boil.afraid.org: So despite being given (as proposed) vanilla above/below mark properties, they do not stack the way such characters normally do, but is supposed to invoke an entirely new behaviour. I agree, except that if we

Re: N4106

Den 2011-11-05 04:23, skrev António Martins-Tuválkin tuval...@gmail.com: I'm going through N4106 ( http://std.dkuug.dk/jtc1/sc2/wg2/docs/n4106.pdf ), ... I see the following characters being put forward for proposing to be encoded: 1ABB COMBINING PARENTHESES ABOVE 1ABC COMBINING DOUBLE

Re: Arabic date format and Microsoft programs

Just in case somebody has missed this: There is a public review issue very much related to this thread: http://www.unicode.org/review/pri205/, Proposed addition of AL MARK and LEVEL DIRECTION MARK, http://www.unicode.org/review/pri205/pri205-background.html. The latter proposed addition is

Re: about P1 part of BIDI alogrithm

Den 2011-10-11 09:43, skrev Eli Zaretskii e...@gnu.org: Let me give you just one example: if the character should be mirrored, you cannot decide whether it fits the display line until _after_ you know what its mirrored glyph looks like. But mirroring is only resolved at a very late stage of

Re: Need for Level Direction Mark

Den 2011-09-22 10:54, skrev Philippe Verdy verd...@wanadoo.fr: 2011/9/21 Richard Wordingham richard.wording...@ntlworld.com: LRE...PDF acts like a character with BiDi class L, and likewise for RLE...PDF.  I suppose the principle is that in a right-to-left context a word composed of letters

Re: Need for Level Direction Mark

Den 2011-09-19 04:53, skrev Peter Edberg pedb...@apple.com: Philippe, On Sep 17, 2011, at 12:54 PM, Philippe Verdy wrote: ... Note also that there's no way to specify a weak direction for the internal content of embedded fields, as we don't have the WDE..PDF mechanism described in the

Re: Need for Level Direction Mark

Den 2011-09-14 03:31, skrev Philippe Verdy verd...@wanadoo.fr: 2011/9/13 Kent Karlsson kent.karlsso...@telia.com: ... for the new one, and to the paragraph bidi level for the three old ones). (I know, this would be a form of option 1 in the PRI.) You can turn it as you want it is still

Re: Need for Level Direction Mark

Den 2011-09-14 19:05, skrev Philippe Verdy verd...@wanadoo.fr: 2011/9/14 Kent Karlsson kent.karlsso...@telia.com: Because that stability guarantee says The Bidi_Class property values will not be further subdivided. I'm not too keen on the word subdivided here, ... That's absolutely

Re: Need for Level Direction Mark

Den 2011-09-14 19:56, skrev Philippe Verdy verd...@wanadoo.fr: 2011/9/14 Kent Karlsson kent.karlsso...@telia.com: And how will you define what is an implicit LDM ? For example 1.2 Did you actually READ my submission re. the PRI? Seems like not. There is a suggestion there (which requires

Re: ligature usage - WAS: How do we find out what assigned code points aren't normally used in text?

Den 2011-09-11 18:53, skrev Peter Constable peter...@microsoft.com: There's no requirement that the width of glyphs in a monospaced font be 1 em. I would agree, though, that if a monospaced font forms a ligature of a pair like 0066, 0069, then it should be twice the width (not necessarily

Re: ligature usage - WAS: How do we find out what assigned code points aren't normally used in text?

Den 2011-09-10 20:58, skrev Jukka K. Korpela jkorp...@cs.tut.fi: There is a deeper language-dependency. According to Oxford Style Manual, one should not use the fi ligature in Turkish, as that would obscure the distinction between normal i and dotless i (ž). This makes perfect sense to me.

Re: ligature usage - WAS: How do we find out what assigned code points aren't normally used in text?

Den 2011-09-10 23:06, skrev Richard Wordingham richard.wording...@ntlworld.com: On Sat, 10 Sep 2011 22:19:27 +0200 Kent Karlsson kent.karlsso...@telia.com wrote: Den 2011-09-10 20:58, skrev Jukka K. Korpela jkorp...@cs.tut.fi: According to Oxford Style Manual, one should not use

Re: ligature usage - WAS: How do we find out what assigned code points aren't normally used in text?

Den 2011-09-11 01:23, skrev Richard Wordingham richard.wording...@ntlworld.com: On Sat, 10 Sep 2011 23:53:34 +0200 Kent Karlsson kent.karlsso...@telia.com wrote: IMO, a glyph (if any) for that compatibility character should look *exactly* like an fi (after automatic ligature formation

Re: How do we find out what assigned code points aren't normally used in text?

Den 2011-09-09 21:24, skrev Karl Williamson pub...@khwilliamson.com: On 07/06/2011 04:23 PM, Ken Whistler wrote: I'm not sure whether the FB05/FB06 instance is important enough to add or not. Neither of those compabitility ligatures should ordinarily be used in text, anyway ... --Ken

Re: ligature usage - WAS: How do we find out what assigned code points aren't normally used in text?

I was talking about purely typographic ligatures, in particular ligatures used because the glyphs (normally spaced) would otherwise overlap in an unpleasing manner. If the glyphs don't overlap (or there is extra spacing, which is quite ugly in itself if used in normal text), no need to use a

Re: How do we find out what assigned code points aren't normally used in text?

...@khwilliamson.com: On 09/09/2011 02:36 PM, Kent Karlsson wrote: getting these ligatures to work is quite hard, and it would be nice to How do you mean getting these ligatures to work? These particular Sorry that I took out too much of the original context. This is about implementing

Re: ligature usage - WAS: How do we find out what assigned code points aren't normally used in text?

Den 2011-09-10 02:32, skrev Stephan Stiller sstil...@stanford.edu: Actually, I *was* talking about purely typographic/aesthetic ligatures as well. I'm aware that which di-/trigraphs need to be considered from a font design perspective is language-dependent. But the point is that I

Re: Continue:Glaring mistake in the code list for South Asian Script

Den 2011-09-10 00:53, skrev delex r del...@indiatimes.com: I figure out that Unicode has not addressed the sovereignty issues of a language Which, I daresay, is irrelevant from a *character* encoding perspective. while trying to devise an ASCII like encoding system for almost all the

Re: Application that displays CJK text in Normalization Form D

Den 2010-11-15 23:53, skrev Doug Ewell d...@ewellic.org: When I type the ideograph 漢 (U+FA47) into BabelPad, highlight it, and then click the button labeled Normalize to NFC, the character becomes 漢 (U+6F22). Does BabelPad not conform to the Unicode Standard in this case? Is this not truly

Re: looks like some problem in Scripts.txt file of UCD

Den 2010-08-13 02.28, skrev Pravin Satpute psatp...@redhat.com: Yes, problem is happening only when these characters come at initial position. i.e U+0951 and U+0952 in isolation should render with U+25cc U+25CC should never be inserted automatically. That some systems do so is a bug (no

Re: CSUR Tonal

Den 2010-08-06 11.02, skrev Andrew West andrewcw...@gmail.com: On 6 August 2010 05:14, Doug Ewell d...@ewellic.org wrote: What makes this troublesome for me is that, on the one hand, there are the perfectly ordinary-looking 0 through 8, and on the other hand there are the invented digits

Re: CSUR Tonal

I see absolutely no point in reencoding the digits 0-9 even though 9 is (strangely) used to denote the value that is usually denoted 10. That is just a (very strange) usage, not different characters from the ordinary 0-9. /kent k Den 2010-08-02 19.54, skrev Doug Ewell d...@ewellic.org:

Re: CSUR Tonal

Den 2010-08-05 00.20, skrev Doug Ewell d...@ewellic.org: Kent Karlsson kent dot karlsson14 at telia dot com wrote: I see absolutely no point in reencoding the digits 0-9 even though 9 is (strangely) used to denote the value that is usually denoted 10. That is just a (very strange) usage

Re: CSUR Tonal

Since no-one else seems to have responded to Luke... Den 2010-07-30 22.09, skrev Luke-Jr l...@dashjr.org: This isn't about them not looking *exactly* the same, it's about these existing modifiers being inconsistent with each other in visibly noticable ways. That is most certainly a font

Re: High dot/dot above punctuation?

Den 2010-07-29 08.47, skrev Khaled Hosny khaledho...@eglug.org: I have few fonts where I implemented a 'locl' OpenType feature that maps European to Arabic digits, and contextual substitution feature that replaces the dot with Arabic decimal separator when it comes between two Arabic

Re: High dot/dot above punctuation?

Den 2010-07-28 09.50, skrev Jukka K. Korpela jkorp...@cs.tut.fi: André Szabolcs Szelp wrote: Generally, for the decimal point . (U+002E FULLSTOP) and , (U+002C COMMA) is used in the SI world. However, earlier conventions could use different notation, such as the common British raised dot

Re: High dot/dot above punctuation?

Den 2010-07-28 17.09, skrev Jukka K. Korpela jkorp...@cs.tut.fi: Kent Karlsson wrote: And the Nameslist says: 002EFULL STOP = period, dot, decimal point * may be rendered as a raised decimal point in old style numbers Right, I remembered there is such a comment somewhere

Re: CSUR Tonal

Den 2010-07-26 02.48, skrev Doug Ewell d...@ewellic.org: superscript letters S, T, b, m, r, s, and t. [...] ... Imagine my surprise, then, when I found that these superscripts are not formally encoded (only i and n are). [...] There are more superscripted letters than i and n that are

Re: Using Combining Double Breve and expressing characters perhaps as if struck out.

Den 2010-07-24 10.07, skrev Philippe Verdy verd...@wanadoo.fr: Double diacritics have a combining property equal to zero, so they No, they don't. The above ones have combining class 234 and the below ones have combining class 233 (other characters with the word DOUBLE in them are 'double' in

Re: [indic] Indian Rupee symbol

Den 2010-07-15 11.54, skrev N. Ganesan naa.gane...@gmail.com: On Thu, Jul 15, 2010 at 4:08 AM, Dr Pavanaja pavan...@vishvakannada.com wrote: Now that Indian Rupee symbol has been finalised and accepted  by the Indian Parliament can it go into Unicode ver 6.0? For a look at the new sign

Re: Indian Rupee Sign to be chosen today

Den 2010-06-28 10.16, skrev Michael Everson ever...@evertype.com: On 28 Jun 2010, at 06:41, Mahesh T. Pai wrote: Mahesh T. Pai said on Mon, Jun 28, 2010 at 10:57:53AM +0530,: On a serious note - 1. Would a change of glypn / glyph shape be considered? It would depend on what is

Re: U+0000 in C strings

Of course you can have NULL in a C string. It is just that many (not all) standard C functions that accept a string argument, interpret/use NULL for ending a string. That is the convention used for many user defined functions that accept string arguments or produce a string too. But some

RE: bit notation in ISO-8859-x is wrong

Not counting from zero leads to weird situations at times, such as the missing year 0 in the BC/AD system ;-) Well, since you couldn't resist, nor can I... There are (really) two systems here, not one, and the relationship is: year X AD = year (1-X) BC (and thus: year X BC = year

RE: Saudi-Arabian Copyright sign

Kenneth Whistler wrote: Second, there is the question of cursive joining for Arabic. I don't know anything in the Unicode Standard that states that a combining enclosing mark breaks cursive ligation. It stands to reason that it *should*, but I don't know anything that requires it. Well,

Re: Arabic Implementation

After a character changes the display form into one mentioned in Arabic Presentation Form B does it still belong to a joining type. Nope. All the Arabic presentation forms implicitly have the joining type U (non-joining) [and the joining metagroup no shaping]. For example: Lets say Unicode

Re: Error in Hangul composition code

http://www.unicode.org/reports/tr15/ says: int SIndex = last - SBase; ... The arithmetic decomposition of the Hangul Syllable characters can be described as follows: Each Hangul precomposed syllable character of Hangul_Syllable_Type LV has a canonical decomposition into an L and a

RE: any unicode conversion tools?

Peter Constable wrote: UTF-8 sequences, as originally defined, could be longer than four bytes, in order to address codepoints in the vast expanse of UCS-4 at U+11..U+. Since the accepted code space has been constrained to U+..U+10, only four bytes are needed. There

RE: Phoenician

Michael Everson Wrote: This sort of battle was fought over Runic: Runologists wanted the Runes to be sorted in Latin alphabetical order, Yes, but there was no suggestion to interleave the Runes with the Latin script. So the example of the Runes is not a parallel to the current discussion.

RE: interleaved ordering (was RE: Phoenician)

Title: Message -Original Message-From: Mike Ayers [mailto:[EMAIL PROTECTED] And it might make sense to interleave (say) Thai and Lao in the default ordering. No, it wouldn't. That's not an argument... Hmmm? Are you looking for some kind of

RE: interleaved ordering (was RE: Phoenician)

... (The Thai letters in turn derive from the Khmer letters... That's not correct. Just to check that it is not just *my* imagination that is running wild... ;-) http://encyclopedia.thefreedictionary.com/Thai%20alphabet says: History The Thai alphabet is probably derived from the Old Khmer

RE: interleaved ordering (was RE: Phoenician)

And it might make sense to interleave (say) Thai and Lao in the default ordering. No, it wouldn't. That's not an argument... Or to interleave, in the default ordering, the Indic scripts covered by ISCII. No, it wouldn't! Nor is that... Any pecularities could be handled in

  1   2   3   >