W3C Unicode

Unicode in XML and other Markup Languages

Unicode Technical Report #20

W3C Working Draft XX-XXXX-2000

Revision (Unicode):
This version:
Latest version:
Previous version:
Date (Unicode):
Martin Dürst (duerst@w3.org) and Asmus Freytag (asmus@unicode.org)


This document contains guidelines on the use of the Unicode Standard Version 3.0 in conjunction with markup languages such as XML.

Status of this document (Unicode Consortium)


[SInce this is a joint document, this TR will be published as soon as W3C approves its version and any resulting editorial issues have been resolved in committee].

This draft is published for review purposes. This draft has been considered by the Unicode Technical Committee and approved as draft for public review. At its next meeting, the Unicode Technical Committee may approve, reject, or further amend this document. This document is a joint Unicode - W3C document.

The content of technical reports must be understood in the context of the latest version of the Unicode Standard. See http://www.unicode.org/unicode/standard/versions/ for more information.

This document does not, at this time, imply any endorsement by the Consortium's staff or member organizations. Please mail comments to unicore@unicode.org.

Status of this document (W3C)

 [This section needs updating by W3C since it's not final. It's also not correct, and conflicts with section 5].

This is a W3C Working Draft worked on jointly by the W3C Internationalization Working Group/Interest Group (Members only) in the context of the W3C Internationalization Activity and by the Unicode Technical Committee. For public discussion of this working draft, please use the mailing lists www-international@w3.org and unicode@unicode.org (please cross post to both lists). In order to post to unicode@unicode.org, you must join the list by following the simple instructions on http://www.unicode.org/unicode/consortium/distlist.html. For internal discussions, please use the relevant mailing list (again with cross posting). Please send editorial comments to the authors.

The material in this draft now covers all affected characters in the Unicode Standard, Version 3.0. Some of the detailed recommendations need additional discussion, and the descriptions may need additional clarification in some instances. It is not exactly clear yet how this document will be related to other W3C specifications. One potential way to proceed is to work towards publishing this document as a Note, and to reference it, normatively or otherwise, from the Character Model [CharMod] document.

Publication as a Working Draft does not imply endorsement by the W3C membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite W3C Drafts as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR/.

Table of Contents

  1. Introduction
  2. General Considerations
  3. List of Characters
  4. Characters with compatibility mappings
  5. Versioning
  6. Conformance
  7. References
  8. Acknowledgements
  9. Change History
  10. Copyright

1. Introduction

The Unicode Standard  [Unicode] is the universal character set. Its primary goal is to provide an unambiguous encoding of the content of plain text, ultimately covering all languages in the world. Currently in its third major version, Unicode contains a large number of characters covering most of the currently used scripts in the world. It also contains additional characters for interoperability with older character encodings, and characters with control-like functions included primarily for reasons of providing unambiguous interpretation of plain text. Unicode provides specifications for use of all of these characters.

For document and data interchange, the Internet and the World Wide Web are more and more making use of marked-up text such as HTML and XML. In many instances, markup provides the same, or essentially similar features to those provided by format characters in the Unicode Standard for use in plain text. Another special character category provided by Unicode are compatibility characters. While there may be valid reasons to support these characters and their specifications in plain text, their use in marked-up text can conflict with the rules of the markup language. Formatting characters are discussed in chapters 2 and 3, compatibility characters in chapter 4.

The issues of using Unicode characters with marked-up text depend to some degree on the rules of the markup language in question and the set of elements it contains. In a narrow sense, this document concerns itself only with XML, and to some extent HTML. However, much of the general information presented here should be useful in a broader context, including some page layout languages.

1.1 Notation

This report uses XML [XML] as a prominent and general example of markup. The XML namespace notation [Namespace] is used to indicate that a certain element is taken from a specific markup language. As an example, the prefix 'html:' indicates that this element is taken from [XHTML]. This means that the examples containing the namespace prefix 'html:' are assumed to include a namespace declaration of xmlns:html="..." 

