DOCSLIB.ORG

Would UTF-8 Be Able to Support the Inclusion of a Vast Alien Language with Millions of New Characters?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Would UTF-8 Be Able to Support the Inclusion of a Vast Alien Language with Millions of New Characters? _ Software Engineering Stack Exchange Here's how it works: is a question and answer site for professionals, academics, and students working within the systems development life cycle. Join them; it only takes a minute: Anybody can ask Anybody can The best answers are voted a question answer up and rise to the top Sign up Would UTF-8 be able to support the inclusion of a vast alien language with millions of new characters? In the event an alien invasion occurred and we were forced to support their languages in all of our existing computer systems, is UTF-8 designed in a way to allow for their possibly vast amount of characters? (Of course, we do not know if aliens actually have languages, if or how they communicate, but for the sake of the argument, please just imagine they do.) For instance, if their language consisted of millions of newfound glyphs, symbols, and/or combining characters, could UTF-8 theoretically be expanded in a non-breaking way to include these new glyphs and still support all existing software? I'm more interested in if the glyphs far outgrew the current size limitations and required more bytes to represent a single glyph. In the event UTF-8 could not be expanded, does that prove that the single advantage over UTF-32 is simply size of lower characters? unicode utf-8 edited May 23 '17 at 12:40 asked Nov 24 '15 at 12:18 Community ♦ Qix 1 722 9 28 15 "support their languages" (my emphasis)... How many? Are we sure the languages can be broken down to characters? Maybe the language is based on spatial relations. - see Ted Chiang "Story of Your Life", Stories of Your Life and Others. At best, this is simply a max-things-in-X-bytes question (off-topic). At worst, it's speculative nonsense. (not clear what you're asking) – Scant Roger Nov 24 '15 at 13:12 6 @ScantRoger The accepted answer does a fine job at answering the question as it was intended. – Qix Nov 24 '15 at 13:13 10 The accepted answer does a fine job of telling us the facts of UTF-8, UTF-16, and UTF-32. You could simply look this up on Wikipedia. As for "alien invasion", I don't see how the answer addresses it at all. – Scant Roger Nov 24 '15 at 13:17 10 Related (on Stack Overflow): Is UTF-8 enough for all common languages? – yannis ♦ Nov 24 '15 at 13:17 9 Unicode does not support languages, it supports characters - glyphs used to represent meaning in written form. Many human languages does not have a script and hence cannot be supported by unicode. Not to mention many animals communicate but don't have a written language. Communication by say illustrations or wordless comics cannot be supported by unicode since the set of glyphs are not finite. By definition we don't know how aliens communicate, so your question is impossible to answer. If you just want to know how many distinct characters unicode can support, you should probably clarify :) – JacquesB Nov 24 '15 at 16:41 5 Answers The Unicode standard has lots of space to spare. The Unicode codepoints are organized in “planes” and “blocks”. Of 17 total planes, there are 11 currently unassigned. Each plane holds 65,536 characters, so there's realistically half a million codepoints to spare for an alien language (unless we fill all of that up with more emoji before first contact). As of Unicode 8.0, only 120,737 code points have been assigned in total (roughly 10% of the total capacity), with roughly the same amount being unassigned but reserved for private, application-specific use. In total, 974,530 codepoints are unassigned. UTF-8 is a specific encoding of Unicode, and is currently limited to four octets (bytes) per code point, which matches the limitations of UTF-16. In particular, UTF-16 only supports 17 planes. Previously, UTF-8 supported 6 octets per codepoint, and was designed to support 32768 planes. In principle this 4 byte limit could be lifted, but that would break the current organization structure of Unicode, and would require UTF-16 to be phased out – unlikely to happen in the near future considering how entrenched it is in certain operating systems and programming languages. The only reason UTF-16 is still in common use is that it's an extension to the flawed UCS-2 encoding which only supported a single Unicode plane. It otherwise inherits undesirable properties from both UTF-8 (not fixed-width) and UTF-32 (not ASCII compatible, waste of space for common data), and requires byte order marks to declare endianness. Given that despite these problems UTF-16 is still popular, I'm not too optimistic that this is going to change by itself very soon. Hopefully, our new Alien Overlords will see this impediment to Their rule, and in Their wisdom banish UTF-16 from the face of the earth. edited Nov 24 '15 at 13:47 answered Nov 24 '15 at 12:48 amon 67.4k 16 124 210 7 Actually, UTF-8 is limited to only a part of even the 4-byte-limit, in order to match UTF-16. Specifically, to 17/32 of it, slightly more than half. – Deduplicator Nov 24 '15 at 15:19 5 Outside of Windows I know of no other OS where either the OS or the majority of programs on the OS use UTF16. OSX programs are typically UTF8, Android programs are typically UTF8, Linux are typically UTF8. So all we need is for Windows to die (it already is sort of dead in the mobile space) – slebetman Nov 25 '15 at 3:14 23 Unless we fill all of that up with more emoji before first contact... There you have it. The most significant threat to peaceful interaction with aliens is emoji. We're doomed. – rickster Nov 25 '15 at 6:03 13 @slebetman Not really. Anything JVM-based uses UTF-16 (Android as well, not sure why you say it doesn't), JavaScript uses UTF-16, and given that Java and JavaScript are the most popular languages, UTF-16 is not going anywhere anytime soon. – Malcolm Nov 25 '15 at 8:34 5 @Kaiserludi "Most linux code uses UTF32 for unicode", yeah, no. Seriously where the hell did you get that idea? There is not even a wfopen syscall or anything else, it's UTF8 all the way. Hell even Python and Java - both which define strings as UTF-16 due to historical reasons - do not store strings as UTF-16 except when necessary.. large memory benefits and no performance hits (and that despite the additional code to handle conversions - memory is expensive, CPU is cheap). Same goes for Android - the NDK's JString is UTF8, mostly because Google engineers are not insane. – Voo Nov 25 '15 at 22:19 If UTF-8 is actually to be extended, we should look at the absolute maximum it could represent. UTF-8 is structured like this: Char. number range | UTF-8 octet sequence (hexadecimal) | (binary) --------------------+--------------------------------------------- 0000 0000-0000 007F | 0xxxxxxx 0000 0080-0000 07FF | 110xxxxx 10xxxxxx 0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx (shamelessly copied from the RFC.) We see that the first byte always controls how many follow-up bytes make up the current character. If we extend it to allow up to 8 bytes we get the additional non-Unicode representations 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 11111111 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx Calculating the maximum possible representations that this technique allows we come to 10000000₂ + 00100000₂ * 01000000₂ + 00010000₂ * 01000000₂^2 + 00001000₂ * 01000000₂^3 + 00000100₂ * 01000000₂^4 + 00000010₂ * 01000000₂^5 + 00000001₂ * 01000000₂^6 + 00000001₂ * 01000000₂^7 or in base 10: 128 + 32 * 64 + 16 * 64^2 + 8 * 64^3 + 4 * 64^4 + 2 * 64^5 + 1 * 64^6 + 1 * 64^7 which gives us the maximum amount of representations as 4,468,982,745,216. So, if these 4 billion (or trillion, as you please) characters are enough to represent the alien languages I am quite positive that we can, with minimal effort, extend the current UTF-8 to please our new alien overlords ;-) edited Sep 20 '16 at 11:23 answered Nov 24 '15 at 16:21 Qix Boldewyn 722 9 28 417 3 7 3 They shall be pleased. Thank you for this! – Qix Nov 24 '15 at 16:23 8 Currently UTF-8 is limited to only code points until 0x10FFFF - but that is only for compatibility with UTF-16. If there was a need to extend it, there is no ambiguity about how to extend it with code points until 0x7FFFFFFF (that's 2³¹-1). But beyond that I have seen conflicting definitions. One definition I have seen has 111111xx as a possible first byte followed by five extension bytes for a maximum of 2³² code points. But that is only compatible with the definition you mention for the first 2³¹ code points. – kasperd Nov 24 '15 at 16:49 2 Yes, Wikipedia says something about UTF-16, when really they mean Unicode or ISO 10646 (depending on context). Actually, since RFC 3629, UTF-8 is undefined beyond U+10FFFF (or F4 8F BF BF in UTF-8 bytes). So, everything I mention here beyond that is pure speculation. Of course, someone could think of other extensions, where a high first byte signifies some other structure following (and hopefully not destroying self sync in the process).
Load more

