Base character plus tag sequences (from RE: Is the binaryness/textness of a data format a property?)

Doug Ewell wrote: When 137,468 private-use characters aren't enough? In my opinion, a base character plus tag sequence has the potential to be used for many large scale applications for the future. A base character plus tag sequence encoding has the advantage over a Private Use Area encoding

Re: Is the binaryness/textness of a data format a property?

On 23/03/2020 03:56, Markus Scherer via Unicode wrote: > On Sat, Mar 21, 2020 at 12:35 PM Doug Ewell via Unicode > wrote: > >> I thought the whole premise of GB18030 was that it was Unicode mapped into >> a GB2312 framework. What characters exist in GB18030 that don't exist in >> Unicode, and

Re: Is the binaryness/textness of a data format a property?

On Sat, Mar 21, 2020 at 12:35 PM Doug Ewell via Unicode wrote: > I thought the whole premise of GB18030 was that it was Unicode mapped into > a GB2312 framework. What characters exist in GB18030 that don't exist in > Unicode, and have they been proposed for Unicode yet, and why was none of > the

Re: Is the binaryness/textness of a data format a property?

On Sat, 21 Mar 2020 13:33:18 -0600 Doug Ewell via Unicode wrote: > Eli Zaretskii wrote: > > Emacs uses some of that for supporting charsets that cannot be > > mapped into Unicode. GB18030 is one example of such charsets. The > > internal representation of characters in Emacs is UTF-8, so it

RE: Is the binaryness/textness of a data format a property?

Eli Zaretskii wrote: >> When 137,468 private-use characters aren't enough? > > Why is that relevant to the issue at hand? You're right. I did ask what the uses of non-standard UTF-8 were, and you gave me an example. > I don't remember off hand, but last time I looked at GB18030, there > were a

Re: Is the binaryness/textness of a data format a property?

On 2020-03-21, Eli Zaretskii via Unicode wrote: >> Date: Sat, 21 Mar 2020 11:13:40 -0600 >> From: Doug Ewell via Unicode >> >> Adam Borowski wrote: >> >> > Also, UTF-8 can carry more than Unicode -- for example, U+D800..U+DFFF >> > or U+11000..U+7FFF (or possibly even up to 2³⁶ or 2⁴²),

Re: Is the binaryness/textness of a data format a property?

> From: "Doug Ewell" > Cc: > Date: Sat, 21 Mar 2020 13:33:18 -0600 > > > Emacs uses some of that for supporting charsets that cannot be mapped > > into Unicode. GB18030 is one example of such charsets. The internal > > representation of characters in Emacs is UTF-8, so it uses 5-byte > >

RE: Is the binaryness/textness of a data format a property?

Eli Zaretskii wrote: >>> Also, UTF-8 can carry more than Unicode -- for example, >>> U+D800..U+DFFF or U+11000..U+7FFF (or possibly even up to 2³⁶ or >>> 2⁴²), which has its uses but is not well-formed Unicode. >> >> I'd be interested in your elaboration on what these uses are. > > Emacs uses

Re: Is the binaryness/textness of a data format a property?

> Date: Sat, 21 Mar 2020 11:13:40 -0600 > From: Doug Ewell via Unicode > > Adam Borowski wrote: > > > Also, UTF-8 can carry more than Unicode -- for example, U+D800..U+DFFF > > or U+11000..U+7FFF (or possibly even up to 2³⁶ or 2⁴²), which has > > its uses but is not well-formed Unicode. >

Re: Is the binaryness/textness of a data format a property?

Adam Borowski wrote: > Also, UTF-8 can carry more than Unicode -- for example, U+D800..U+DFFF > or U+11000..U+7FFF (or possibly even up to 2³⁶ or 2⁴²), which has > its uses but is not well-formed Unicode. I'd be interested in your elaboration on what these uses are. -- Doug Ewell |

Re: Is the binaryness/textness of a data format a property?

On 20/03/2020 23:41, Adam Borowski via Unicode wrote: > Also, UTF-8 can carry more than Unicode -- for example, U+D800..U+DFFF or > U+11000..U+7FFF (or possibly even up to 2³⁶ or 2⁴²), which has its uses > but is not well-formed Unicode. This would definitely no longer be UTF-8! Martin.