Characters are denoted using the notation used in the Unicode Standard, i.e. U+ followed by their hexadecimal number, using at least 4 digits, such as "U+1234" or "U+10FFFD". In XML or HTML this could be expressed as "ሴ" or "􏿽". 

2. General Considerations

There are several general points to consider when looking at the interaction between character encoding and markup. 

2.1 Linearity versus Structure

Encoding text as a sequence of characters without further information leads to a linear sequence, commonly called plain text. Character follows character, without any particular structure. Markup, on the other hand, defines a hierarchical structure for the text or data. In the case of XML and most other, similar markup languages, the markup defines a tree structure. While this tree structure is linearized for transmission in the XML document, once the document has been parsed, the tree is available directly.

Operations that are easy to perform on trees are often difficult to perform on linear sequences and vice versa. By separating functionality between character encoding and markup appropriately, the architecture becomes simpler, more powerful and longer-lasting.

In particular, operations on hierarchical structures can easily make sure that information is kept in context. Attributes assigned to parts of a document are moved together with the associated part of the document. Assigning an attribute to a part of a document limits the scope of the attribute to that part of the document. Performing the same operations on linear sequences of characters using control codes to set attributes and to delimit their scope requires much more work and is error prone. Locating the start or end of a span of text of the same attribute requires scanning backwards and forwards for the embedded delimiter or control code. Moving or editing text often results in mismatched control codes, so that an attribute might suddenly apply to text it was not intended for.

2.2 Overlap of Control Code and Markup Semantics

When markup is not available, plain text may require control characters. This is usually the case where plain text must contain some scoping or attribute information in order to be legible, i.e. to be able to transmit the same content between originator and receiver. Many of these control characters have direct equivalents in particular markup languages, since markup handles these concerns efficiently. If both characters and their markup equivalents may be present in the same text, the question of priority is raised: Which of the settings has priority and in which case? Therefore it is important to identify and resolve these ambiguities at the time markup is first applied.

2.3 Markup and Styling

Besides the basic character encoding and text markup there is a third contributor to text functionality, namely styling. Markup is concerned with the logical structure of the text or data, e.g. to indicate sections, subsections, and headers in a document, or to indicate the various fields of an address record. Styling is used to present the information in various ways, e.g. in different fonts, different type styles (italic, bold), different colors, etc.. Some character codes do not encode a generic character, but a styled character. Where these characters are used, styling information is frozen, i.e. it is no longer possible to alter the appearance of the text by applying style information. However, there are many examples where a historically free stylistic variation has over time become a semantic distinction that is properly encoded as plain text. In such instances, altering the appearance of the text by styling information would irreparably alter the content of the text.

2.4 Coincidence of Markup and Functions

Dealing with various functionalities on the markup level has the additional advantage that in most cases, text portions that need some particular attribute (or styling) are actually those text portions identified by markup. A paragraph may be in French, a citation may need a bidi embedding, a keyword may be in italics, a list number may be circled, etc.. This makes it very efficient to associate those attributes with markup.

2.5 Extensibility of Markup

Character encoding works with a range of integers used as character codes. This is extremely efficient, but has some limitations. Markup on the other hand, is much more extensible. Using technologies such as [Namespace] various vocabularies can be mixed. This is important for functionality that depends on complex context.

2.6 Local Context

Where local, or point-like context is required, markup is not very efficient and its main benefit, easy manipulation of scope, is not required. On the contrary, the intrusion of markup in the middle of words can make search or sort operations more difficult. For these cases expressing the information as character codes is not only a viable, but often the preferred alternative, which needs to be considered in the design of markup languages.

3. List of Characters

3.1 List of discouraged characters

There are characters whose use in the context of markup in XML/HTML should be considered discouraged, because one or more of the following conditions apply:

The following table contains the characters currently considered not suitable for use with markup in XML/HTML. They may also be unsuitable for other markup or page layout languages. 

Table 3.1 Characters not suitable for use with markup



Short Comment