Recommended publications
  • Unicode Nearly Plain-Text Encoding of Mathematics Murray Sargent III Office Authoring Services, Microsoft Corporation 4-Apr-06
    Unicode Nearly Plain Text Encoding of Mathematics Unicode Nearly Plain-Text Encoding of Mathematics Murray Sargent III Office Authoring Services, Microsoft Corporation 4-Apr-06 1. Introduction ............................................................................................................ 2 2. Encoding Simple Math Expressions ...................................................................... 3 2.1 Fractions .......................................................................................................... 4 2.2 Subscripts and Superscripts........................................................................... 6 2.3 Use of the Blank (Space) Character ............................................................... 7 3. Encoding Other Math Expressions ........................................................................ 8 3.1 Delimiters ........................................................................................................ 8 3.2 Literal Operators ........................................................................................... 10 3.3 Prescripts and Above/Below Scripts........................................................... 11 3.4 n-ary Operators ............................................................................................. 11 3.5 Mathematical Functions ............................................................................... 12 3.6 Square Roots and Radicals ........................................................................... 13 3.7 Enclosures.....................................................................................................
    [Show full text]
  • Using Lexical Tools to Convert Unicode Characters to ASCII
    Using Lexical Tools to Convert Unicode Characters to ASCII Chris J. Lu, Ph.D.1, Allen C. Browne2, Divita Guy1 1Lockheed Martin/MSD, Bethesda, MD; 2National Library of Medicine, Bethesda, MD Abstract 2-3. Recursive algorithm Some Unicode characters require multiple steps, combining Unicode is an industry standard allowing computers to the methods described above, in ASCII conversion. A consistently represent and manipulate text expressed in recursive algorithm is implemented in LVG flow, -f:q7, for most of the world’s writing systems. It is widely used in this purpose. multilingual NLP (natural language processing) projects. On the other hand, there are some NLP projects still only 2-4. Table lookup mapping and strip dealing with ASCII characters. This paper describes Some Unicode characters do not belong to categories methods of utilizing lexical tools to convert Unicode mentioned above. A local table of conversion values is characters (UTF-8) to ASCII (7-bit) characters. used to convert these to an ASCII representation. For example, Greek letters are converted into fully spelled out 1. Introduction forms. ‘α’ is converted to “alpha”. Non-defined Unicode The SPECIALIST Lexical tools, 2008, distributed by characters, (such as ™, ©, ®, etc.), are treated as National Library of Medicine (NLM) provide several stopwords and stripped out completely to ensure pure functions, called LVG (Lexical Variant Generation) flow ASCII conversion. This table lookup and strip function is components, to convert Unicode characters to ASCII. In represented by LVG flow, -f:q8. general, ASCII conversion either preserves semantic and/or 2-5. Pure ASCII conversions graphic representation or facilitates NLP.
    [Show full text]
  • L2/20-136 Reference: Action: for Consideration by JTC1/SC2 Date: Apri 29, 2020
    Doc Type: Liaison Contribution Title: Comments on and proposed response to SC2 N4710, LS on Unicode symbol numbers representing disasters Status: Circulated for information Source: Unicode Consortium Source L2/20-136 reference: Action: For consideration by JTC1/SC2 Date: Apri 29, 2020 In N4710, 3GPP/CT1 requests action from JTC1/SC2 to respond to the following questions: • Question 1. 3GPP CT WG1 would like to ask ISO/IEC JTC1/SC2 to provide what Unicode symbols defined in ISO/IEC 10646 are possible to be recommended as language-independent contents such as pictograms mapping to disasters (earthquake, tsunami, fire, flood, typhoon, hurricane, cyclone, tornado, volcanic eruption, epidemic and chemical hazard) that can be compatible with Unicode-based texts and can be included in public warning message. • Question 2. If there are no proper Unicode symbols recommendable for the ePWS purpose to address the language issue existed in text-based warning messages in ISO/IEC 10646, 3GPP CT WG1 would like to request ISO/IEC JTC1/SC2 the standardization of Unicode-based language- independent contents representing earthquake, tsunami, fire, flood, typhoon, hurricane, cyclone, tornado, volcanic eruption, epidemic and chemical hazard. In short, this is a request for SC2 to devise a system of pictographic symbols for a particular application, and to include characters for these pictographs in the UCS (ISO/IEC 10646). The background given for this request is that 3GPP/CT1 is working on improvement to a text-based public warning service used in 5G communications (PWS) and would like to provide language-neutral symbols for public communication in disaster scenarios.
    [Show full text]
  • UTR #25: Unicode and Mathematics
    UTR #25: Unicode and Mathematics http://www.unicode.org/reports/tr25/tr25-5.html Technical Reports Draft Unicode Technical Report #25 UNICODE SUPPORT FOR MATHEMATICS Version 1.0 Authors Barbara Beeton ([email protected]), Asmus Freytag ([email protected]), Murray Sargent III ([email protected]) Date 2002-05-08 This Version http://www.unicode.org/unicode/reports/tr25/tr25-5.html Previous Version http://www.unicode.org/unicode/reports/tr25/tr25-4.html Latest Version http://www.unicode.org/unicode/reports/tr25 Tracking Number 5 Summary Starting with version 3.2, Unicode includes virtually all of the standard characters used in mathematics. This set supports a variety of math applications on computers, including document presentation languages like TeX, math markup languages like MathML, computer algebra languages like OpenMath, internal representations of mathematics in systems like Mathematica and MathCAD, computer programs, and plain text. This technical report describes the Unicode mathematics character groups and gives some of their default math properties. Status This document has been approved by the Unicode Technical Committee for public review as a Draft Unicode Technical Report. Publication does not imply endorsement by the Unicode Consortium. This is a draft document which may be updated, replaced, or superseded by other documents at any time. This is not a stable document; it is inappropriate to cite this document as other than a work in progress. Please send comments to the authors. A list of current Unicode Technical Reports is found on http://www.unicode.org/unicode/reports/. For more information about versions of the Unicode Standard, see http://www.unicode.org/unicode/standard/versions/.
    [Show full text]
  • Proposal for Addition of Group Mark Symbol Introduction
    Proposal for addition of Group Mark symbol Ken Shirriff github.com/shirriff/groupmark Feb 14, 2015 Abstract The group mark symbol was part of the character set of important computers of the 1960s and 1970s, such as the IBM 705, 7070, 1401 and 1620. Books about these computers and manuals for them used the symbol to represent the group mark in running text. Unfortunately, this symbol does not exist in Unicode, making it difficult to write about technical details of these historical computers. Introduction The group mark was introduced in the 1950s as a separator character for I/O operations. In written text, the group mark is indicated by the symbol: . Unicode doesn't include this symbol, which is inconvenient when writing about the group mark or the character set of these computers. The group mark became part of IBM's Standard BCD Interchange Code (BCDIC) in 1962. [1, page 20 and figure 56]. This standard was used by the IBM 1401, 1440, 1410, 1460, 7010, 7040, and 7044 data processing systems [2]. The BCDIC standard provided consistent definitions of codes and the relation between these codes and printed symbols, including uniform graphics for publications.[2, page A-2]. Unicode can represent all the characters in BCDIC, except for the group mark. This proposal is for a Unicode code point for the group mark for use in running text with an associated glyph . This is orthogonal to the use of the group mark as a separator in data files. While the proposed group mark could be used in data files, that is not the focus of this proposal.
    [Show full text]
  • Unicode Nearly Plain Text Encoding of Mathematics
    Unicode Nearly Plain Text Encoding of Mathematics Unicode Nearly Plain-Text Encoding of Mathematics Murray Sargent III Office Authoring Services, Microsoft Corporation 28-Aug-06 1. Introduction ............................................................................................................ 2 2. Encoding Simple Math Expressions ...................................................................... 3 2.1 Fractions .......................................................................................................... 4 2.2 Subscripts and Superscripts........................................................................... 6 2.3 Use of the Blank (Space) Character ............................................................... 7 3. Encoding Other Math Expressions ........................................................................ 8 3.1 Delimiters ........................................................................................................ 8 3.2 Literal Operators ........................................................................................... 10 3.3 Prescripts and Above/Below Scripts .......................................................... 11 3.4 n-ary Operators ............................................................................................. 11 3.5 Mathematical Functions ............................................................................... 12 3.6 Square Roots and Radicals ........................................................................... 13 3.7 Enclosures ....................................................................................................
    [Show full text]
  • A Proposed Set of Mnemonic Symbolic Glyphs for the Visual Representation of C0 Controls and Other Nonprintable ASCII Characters Michael P
    Michael P. Frank My-ASCII-Glyphs-v2.3.doc 9/14/06 A Proposed Set of Mnemonic Symbolic Glyphs for the Visual Representation of C0 Controls and Other Nonprintable ASCII Characters Michael P. Frank FAMU-FSU College of Engineering Thursday, September 14, 2006 Abstract. In this document, we propose some single-character mnemonic, symbolic representations of the nonprintable ASCII characters based on Unicode characters that are present in widely-available fonts. The symbols chosen here are intended to be evocative of the originally intended meaning of the corresponding ASCII character, or, in some cases, a widespread de facto present meaning. In many cases, the control pictures that we suggest are similar to those specified in ANSI X3.32/ISO 2047, which has not been uniformly conformed to for representing the control codes in all of the widely available Unicode fonts. In some cases, we suggest alternative glyphs that we believe are more intuitive than ISO 2047’s choices. 1. Introduction The most current official standard specification defining the 7-bit ASCII character set is ANSI X3.4-1986, presently distributed as ANSI/INCITS 4-1986 (R2002). This character set includes 34 characters that have no visible, non-blank graphical representation, namely the 33 control characters (codes 00 16 -1F 16 and 7F 16 ) and the space character (code 20 16 ). In some situations, for readability and compactness, it may be desired to display or print concise graphic symbolic representations of these characters, consisting of only a single glyph per character, rather than a multi-character character sequence. According to ANSI X3.4-1986, graphic representations of control characters may be found in American National Standard Graphic Representation of the Control Characters of American National Standard Code for Information Interchange , ANSI X3.32-1973.
    [Show full text]
  • Unicode Characters in Proofpower Through Lualatex
    Unicode Characters in ProofPower through Lualatex Roger Bishop Jones Abstract This document serves to establish what characters render like in utf8 ProofPower documents prepared using lualatex. Created 2019 http://www.rbjones.com/rbjpub/pp/doc/t055.pdf © Roger Bishop Jones; Licenced under Gnu LGPL Contents 1 Prelude 2 2 Changes 2 2.1 Recent Changes .......................................... 2 2.2 Changes Under Consideration ................................... 2 2.3 Issues ............................................... 2 3 Introduction 3 4 Mathematical operators and symbols in Unicode 3 5 Dedicated blocks 3 5.1 Mathematical Operators block .................................. 3 5.2 Supplemental Mathematical Operators block ........................... 4 5.3 Mathematical Alphanumeric Symbols block ........................... 4 5.4 Letterlike Symbols block ..................................... 6 5.5 Miscellaneous Mathematical Symbols-A block .......................... 7 5.6 Miscellaneous Mathematical Symbols-B block .......................... 7 5.7 Miscellaneous Technical block .................................. 7 5.8 Geometric Shapes block ...................................... 8 5.9 Miscellaneous Symbols and Arrows block ............................. 9 5.10 Arrows block ........................................... 9 5.11 Supplemental Arrows-A block .................................. 10 5.12 Supplemental Arrows-B block ................................... 10 5.13 Combining Diacritical Marks for Symbols block ......................... 11 5.14
    [Show full text]
  • Unicodemath a Nearly Plain-Text Encoding of Mathematics Version 3.1 Murray Sargent III Microsoft Corporation 16-Nov-16
    Unicode Nearly Plain Text Encoding of Mathematics UnicodeMath A Nearly Plain-Text Encoding of Mathematics Version 3.1 Murray Sargent III Microsoft Corporation 16-Nov-16 1. Introduction ............................................................................................................ 2 2. Encoding Simple Math Expressions ...................................................................... 3 2.1 Fractions .......................................................................................................... 4 2.2 Subscripts and Superscripts........................................................................... 6 2.3 Use of the Blank (Space) Character ............................................................... 8 3. Encoding Other Math Expressions ........................................................................ 8 3.1 Delimiters ........................................................................................................ 8 3.2 Literal Operators ........................................................................................... 11 3.3 Prescripts and Above/Below Scripts ........................................................... 11 3.4 n-ary Operators ............................................................................................. 12 3.5 Mathematical Functions ............................................................................... 13 3.6 Square Roots and Radicals ........................................................................... 14 3.7 Enclosures ....................................................................................................
    [Show full text]
  • Glossary of Mathematical Symbols
    Glossary of mathematical symbols A mathematical symbol is a figure or a combination of figures that is used to represent a mathematical object, an action on mathematical objects, a relation between mathematical objects, or for structuring the other symbols that occur in a formula. As formulas are entirely constituted with symbols of various types, many symbols are needed for expressing all mathematics. The most basic symbols are the decimal digits (0, 1, 2, 3, 4, 5, 6, 7, 8, 9), and the letters of the Latin alphabet. The decimal digits are used for representing numbers through the Hindu–Arabic numeral system. Historically, upper-case letters were used for representing points in geometry, and lower-case letters were used for variables and constants. Letters are used for representing many other sort of mathematical objects. As the number of these sorts has dramatically increased in modern mathematics, the Greek alphabet and some Hebrew letters are also used. In mathematical formulas, the standard typeface is italic type for Latin letters and lower-case Greek letters, and upright type for upper case Greek letters. For having more symbols, other typefaces are also used, mainly boldface , script typeface (the lower-case script face is rarely used because of the possible confusion with the standard face), German fraktur , and blackboard bold (the other letters are rarely used in this face, or their use is unconventional). The use of Latin and Greek letters as symbols for denoting mathematical objects is not described in this article. For such uses, see Variable (mathematics) and List of mathematical constants. However, some symbols that are described here have the same shape as the letter from which they are derived, such as and .
    [Show full text]
  • A Modular Architecture for Unicode Text Compression
    A modular architecture for Unicode text compression Adam Gleave St John’s College A dissertation submitted to the University of Cambridge in partial fulfilment of the requirements for the degree of Master of Philosophy in Advanced Computer Science University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom Email: [email protected] 22nd July 2016 Declaration I Adam Gleave of St John’s College, being a candidate for the M.Phil in Advanced Computer Science, hereby declare that this report and the work described in it are my own work, unaided except as may be specified below, and that the report does not contain material that has already been used to any substantial extent for a comparable purpose. Total word count: 11503 Signed: Date: This dissertation is copyright c 2016 Adam Gleave. All trademarks used in this dissertation are hereby acknowledged. Acknowledgements I would like to thank Dr. Christian Steinruecken for his invaluable advice and encouragement throughout the project. I am also grateful to Prof. Zoubin Ghahramani for his guidance and suggestions for extensions to this work. I would further like to thank Olivia Wiles and Shashwat Silas for their comments on drafts of this dissertation. I would also like to express my gratitude to Maria Lomelí García for a fruitful discussion on the relationship between several stochastic processes considered in this dissertation. Abstract Conventional compressors operate on single bytes. This works well on ASCII text, where each character is one byte. However, it fares poorly on UTF-8 texts, where characters can span multiple bytes.
    [Show full text]
  • Best Practice When Using Non-Alphabetic Characters in Orthographies: Helping Languages Succeed in the Modern World
    Best practice when using non-alphabetic characters in orthographies: Helping languages succeed in the modern world May 4, 2018 1. Why this document? 2. Word-forming characteristics of a symbol used for tone 3. Altering software programs 4. Linguistic and readability issues 5. Technical recommendations for selecting symbols 5.1. Word-forming characters 5.2. Non-word-forming characters 5.3. Adding characters to Unicode 6. Some specific uses of common symbols Hyphen Apostrophe Asterisk 7. Case Studies Case Study #1: Hyphens Case Study #2: Can you change the program for me? Case Study #3: A successful Unicode proposal, but... Case Study #4: Paratext remarks APPENDIX A: List of non-alphabetic symbols APPENDIX B: “Text Engineering” requirements REFERENCES (and useful Links) 1. Why this document? The goal of this document is to suggest best practices for using non-alphabetic symbols in Roman (Latin) script orthographies, for tone and other functions. We especially want to assist people dealing with marking grammatical tone, though others using non-alphabetical symbols such as apostrophes will find this helpful as well. “Best practices” here involves making orthographies as easy as possible for the user and enabling the orthography to be used as widely as possible on today's computers and mobile devices. Linguistic and sociopolitical factors are vital in orthography, but this paper focuses on the need to be compliant with Unicode so orthographies can be used on modern devices. An orthography that ignores such standards risks problems in text interchanges, and may end up being marginalized by the world at large. These are the Best Practices that are expounded throughout this paper.
    [Show full text]