Re: Is the binaryness/textness of a data format a property?

On Fri, 20 Mar 2020 13:46:25 +0100 Adam Borowski via Unicode wrote: > On Fri, Mar 20, 2020 at 12:21:26PM +, Costello, Roger L. via > Unicode wrote: > > [Definition] Property: an attribute, quality, or characteristic of > > something. > > > > JPEG is a binary

Re: Is the binaryness/textness of a data format a property?

On Fri, Mar 20, 2020 at 07:22:45AM -0700, J Decker via Unicode wrote: > On Fri, Mar 20, 2020 at 5:48 AM Adam Borowski via Unicode < > > For example, most Unix-heads will tell you that UTF16LE is a binary rather > > than text format. Microsoft employees and some me

Re: Is the binaryness/textness of a data format a property?

On Fri, Mar 20, 2020 at 5:48 AM Adam Borowski via Unicode < unicode@unicode.org> wrote: > On Fri, Mar 20, 2020 at 12:21:26PM +, Costello, Roger L. via Unicode > wrote: > > [Definition] Property: an attribute, quality, or characteristic of > something. > > >

Re: Is the binaryness/textness of a data format a property?

On Fri, Mar 20, 2020 at 12:21:26PM +, Costello, Roger L. via Unicode wrote: > [Definition] Property: an attribute, quality, or characteristic of something. > > JPEG is a binary data format. > CSV is a text data format. > > Question #1: Is the binaryness/textness of a data

AW: Is the binaryness/textness of a data format a property?

#1: Yes. #2: [ my suggestion ] File type category A.D. -Ursprüngliche Nachricht- Von: Unicode Im Auftrag von Costello, Roger L. via Unicode Gesendet: Freitag, 20. März 2020 13:21 An: unicode@unicode.org Betreff: Is the binaryness/textness of a data format a property? Hello Data

Is the binaryness/textness of a data format a property?

Hello Data Format Experts! [Definition] Property: an attribute, quality, or characteristic of something. JPEG is a binary data format. CSV is a text data format. Question #1: Is the binaryness/textness of a data format a property? Question #2: If the answer to Question #1 is yes, then what

Re: Website format (was Re: Unicode website glitches. (was The Most Frequent Emoji))

On 10/12/2019 1:16 AM, Daniel Bünzli via Unicode wrote: With all due respect for the work that has been done on the new website I think that the new structure significantly decreased the usability of the website for technical users. ^^^  This 

Website format (was Re: Unicode website glitches. (was The Most Frequent Emoji))

On 12 October 2019 at 02:05:23, Martin J. Dürst via Unicode (unicode@unicode.org) wrote: > I think it's less the format and much more the split personality of the > Unicode Web site(s?) that I have problems with. I also do.  One thing that is particulary annoying is the fact that the

Format A