U+2028 .. U+2029 Line and paragraph separator use <html:br />, <html:p></html:p>, or equivalent
U+202A .. U+202E BIDI embedding controls 
Strongly discouraged in [HTML 4.0];
U+206A .. U+206B Activate/Inhibit Symmetric swapping Deprecated  in Unicode 3.0
U+206C .. U+206D Activate/Inhibit Arabic form shaping Deprecated in Unicode 3.0
U+206E .. U+206F Activate/Inhibit National digit shapes Deprecated in Unicode 3.0
U+FFF9 .. U+FFFB Interlinear annotation characters Use ruby markup [Ruby]
U+FFFC Object replacement character Use markup, e.g. HTML <object> or HTML <img>
U+E0000 .. U+E007F Language Tag codepoints 
(not part of Unicode 3.0)
Use html:lang or xml:lang

Sections 3.3 through 3.7 discuss in more detail the following points for the characters in table 3.1:

Except for Line and Paragraph Separator and the characters in table 3.2 it is always acceptable for user agents to ignore the presence of discouraged characters in HTML or XML. It is up to authoring tools to ensure proper conversion between these characters and equivalent markup where it exists. 

These recommendations use markup available in HTML. For XML, the character can be replaced if the DTD permits. However if the DTD and or schema does not contain equivalent markup, there is no conflict preventing the use of this character. (also in 4.1)

3.2 List of format characters suitable for use with markup

The following table contains characters, that despite their apparent relation to characters in table 3.1, are currently considered suitable for use with markup. 

Table 3.2: Some characters that affect text format but are suitable for use with markup

Code points


Short Comment

U+00A0 No-break space In Latin-1
U+00AD Soft Hyphen In Latin-1
U+070C Syriac Abbreviation Mark (SAM)  
U+0F0C Tibetan tsheg mark  
U+180B..U+180E Mongolian Variant Selectors(FVS1.. FVS3, MVS) Required for Mongolian
U+200C..U+200D Zero-width Joiners (ZWJ and ZWNJ) Required for Persian
U+200E..U+200F Implicit directional marks (LRM and RLM) LRM and RLM are allowed
U+2011 Non breaking Hyphen  
U+202F Narrow No-break Space  
U+2FF0..U+2FFB Ideographic character description graphic characters (not controls)
U+303E Ideographic variation indicator graphic character (not a control)

3.3 Line and Paragraph Separator, U+2028..U+2029

Short description: The line and paragraph separator provide unambiguous means to denote hard line breaks and paragraph delimiters in plain text.

Reason for inclusion: These characters were introduced into the Unicode Standard to overcome the ambiguous and widely divergent use of control codes for this purpose. See Unicode Technical Report #13, Unicode Newline Guidelines [UTR13].

Problems when used in markup: Including these characters in markup text does not work where it would duplicate the existing markup commands for delimiting paragraphs and lines.

Problems with other uses: The separator characters can also problematic when used in plain text, because legacy data is usually converted code point for code point into Unicode and all receivers of Unicode plain text have to effectively be able to interpret the existing use of control codes for this purpose. As a result, fewer Unicode implementations support these characters, than would be the case otherwise.

Replacement markup: In HTML, use <html:br /> instead of U+2028 and surround paragraphs by <html:p> and </html:p> instead of separating them with U+2029.

What to do if detected: In a browser context, treat as whitespace. When received in an editing context, replace the character by the corresponding markup. 

3.4 BIDI embedding controls (LRE, RLE, LRO, RLO, PDF), U+202A .. U+202E

Short description: The BIDI embedding controls are required to supplement the Unicode Bidirectional Algorithm in plain text

Reason for inclusion: The Unicode Bidirectional algorithm unambiguously resolves the display direction for bidirectional text. It does so by assigning all characters directional categories and then resolving these in context. In a small number of circumstances this implicit  method does not produce satisfactory results and embedding controls are needed to ensure that sender and receiver agree on the display direction for a given text. See Unicode Technical Report # 9, The Bidirectional Algorithm [UTR 9].

Problems when used in markup: These characters duplicate available markup, which is better suited to handle the stateful nature of their effect. 

Problems with other uses: The embedding controls introduce a state into the plain text, which must be maintained when editing or displaying the text. Processes that are modifying the text without being aware of this state may inadvertently affect the rendering of large portions of the text, for example by removing a PDF.

Replacement markup: The following table gives the replacement markup:

Unicode Equivalent markup Comment


<BDO dir = "RTL">  


<BDO dir = "LTR">  
PDF </BDO> when used to terminate RLO or LRO only, otherwise ignore
RLE dir = "rtl" attribute on block or inline element
LRE dir = "ltr" attribute on block or inline element

For details on bidi markup, please see Section 8.2 of HTML [HMTL 4.0-8.2]. The text of HTML 4.0 gives this recommendation: 

Using HTML directionality markup with Unicode characters. Authors and designers of authoring software should be aware that conflicts can arise if the dir attribute is used on inline elements (including BDO) concurrently with the corresponding [UNICODE] formatting characters. Preferably one or the other should be used exclusively. The markup method offers a better guarantee of document structural integrity and alleviates some problems when editing bidirectional HTML text with a simple text editor, but some software may be more apt at using the [UNICODE] characters. If both methods are used, great care should be exercised to insure proper nesting of markup and directional embedding or override, otherwise, rendering results are undefined.

This document goes beyond HTML and recommends that only the markup should be used.

What to do if detected: In a browser context, ignore. When received in an editing context, replace the characters by the appropriate markup. 

3.5 Deprecated Formatting Characters, U+206A..U+206F

Short description: These characters are deprecated. They were originally intended to allow explicit activation of contextual shaping, numeric digit rendering and symmetric swapping.

Reason for inclusion: These characters were retained from draft versions of ISO 10646.

Problems when used in markup: The processing model for these characters is not supported in markup.

Problems with other uses: The Unicode Standard requires that symmetric swapping, contextual shaping and alternate digit shapes are enabled by default and no longer supports inhibiting any of them by use of these character codes. The most likely effect of their occurrence in generated text would be that of a 'garbage' character.

Conversion for use with markup: Apply the appropriate conversion to bring the data stream in line with the Unicode text model for bidirectional text and cursively-connected scripts.

What to do if detected: When received by a browser as part of marked up text, they may be ignored. When received in an editing context, they may be removed, possibly with a warning. Alternatively, an appropriate conversion from the legacy text model may be provided. This will most likely be limited to applications directly interfacing with and knowledgeable of the particular legacy implementation that inspired these characters.

3.6 Interlinear Annotation Characters, U+FFF9-U+FFFB

Short description: The interlinear annotation characters are used to delimit interlinear annotations in certain circumstances. They are intended to provide text anchors and delimiters for interlinear annotation for in-process use and are not intended for interchange.

Reason for inclusion: The interlinear annotation characters were included in Unicode only in order to reserve code points for very frequent application-internal use. The interlinear annotation characters are used to delimit interlinear annotations in contexts where other delimiters are not available, and where non-textual means exist to carry formatting information. Many text-processing applications store the text and the associated markup (or in some cases styling information) of a document in separate structures. The actual text is kept in a single linear structure; additional information is kept separately with pointers to the appropriate text positions. This is called out-of-band information. The overall implementation makes sure that these two structures are kept in sync. If the text contains interlinear annotations, it is extremely helpful for implementations to have delimiters in the text itself; even though delimiters are not otherwise used for style markup. With this method, and unlike the case of the object replacement character, all textual information can remain in the standard text stream, but any additional formatting information is kept separately. In addition, the Interlinear Annotation Anchor serves as a placeholder for formatting information for the whole annotation object, the same way a paragraph mark can be a placeholder to attach paragraph formatting information.

Problems when used in markup: Including interlinear annotation characters in marked-up text does not work because the additional formatting information (how to position the annotation,...) is not available.

Problems with other uses: The interlinear annotation characters are also problematic when used in plain text, and are not intended for that purpose. In particular, on older display systems that simply ignore or replace the Interlinear Annotation Characters, the meaning of the text may be changed.

Replacement markup: The markup to be used in place of the Interlinear Annotation Characters depends on the formatting and nature of the interlinear annotation in question. For ruby, please see [Ruby].