Apologies if this is a repeat of a (much) earlier inquiry. The mapping tables that are available as part of the Unicode Standard (http://www.unicode.org/Public/MAPPINGS/) are generally provided in a text format called "Format A." Each line in the file defines a mapping between a

Re: IDC's versus Egyptian format controls

Martin J. Dürst wrote: > Is it only me or did you get some of this data wrong? Yes, sorry. There's an offset. I copy/pasted data from an archive which apparently predates the formal release of Ext C, and IIRC there was some shifting. Unfortunately the font I used to view the data matches the

Re: IDC's versus Egyptian format controls

On 2018/02/17 08:25, James Kass via Unicode wrote: Some people studying Han characters use the IDCs to illustrate the ideographs and their components for various purposes. Well, as far as I understand, this was their original (and is still their main) purpose. For example: U-0002A8B8 ꢸ

Re: IDC's versus Egyptian format controls

I apologize for apparently misunderstanding the scope of what was being proposed. If a finite set of unencoded Han characters needs to be displayed correctly using IDSes, then the complexity of the look-up tables depends upon how many characters are in the set. It would probably best be handled

Re: IDC's versus Egyptian format controls

On Fri, 16 Feb 2018 18:05:41 -0800 James Kass via Unicode wrote: > Richard Wordingham wrote: > > > One can argue that once the compound ideograph have been encoded, > > the IDS should no longer be interpreted. > > Wouldn't that break existing data? If this sort of thing

Re: IDC's versus Egyptian format controls

> Wouldn't that break existing data? Functionality, not data.

Re: IDC's versus Egyptian format controls

Richard Wordingham wrote: > One can argue that once the compound ideograph have been encoded, the > IDS should no longer be interpreted. Wouldn't that break existing data? If this sort of thing were done at OS or app level, it might be possible to replace the IDS string with the appropriate

Re: IDC's versus Egyptian format controls

Richard Wordingham wrote: > There is another possible use of the latitude given by TUS 5.0 to 10.0 > and possibly earlier. I can certainly imagine a case where someone > writes a font so that an unencoded character may be manipulated like any > other character. He has two choices - he can put

Re: IDC's versus Egyptian format controls

On Fri, 16 Feb 2018 15:25:22 -0800 James Kass via Unicode wrote: > Some people studying Han characters use the IDCs to illustrate the > ideographs and their components for various purposes. For example: > > U-0002A8B8 ꢸ ⿰土土 > U-0002A8B9 ꢹ ⿰土凡 > U-0002A8BA ꢺ ⿱夂土 >

Re: IDC's versus Egyptian format controls

Richard Wordingham wrote, > And doing it reasonably well could be a lot of work. > However, I don't see any good reason to discourage > fonts from doing it by default, which is what is now > being proposed. Some people studying Han characters use the IDCs to illustrate the ideographs and their

Re: IDC's versus Egyptian format controls

On Fri, 16 Feb 2018 11:10:29 -0800 Ken Whistler via Unicode wrote: > On 2/16/2018 11:00 AM, Asmus Freytag via Unicode wrote: > > On 2/16/2018 8:00 AM, Richard Wordingham via Unicode wrote: > >> That doesn't square well with, "An implementation *may* render a > >> valid

Re: IDC's versus Egyptian format controls

On 2/16/2018 11:10 AM, Ken Whistler wrote: It's the "may either" which is not the same as "may also". A./ On 2/16/2018 11:00 AM, Asmus Freytag via Unicode wrote: On 2/16/2018 8:00 AM, Richard Wordingham via Unicode wrote: That doesn't square well with, "An implementation *may* render a

Re: IDC's versus Egyptian format controls

On 2/16/2018 11:00 AM, Asmus Freytag via Unicode wrote: On 2/16/2018 8:00 AM, Richard Wordingham via Unicode wrote: That doesn't square well with, "An implementation *may* render a valid Ideographic Description Sequence either by rendering the individual characters separately or by parsing

Re: IDC's versus Egyptian format controls

raphic description characters) are explicitly *not* format controls. They are visible graphic symbols that sit visibly in text. That doesn't square well with, "An implementation may render a valid Ideographic Description Sequence either by rendering the individual characters separately or

Re: IDC's versus Egyptian format controls

graphic description > characters) are explicitly *not* format controls. They are visible > graphic symbols that sit visibly in text. That doesn't square well with, "An implementation may render a valid Ideographic Description Sequence either by rendering the individual characters se

Re: IDC's versus Egyptian format controls

On 2/16/2018 8:22 AM, Ken Whistler wrote: The Egyptian quadrat controls, on the other hand, are full-fledged Unicode format controls. One more point of distinction: The (gc=So) IDC's follow a syntax that uses Polish notation order for the descriptive operators (inherited from the intended

IDC's versus Egyptian format controls (was: Re: Why so much emoji nonsense?)

is being developed for blocks of Egyptian Hieroglyphs, and has been proposed for Mayan as well. A point of clarification: The IDC's (ideographic description characters) are explicitly *not* format controls. They are visible graphic symbols that sit visibly in text. There is a specified syntax

Transforming BidiTest.txt to the format of BidiCharacterTest.txt

Does anybody have a program that transforms the UCD file BidiTest.txt to the format of BidiCharacterTest.txt, and that they are willing to share? Thanks, Eric. ___ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode

RE: Transforming BidiTest.txt to the format of BidiCharacterTest.txt

Eric, The C version of the bidiref code does that, in part. See the function br_ParseFileFormatB in brinput.c. http://www.unicode.org/Public/PROGRAMS/BidiReferenceC/6.3.0/ It doesn't actually *transform* the BidiTest.txt file to output the other format, but it parses the input

Re: Transforming BidiTest.txt to the format of BidiCharacterTest.txt