What to do if detected:  When received by a browser as part of marked-up text, they may be ignored. When receiving plain text in an editing environment, editor may take one or more of several actions: remove U+FFF9 together with removing all characters between U+FFFA and following U+FFFB,  ignore U+FFF9 and turn U+FFFA and U+FFFB  to "[" and "]" respectively, issue a warning to the user, or tentatively convert into appropriate ruby markup for further editing and formatting by the user.

3.7 Object Replacement Character, U+FFFC

Short description: The object replacement character is used to stand in place of an object (e.g. an image) included in a text.

Reason for inclusion: The object replacement character was included in Unicode only in order to reserve a codepoint for a very frequent application-internal use. Many text-processing applications store the text and the associated markup (or in some cases styling information) of a document in separate structures. The actual text is kept in a single linear structure; additional information is kept separately with pointers to the appropriate text positions. The overall implementation makes sure that these two structures are kept in sync. If the text contains objects such as images, it is extremely helpful for implementations to have a sentinel in the text itself; any additional information is kept separately.

Problems when used in markup: Including an object replacement character in markup text does not work because the additional information (what object to include,...) is not available.

Problems with other uses: The object replacement character is also problematic when used in plain text, because there is no way in plain text to provide the actual object information or a reference to it.

Replacement markup: The markup to be used in place of the Object Replacement Character depends on the object in question and the markup context it is used in. Typical cases are <html:img src'...' />, <html:object ...>, or <html:applet ...>. These constructs allow providing all additional information needed to identify and use the object in question.

What to do if detected: Browsers may ignore this character. When received in an editing context, if the actual object is accessible, editors may either replace the character by the appropriate markup for that object, or otherwise remove it, ideally providing a warning.

3.8 Language Tag Characters

Short description: A series of characters from U+E0000 .. U+E007F that can be used to express language tags, based on existing standards for language tags using the rules in [UTR7].

Reason for inclusion: These characters allow in-band language tagging in situations where full markup is not available, while allowing easy filtering by applications that do not support them. They were specifically included for the benefit of Internet protocols such as ACAP, which require a standard mechanism for marking language in UTF-8 strings and to avoid the use of other schemes that relied on specific details of the encoding form used.

Problems when used in markup: These characters duplicate information that can be expressed in markup.

Problems with other uses: Their special code range allows them to be easily filtered, but applications that don't expect them will treat them as garbage characters.

Replacement markup: Replace with equivalent language markup <html:lang>

What to do if detected: Browsers may ignore these characters. When received in an editing context, editors may remove and/or replace them by equivalent markup.

4. Characters with compatibility mappings

The Unicode Standard provides compatibility mappings for a number of characters. Compatibility mappings indicate a relationship to another character, but the exact nature of the relationship varies. In some cases the relationship means "is based on" in some other cases it denotes a property. When plain text is marked up, it may make sense to map some of these characters to their compatibility equivalents and suitable markup. It is important to understand the nature of the distinctions between characters and their compatibility equivalents and the context in where these distinctions matter. It is never advisable to apply compatibility mappings indiscriminately. This section provides guidance on when and how to apply compatibility mappings. It is organized by the "compatibility tag" associated with each compatibility mapping.

4.1 Overview

The following table gives an overview of the various compatibility characters, organized by "compatibility tag". The first column contains the tag value of the "compatibility tag" from the Unicode database. Although these tags use "<" and ">", they should not be confused with XML tags. Code range indicates which code points the entry applies to. The entry in the Action column summarizes whether the characters should be retained, can be substituted using the compatibility equivalent according to Normalization Form KC of [UTR 15], or be replaced by equivalent markup where available. For some cases, instead of or in addition to markup, style information [CSS2] is needed. Description and usage provides additional information. Sections 4.3 through 4.6 provide additional information for some of these sets of compatibility characters including detailed recommended actions.


Table 4.1 Characters with compatibility mappings