* the BidiTest.txt file to output the other format, but it parses the input and then constructs calls into the bidi testing API in the same format used when it parses BidiCharacterTest.txt. So you could adapt that code, if you want, to writing out lines in the format of BidiCharacterTest.txt. The main

Re: Arabic date format and Microsoft programs

is partially motivated by date format direction issues. /Kent K Den 2011-10-17 13:00, skrev Eli Zaretskii e...@gnu.org: Date: Mon, 17 Oct 2011 10:09:06 +0100 From: Peter Krefting pe...@opera.com Eli Zaretskii e...@gnu.org: However, it could be that the confusion is mine, and it stems from

Re: Arabic date format and Microsoft programs

On 10/15/2011 05:19 PM, Andreas Prilop wrote: I return to http://www.unicode.org/mail-arch/unicode-ml/y2011-m10/att-0059/1999-12-31.html Microsoft programs (Internet Explorer, MS Word), display this as 31/12/1999 Other programs (Firefox, Opera, OpenOffice) display this as 1999/12/31

Re: Arabic date format and Microsoft programs

Date: Mon, 17 Oct 2011 08:42:02 +0200 From: Simon Montagu smont...@smontagu.org List-software: Ecartis version 1.0.0 On 10/15/2011 05:19 PM, Andreas Prilop wrote: I return to http://www.unicode.org/mail-arch/unicode-ml/y2011-m10/att-0059/1999-12-31.html Microsoft programs (Internet

Re: Arabic date format and Microsoft programs

On 10/17/2011 10:08 AM, Eli Zaretskii wrote: Date: Mon, 17 Oct 2011 08:42:02 +0200 From: Simon Montagusmont...@smontagu.org List-software: Ecartis version 1.0.0 On 10/15/2011 05:19 PM, Andreas Prilop wrote: I return to

Re: Arabic date format and Microsoft programs

Eli Zaretskii e...@gnu.org: Btw, according to my testing, the current Firefox displays this as 31/12/1999. I don't have Opera or OO to check there, but it's possible that the OP was using old versions of these that were still using the old Unicode data base. It still displays as

Re: Arabic date format and Microsoft programs

Date: Mon, 17 Oct 2011 10:35:39 +0200 From: Simon Montagu smont...@smontagu.org CC: unicode@unicode.org Sorry, I think I confused you here. I quoted the expected rendering in ASCII digits, but the testcase in fact uses Arabic-Indic digits. There's no difference in rendering of ASCII

Re: Arabic date format and Microsoft programs

Eli Zaretskii e...@gnu.org: However, it could be that the confusion is mine, and it stems from the fact that the logical order of these characters was not stated by the OP. Is it 1999/12/31 or 31/12/1999 ? The logical order in the document that was cited is 1999/12/31 (١٩٩٩/١٢/٣١). I

Re: Arabic date format and Microsoft programs

Date: Mon, 17 Oct 2011 09:40:02 +0100 From: Peter Krefting pe...@opera.com Eli Zaretskii e...@gnu.org: Btw, according to my testing, the current Firefox displays this as 31/12/1999. I don't have Opera or OO to check there, but it's possible that the OP was using old versions of

Re: Arabic date format and Microsoft programs

Date: Mon, 17 Oct 2011 10:09:06 +0100 From: Peter Krefting pe...@opera.com Eli Zaretskii e...@gnu.org: However, it could be that the confusion is mine, and it stems from the fact that the logical order of these characters was not stated by the OP. Is it 1999/12/31 or

Re: Arabic date format and Microsoft programs

On Mon, 17 Oct 2011, Eli Zaretskii wrote: However, it could be that the confusion is mine, and it stems from the fact that the logical order of these characters was not stated by the OP. You can read the source text, no?

Re: Arabic date format and Microsoft programs

On Mon, 17 Oct 2011, Eli Zaretskii wrote: Btw, according to my testing, the current Firefox displays this this is http://www.unicode.org/mail-arch/unicode-ml/y2011-m10/att-0059/1999-12-31.html as 31/12/1999. Firefox 7 displays 1999/12/31.

Re: Arabic date format and Microsoft programs