Tag value Code range Action Description  and usage
<circled> all retain Circled letters and digits used for list item markers
<compat> 2100-2101 retain Variant letter forms that are used as symbols
<compat> 2105-2106 retain Variant letter forms that are used as symbols
<compat> 2121 retain** For use as single code point in vertical layout
<compat> 2160-2175 retain** For use as single code point in vertical layout
<compat> 3131-318E retain Compatibility Hangul Jamo. These do not-conjoin
<compat> 2002-200A retain Fixed width spaces
<compat> 3200-3229 use list item marker style Parenthesized characters used as list item markers
<compat> 322A-3243 retain** Parenthesized characters used as symbols in vertical layout
<compat> 2474-249B use list item marker style Parenthesized or dotted number used as list item marker
<compat> 249C-24B5 use list item marker style or normalize* Parenthesized letters used as list item markers
<compat> 32C0-32CB retain** String used as single code point in vertical layout
<compat> all other retain Maintain, semantic distinctions apply
<final> all normalize* Arabic Presentation forms
<font> all retain Variant letter forms that are used as symbols
<fraction> all decompose As long as fraction slash is supported!
<initial> all normalize* Arabic Presentation forms
<isolated> all normalize* Arabic Presentation forms
<medial> all normalize* Arabic Presentation forms
<narrow> all retain Half-width characters
<no-break> all retain The compatibility mapping is merely a way to indicate the equivalent character that is not non-breaking. The distinction must be preserved
<small> all retain Precise usage unknown. Maintain, but don't generate
<square> 3300-3357 retain*** Single display cell cluster containing multiple lines of kana for vertical layout
<square> 3358-337D retain*** For use as single code point in vertical layout
<square> 33E0-33FE retain*** For use as single code point in vertical layout
<square> all other retain*** Variant letter form used as symbol in vertical layout
<super> all <sup> Superscripted characters
<sub> all <sub> Subscripted characters
<vertical> all normalize* East Asian Presentation forms
<wide> all retain Full-width characters


*) Use normalization form KC for these particular characters. 
**) Some symbols used in vertical layout may also become accessible via list item marker style(s).
***) At the time of this writing there is no appropriate markup for squared kana clusters or horizontal in vertical symbols.

4.2 Generating characters

Presentation forms and characters for which adequate representation exists as marked up text should never be generated for new data. However, many of the characters with <font> tag are suitable for new data, as long as they are used in the manner they are intended, that is as symbols, with definite semantic differentiation between the different forms. However, they must not be used to create styled text. On the other hand, styled text should not be used to carry the essential semantic distinction needed for example for mathematics.

4.3 List item marker characters

Short description: Characters with a <circled> tag or characters with <compat> tag and compatibility mapping to a parenthesized string.

Reason for inclusion: They are most frequently used for marking enumerated list items, but the characters with a <circled> tag often occur as dingbats or footnote markers in tables.

Problems when used in markup: These characters do not cause undue interaction with markup

Problems with other uses: None

Replacement markup: (list item style) When generating marked up text these characters occur only internal to the user agent when list item styles are rendered. When marking up plain text data they could be converted to suitable list item styles, if such use can be properly inferred. However, it is often necessary to refer to numbered or lettered list item markers in the text.

Compatibility mappings of the form (n) or (n.) can be kept as single characters, or replaced by list item marker styles. A conversion to list item marker styles allows a simple extension of the set to arbitrary numbers. This is in contrast to circled characters: Very few browsers can properly generate arbitrary circled numbers, therefore conversion to list item marker styles does not easily allow an extension of the set of accessible circled numbers.

What to do if detected: No action needs to be taken by browsers. When received in an editing context, substitution of a list item marker style may be appropriate. However, the same characters are very often used as dingbat-like symbols in tables, so the user should have the choice of whether to replace.

4.4 Fractions

Short description: Single character fractions such as ½ or ¼.

Reason for inclusion: Subsets of these occur in practically all legacy character sets.

Problems when used in markup: The repertoire is limited to a few common fractions. When used with more general methods of generating fractions such as MathML[MathML] the usual problem of dual representation arises.

Problems with other uses: Other than normalization issues, these characters present no undue problems in plain text. Where fraction slash is supported, these can be expressed by substituting their compatibility mappings.

Replacement markup: MathML.