Date: Mon, 17 Oct 2011 18:08:46 +0200 (CEST) From: Andreas Prilop prilop4...@trashmail.net List-software: Ecartis version 1.0.0 On Mon, 17 Oct 2011, Eli Zaretskii wrote: Btw, according to my testing, the current Firefox displays this this is

Re: Arabic date format and Microsoft programs

On Mon, 17 Oct 2011 05:57:33 +0200 Eli Zaretskii e...@gnu.org wrote: Date: Sun, 16 Oct 2011 22:47:08 +0100 From: Richard Wordingham richard.wording...@ntlworld.com List-software: Ecartis version 1.0.0 HTML 4.0 and 4.0.1 Section 8.2 Paragraph 3 Section 2 states, If a document does not

Re: Arabic date format and Microsoft programs

On Sat, 15 Oct 2011 17:19:29 +0200 (CEST) Andreas Prilop prilop4...@trashmail.net wrote: I return to http://www.unicode.org/mail-arch/unicode-ml/y2011-m10/att-0059/1999-12-31.html Microsoft programs (Internet Explorer, MS Word), display this as 31/12/1999 Other programs (Firefox,

Re: Arabic date format and Microsoft programs

Date: Sun, 16 Oct 2011 22:47:08 +0100 From: Richard Wordingham richard.wording...@ntlworld.com List-software: Ecartis version 1.0.0 HTML 4.0 and 4.0.1 Section 8.2 Paragraph 3 Section 2 states, If a document does not contain a displayable right-to-left character, a conforming user agent is

Arabic date format and Microsoft programs

I return to http://www.unicode.org/mail-arch/unicode-ml/y2011-m10/att-0059/1999-12-31.html Microsoft programs (Internet Explorer, MS Word), display this as 31/12/1999 Other programs (Firefox, Opera, OpenOffice) display this as 1999/12/31 NB: I do not ask how to write unambiguously. (This

RE: Designing a format for research use of the PUA in a RTL mode (from Re: RTL PUA?)

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

Designing a format for research use of the PUA in a RTL mode (from Re: RTL PUA?)

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

RE: Designing a format for research use of the PUA in a RTL mode (from Re: RTL PUA?)

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 files, or the XML equivalent, would be preferable to making one up: E100;ENGSVANYALI LETTER P;Lo;0;R

Re: Designing a format for research use of the PUA in a RTL mode (from Re: RTL PUA?)

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

RE: Designing a format for research use of the PUA in a RTL mode (from Re: RTL PUA?)

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

A binary file format for storing character properties

defined properties (including Unihan) makes small applications become rather big. This made me decide to create a binary file format for storing character properties and initialize property lookup tables on demand. Benefits of using run-time loadable lookup tables initialized from binary files

RE: unicode format

Carl W. Brown wrote: Are there any browsers that support Unicode but will not do endian flips for UTF-16? I usually use UTF-8 to send data between systems just to make sure. Internet Explorer for Mac OS 9 and OS X does not support UTF-16 at all. Development has stopped, so this will

unicode format

Hello, Could someone please clarify the difference between UTF8 and UFT16 please? If it is possible to encode everything in UTF8 and it is more efficient what is the need for UTF16? Thak you, Steve. Steve Bartwhistle Technology Director http://www.appliedlanguage.com Translation

Re: unicode format

steve scripsit: Could someone please clarify the difference between UTF8 and UFT16 please? If it is possible to encode everything in UTF8 and it is more efficient what is the need for UTF16? The short version is that in UTF-8, characters can occupy 1, 2, 3, or (very rarely) 4 bytes; in

Re: unicode format

John Cowan wrote: steve scripsit: Could someone please clarify the difference between UTF8 and UFT16 please? If it is possible to encode everything in UTF8 and it is more efficient what is the need for UTF16? It is more efficient to PROCESS in UTF16.

Re: unicode format