What to do if detected: No action needs to be taken by browsers or editors, except when converting plain text to MathML.

4.5 Squared or horizontal

Short description: Characters that are symbols composed of groups of typically kana or Latin letters, digits plus slash for use in a single display cell in vertical display of text. 

Reason for inclusion: Many existing character sets contain these as precomposed characters since for simple implementations this is the only way to support the common use of providing metric units and other abbreviations in a single character cell for vertical text layout. 

Problems when used in markup: Proposed markup, including CSS styling, would be able express an unbounded set of these abbreviations, obviating the need of cataloguing these in the character encoding standard and making them more directly accessible to text based processing, for example searching.

Problems with other uses: The repertoire of these legacy characters is limited; many more combinations are in actual use than are accounted for in character sets. Pre-composed symbols do not make their text content available to search engines. They also require re-encoding for text laid out horizontally.

Replacement markup: not available at this time.

What to do if detected: No action required. (Subject to change pending the outcome of current proposals.)

4.6 Superscripts and subscripts

Short description: mainly super and subscript digits, but also signs, parens and some letters.

Reason for inclusion: Super and subscript characters occur in many legacy character sets, including Latin-1. Their use in pure plain text is common for databases, e.g. including metric units for part descriptions  (viz. cm2) or (usually simplified) formulae as occur in titles of scientific publications. Super and subscripted letters and digits are common in some forms of phonetic or phonemic transcriptions.

Problems when used in markup: Using these characters directly in markup provides an alternate representation compared to marked up text, leading to different treatment by search engines. However, when super and sub-scripts are to reflect semantic distinctions, it is easier to work with these meanings encoded in text rather than markup, for example, in phonetic or phonemic transcription.

Problems with other uses: none

Replacement markup:<xhtml:sup> and <xhtml:sub> or <mathml:msup> and <mathml:msub>

What to do if detected: No action required by browsers. When received in an editing context, substitute the corresponding markup.

4.7 Other characters marked <compat>

Short description: The <compat> label was given to a set of compatibility characters whose further classification was not settled at the time the standard was created. The largest components are list item marker characters.

Reason for inclusion: These characters occur in many legacy character sets.

Problems when used in markup: none. There usually is no equivalent markup.

Problems with other uses: none

Replacement markup: none.

What to do if detected: No action required.

5. Versioning

This technical report covers all relevant characters in the Unicode Standard, Version 3.0.

This report will be updated by the Unicode Technical Committee in cooperation with the W3C i18n WG whenever the tables of characters need to be updated as result of the addition of characters to the Unicode Standard, as result of a revised determination of the suitability of a given character for use with markup, or when additional background information or recommendations will become available.

As the Unicode standard is updated and new characters get added, new characters that are not suitable for markup may also be added. However, the Unicode Technical Committee only introduces such characters where there is a strong requirement by industry or users of a script. As markup becomes more prevalent, the need for such characters may diminish. 

Each report carries a revision number, which may be used to refer to a specific version of the report. Older versions of the report will remain available. Each version of this report will also specify the underlying version of the Unicode Standard.

For more information on the Unicode Standard and its versions, see:

6. Conformance

In the context of the Unicode Standard, the material in this technical report is informative. However, other documents, particularly markup language specifications, may specify conformance including normative references to this document. There may be future updates to this report as discussed in Section 5, and this will affect such references.

7. References