Message - From: John Cowan [EMAIL PROTECTED] To: steve [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Mon, 2004 Feb 23 04:50 Subject: Re: unicode format steve scripsit: Could someone please clarify the difference between UTF8 and UFT16 please? If it is possible to encode everything

RE: unicode format

: Re: unicode format It is important to distinguish two cases: (a) which UTF one should emit in web pages , (b) which UTF one should use for internal processing. There is a tech note about this at http://www.unicode.org/notes/tn12/ Mark __ http

Re: Windows and MacOS keyboard layouts in human-readable format?

a bunch of reasons why this was not a practical thing to want, so he should not be too disappointed when he did not find it (since by its very nature it would be incomplete). If there is interest in trying to develop a format and subsequently fill it, then that is great. But is it really a good idea

Re: Windows and MacOS keyboard layouts in human-readable format?

) Kaplan michka at trigeminal dot com responded: Such a format for Windows would be quite inadequate since it is missing many things, such as: I was sorry to see Adam's idea shot down so quickly, because it seemed like a pretty good thought to me, assuming the practical limitations are understood

Re: Windows and MacOS keyboard layouts in human-readable format?

this was not a practical thing to want, so he should not be too disappointed when he did not find it (since by its very nature it would be incomplete). Clearly, the success or failure of a project like this depends entirely on expectations. If there is interest in trying to develop a format

Re: Windows and MacOS keyboard layouts in human-readable format?

Michael, Peter, and others: Thank you for the responses. I agree with Michael that the simplistic approach I have envisioned would be rather incomplete -- I'm willing to accept that limitation. I am aware of many issues involving IMEs, chaining dead keys etc. I would be willing to leave them out

Re: Windows and MacOS keyboard layouts in human-readable format?

From: Adam Twardoch [EMAIL PROTECTED] I agree with Michael that the simplistic approach I have envisioned would be rather incomplete -- I'm willing to accept that limitation. I am aware of many issues involving IMEs, chaining dead keys etc. I would be willing to leave them out of the scope,

Windows and MacOS keyboard layouts in human-readable format?

Do you know if there are human-readable versions of Windows and/or MacOS keyboard layouts available somewhere? I'm looking for a way to compile a table that could look a bit like the following: Platform LanguageLayoutUnicodeKeystroke WindowsPolish Polish (Programmers)

Re: Windows and MacOS keyboard layouts in human-readable format?

Such a format for Windows would be quite inadequate since it is missing many things, such as: 1) The version of Windows in which it first shipped (there were minor differences in what was in 9x vs. NT, and on NT some characters were added to keyboards in later versions). 2) The fact that many

Re: Windows and MacOS keyboard layouts in human-readable format?