Martin J. Dürst, François Yergeau, Character Model for the World Wide Web, W3C Working Draft 29-Nov-1999, <http://www.w3.org/TR/charmod>.
Martin J. Dürst, Requirements for String Identity and Character Indexing Definitions for the WWW, W3C Working Draft 10-July-1998, <http://www.w3.org/TR/WD-charreq>.
Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, Eds., Cascading Style Sheets, level 2 (CSS2 Specification), W3C Recommendation 12-May-1998, <http://www.w3.org/TR/REC-CSS2/>.
[HTML 4.0]
Dave Raggett, Arnaud Le Hors, Ian Jacobs, Eds., HTML 4.01 Specification, W3C Recommendation 18-Dec-1997 (revised on 24-Dec-1999), <http://www.w3.org/TR/REC-html40/>.
[HTML 4.0 - 8.2]
Section 8.2 of [HTML4.0] Specifying the direction of text and tables: the dir attribute <http://www.w3.org/TR/html40/struct/dirlang.html#h-8.2>
Patrick Ion, Robert Miner, Eds., Mathematical Markup Language (MathML™) 1.01 Specification
Tim Bray, Dave Hollander, Andrew Layman, Namespaces in XML, W3C Recommendation 14-Jan-1999, <http://www.w3.org/TR/REC-xml-names/>.
Marcin Sawicki, Michel Suignard, Masayasu Ishikawa, Martin Dürst, Eds., Ruby, W3C Working Draft 17-Dec-1999, <http://www.w3.org/TR/ruby/>.
The Unicode Standard, Version 3.0, Addison Wesley, Reading MA, 2000, ISBN: 0-201-61633-5.
[UTR 7]
Ken Whistler, Glenn Adams, Unicode Technical Report #7, Plane 14 Characters for Language Tags, <http://www.unicode.org/unicode/reports/tr7/>.
[UTR 9]
Mark Davis, Unicode Technical Report #9, The Bidirectional Algorithm, <http://www.unicode.org/unicode/reports/tr9/>.
[UTR 13]
Mark Davis, Unicode Technical Report #13, Unicode Newline Guidelines, <http://www.unicode.org/unicode/reports/tr13/>.
[UTR 15]
Mark Davis, Martin Dürst, Unicode Technical Report #15, Unicode Normalization Forms, <http://www.unicode.org/unicode/reports/tr15/>.
Steven Pemberton, et al., XHTML1.0: The Extensible HyperText Markup Language - A Reformulation of HTML 4.0 in XML 1.0, W3C Recommendation, <http://www.w3.org/TR/xhtml1/>.
[XML 1.0]
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eds., Extensible Markup Language (XML) 1.0, W3C Recommendation 10-February-1998, <http://www.w3.org/TR/xml>.

8. Acknowledgements

Mark Davis (mark.davis@us.ibm.com), and Hideki Hiura (hideki.hiura@eng.sun.com) contributed to the early drafts.

9. Change History (last changes first)

Changes from http://www.unicode.org/unicode/reports/tr20/tr20-4.html: Minor editorial changes to the text, added section 4.7, fixed some dates, plus a few typos. (AF)

Changes from http://www.unicode.org/unicode/reports/tr20/tr20-3.html: Minor editorial changes to the introduction, fixed some references, links, and dates, plus a few typos. (AF/MJD)

Changes from http://www.unicode.org/unicode/reports/tr20/tr20-2.html: Added sections 2.1-2.6 (MJD), sections 3.1-3.5, and 3.8, as well as sections 4.4-4.6 and 8 (AF). Edited text for publication as DRAFT Unicode Technical Report. (AF)

Changes from http://www.unicode.org/unicode/reports/tr20/tr20-1.html: Completed references, linked TOC. Various wording changes. Added W3C WD stylesheet, logo, copyright, status of this document. Streamlined authors' section. (MJD) Added material on compatibility characters. (AF)

Changes from the initial draft: Fixed the header. Fixed the numbering. Fixed the title. Put references to final version of data files based on naming conventions. Minor wording changes. Added proposed language on annotation characters to match example on FFFC. Posted for internal review by UTC and W3C. (AF)

10. Copyright

Copyright © 1999-2000 jointly held by Unicode, Inc. and W3C® (MIT, INRIA, Keio), All Rights Reserved.

W3C Copyright, liability, trademark, document use and software licensing rules apply.

The Unicode Consortium makes no expressed or implied warranty of any kind, and assumes no liability for errors or omissions. No liability is assumed for incidental and consequential damages in connection with or arising out of the use of the information or programs contained or accompanying this technical report.

Unicode and the Unicode logo are trademarks of Unicode, Inc., and are registered in some jurisdictions.


Unicode Home Page: http://www.unicode.org

Unicode Technical Reports: http://www.unicode.org/unicode/reports/