From: Michael (michka) Kaplan [EMAIL PROTECTED] To: Unicode List [EMAIL PROTECTED] Such a format for Windows would be quite inadequate since it is missing many things, such as: 1) The version of Windows in which it first shipped (there were minor differences in what was in 9x vs. NT

Re: Windows and MacOS keyboard layouts in human-readable format?

of a second AltGr modifier mapped onto an OEM key? Yes Or about the many dead keys it supports to enter accents used in various languages? No I could go on. but you get the idea. There is no simple list because there is no simple format that can describe them. Notably the complex

Re: Windows and MacOS keyboard layouts in human-readable format?

Mac OSX keyboard layouts can be defined in XML which is a close as we get to human readability - see http://developer.apple.com/technotes/tn2002/tn2056.html This format has been available for over a year, so there may be some published data files from 3rd Parties. Michael Everson is one

RE: TR: STD 63, RFC 3629 on UTF-8, a transformation format of ISO 106 46

Simon Josefsson wrote: Perhaps the Unicode.org webmasters could make sure one of the references in that document points to something useful? [1] http://www.unicode.org/unicode/standard/policies.html Oh rats! And how ironic that a pointer to the *stability* policy has proven unstable... I

TR: STD 63, RFC 3629 on UTF-8, a transformation format of ISO 106 46

... FYI. -Message d'origine- De: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: 10/11/2003 18:23 Objet: STD 63, RFC 3629 on UTF-8, a transformation format of ISO 10646 A new Request for Comments is now available in online RFC libraries. STD 63 RFC 3629 Title

Format A

On the Unicode Web site, cross-mapping tables between Unicode and other coded character sets (including the ISO 8859 series and vendor codes) are provided in a table format called Format A. 1. Is there a formal, or even semi-formal, specification of Format A that is publicly available? 2

Native font format

format? (What drove me to ask this question is that AFAIK, .ttf was designed for Apple Macintosh, then, I'd like to claim .ttf as a native font format of Mac, Can I?.) 2. Can I claim .bdf (bitmap distribution format of Adobe) as a native font format of Linux? And .pcf (Portable Compiled Format)? 3

Re: Native font format

At 00:35 7/28/2001 -0700, Myanmar Triumph Int'l Ltd. wrote: 1. In each and every OS Platform (such as Microsoft Win9x, Win2K, Mac, IBM OS2, Unix, Linux etc...), is there anything like native font format? Not as such. I think it would be fair to describe data fork TTFs as the Windows 9x, ME

Re: Native font format

From: Myanmar Triumph Int'l Ltd. [EMAIL PROTECTED] 1. In each and every OS Platform (such as Microsoft Win9x, Win2K, Mac, IBM OS2, Unix, Linux etc...), is there anything like native font format? That all depends what you mean by native font format. All of those can handle several font formats

Re: Native font format

are supported from 8.5 onwards in ATSUI. John Jenkins at Apple can probably provide more precise information. He may or may not want to burden you with knowledge of the esoteric .dfont format. He does not want to. -- = John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://homepage.mac.com

Re: UCS-2, UCS-4, UTF-16 unicode format files

ot; [EMAIL PROTECTED] To: "Unicode List" [EMAIL PROTECTED] Cc: "Sarasvati" [EMAIL PROTECTED] Sent: Friday, December 08, 2000 6:12 AM Subject: Re: UCS-2, UCS-4, UTF-16 unicode format files James Kass wrote: Try looking at the *.UNI files under the FIVE BOOKS directo

Re: UCS-2, UCS-4, UTF-16 unicode format files

James Kass wrote: John Cowan wrote of problems with the *.UNI files... This browser loads them just fine, but perhaps this is because I "associated" *.UNI files with the browser in the Windows file type configurations? Apparently your browser (IE? which version?) overrides the media type

Re: UCS-2, UCS-4, UTF-16 unicode format files

John Cowan wrote, Apparently your browser (IE? which version?) overrides the media type specified by the server, which is "text/html". MSIE 5.50.4134.0600 but it may not be actually overriding the media type, I should've said "the pages load" rather than "the pages load just fine", since

UCS-2, UCS-4, UTF-16 unicode format files

Hello, I am new to this mailing list. Hope it is appropriate to ask the following question : 1. Any browser that I can used to view UCS-2, UCS-4, UTF-16 unicode format files ? 2. I am looking for some UCS-2, UCS-4, UTF-16 unicode format file. Any web site which I can download the above files

.bdf file format

Hello, Can anybody on this list give me (or point me to) a documentation in which I can find the structure details of a .bdf file? The structure of the .bdf file itself is quite self explanatory but I feel unsatisfied to see around the existing optionsonly; Can I add or remove and/or

Swiss numerical format (war einmal: What is ` (U+0060) for?)

As an aside: Are there good (authorative) references on the so called swiss numerical format with its peculiar thousand separator? I only know about a manual shipped with some Aldus software product as a reference. I own several books printed in Switzerland and they show the typical swiss

RE: Swiss numerical format [OT]

Jörg Knappen wrote: Are there good (authorative) references on the so called swiss numerical format with its peculiar thousand separator? Why not comparing the locale settings of main operating systems? I think that at least WinNT, Apple, Linux, and other Unixes are widely represented

Re: Landmark name format

Sebastian Hagedorn wrote: 15 km SE of Montréal, Québec I am more interested in the structure that the actual character or language encoding here. Actually I think that in Germany you might not even specify the state, so that you would have only one level. You only specify the state

Re: Landmark name format

Antoine Leca wrote: And my girlfriend was to laugh loudly, because she cannot imagine Paris anywhere outside France. I am sure that every people in the U.S.A., on the other hand, certainly can imagine other places... A brief check turns up ten localities named "Paris" in the U.S., of which

Landmark name format

Could someone help me define how users in different countries would expect a geographic landmark's name to be displayed. If in Canada we would locate a vehicle/train/asset the following way : 15 km SE of Montreal, Quebec -- English 15 km SE de Montréal (Québec) -- French How would people

Re: Landmark name format

-- Patrick Andries [EMAIL PROTECTED] is rumored to have mumbled on Montag, 10. Juli 2000 10:06 Uhr -0800 regarding Landmark name format: Could someone help me define how users in different countries would expect a geographic landmark's name to be displayed. If in Canada we would locate