ISO/IEC JTC1/SC2/WG2 N2677

ISO/IEC JTC 1/SC 2/WG 2
PROPOSAL SUMMARY FORM TO ACCOMPANY SUBMISSIONSFOR ADDITIONS TO THE REPERTOIRE OF ISO/IEC 106461
Please fill all the sections A, B and C below.
(Please read Principles and Procedures Document for guidelines and details before filling this form.)
See http://www.dkuug.dk/JTC1/SC2/WG2/docs/summaryform.html for latest Form.
See http://www.dkuug.dk/JTC1/SC2/WG2/docs/principles.html for latest Principles and Procedures document.
See http://www.dkuug.dk/JTC1/SC2/WG2/docs/roadmaps.html for latest roadmaps.

A. Administrative
Adition of six Number forms characters_______________________________________________________________________
1. Title:
2. Requester's name: ___________________________________________________________________________
Ricardo Cancho Niemietz
3. Requester type (Member body/Liaison/Individual contribution):____________________________________
Individual contribution
2003-10-21
4. Submission date:_______________
5. Requester's reference (if applicable): _____________________________________________________________
6. (Choose one of the following:)
Yes
This is a complete proposal:_______________or,More information will be provided later:_______________
B. Technical - General
1. (Choose one of the following:)
No
a. This proposal is for a new script (set of characters):______________
Proposed name of script: _________________________________________________________
Yes.
b. The proposal is for addition of character(s) to an existing block:______________
Number Forms
Name of the existing block:__________________________________________________
6
2. Number of characters in proposal:______________
B.1
3. Proposed category (see section II, Character Categories):______________
1
4. Proposed Level of Implementation (1, 2 or 3) (see clause 14, ISO/IEC 10646-1: 2000):______________Is a rationale provided for the choice?
______________
If Yes, reference: ________________________________________________________________
Yes
5. Is a repertoire including character names provided?
______________
a. If YES, are the names in accordance with the 'character naming guidelines
Yes
in Annex L of ISO/IEC 10646-1: 2000?
______________Yes
b. Are the character shapes attached in a legible form suitable for review?
______________
6. Who will provide the appropriate computerized font (ordered preference: True Type, or PostScript format) for
Ricardo Cancho Niemietz
publishing the standard? ________________________________________________________________
If available now, identify source(s) for the font (include address, e-mail, ftp-site, etc.) and indicate the tools
used:_____________________________________________________________________________________
Ricardo Cancho Niemietz (rcancho@tiscali.es)__________________________________________________________________________________________________________________________________________________________________________
7. References:Yesa. Are references (to other character sets, dictionaries, descriptive texts etc.) provided?
b. Are published examples of use (such as samples from newspapers, magazines, or other sources)Noof proposed characters attached?
______________
8. Special encoding issues:
Does the proposal address other aspects of character data processing (if applicable) such as input,
presentation, sorting, searching, indexing, transliteration etc. (if yes please enclose information)?
Specifications enclosed_____________________________________________________________________________________
9. Additional Information:
Submitters are invited to provide any additional information about Properties of the proposed Character(s) or Scriptthat will assist in correct understanding of and correct linguistic processing of the proposed character(s) or script.
Examples of such properties are: Casing information, Numeric information, Currency information, Display behaviour
information such as line breaks, widths etc., Combining behaviour, Spacing behaviour, Directional behaviour, Default
Collation behaviour, relevance in Mark Up contexts, Compatibility equivalence and other Unicode normalization
related information. See the Unicode standard at http://www.unicode.org for such information on other scripts. Also
see http://www.unicode.org/Public/UNIDATA/UnicodeCharacterDatabase.html and associated Unicode Technical
Reports for information needed for consideration by the Unicode Technical Committee for inclusion in the UnicodeStandard.

N2352-F
2001-09-04

Page 1 of 3

C. Technical - Justification
No
1. Has this proposal for addition of character(s) been submitted before?
______________
If YES explain _________________________________________________________________________
2. Has contact been made to members of the user community (for example: National Body,
No
user groups of the script or characters, other experts, etc.)?
______________
If YES, with whom? ______________________________________________________________
If YES, available relevant documents: ________________________________________________
3. Information on the user community for the proposed characters (for example:
size, demographics, information technology use, or publishing use) is included?
______________
No
Reference: ___________________________________________________________________________
Common4. The context of use for the proposed characters (type of use; common or rare)______________
Reference: ___________________________________________________________________________
Publishers of specialized books about computer software and digital hardware
Yes
5. Are the proposed characters in current use by the user community?
______________
If YES, where? Reference: ______________________________________________________________
Editors thru workaround
6. After giving due considerations to the principles in Principles and Procedures document (a WG 2 standing
document) must the proposed characters be entirely in the BMP?
______________Yes
If YES, is a rationale provided?
______________Yes
If YES, reference: ________________________________________________________
EnclosedYes
7. Should the proposed characters be kept together in a contiguous range (rather than being scattered)? _______
8. Can any of the proposed characters be considered a presentation form of an existingYescharacter or character sequence?
______________Yes
If YES, is a rationale for its inclusion provided?
______________
Enclosed
If YES, reference: ________________________________________________________
9. Can any of the proposed characters be encoded using a composed character sequence of either
No
existing characters or other proposed characters?
______________
If YES, is a rationale for its inclusion provided?
______________
If YES, reference:______________
10. Can any of the proposed character(s) be considered to be similar (in appearanceYesor function) to an existing character?
______________Yes
If YES, is a rationale for its inclusion provided?
______________
Enclosed
If YES, reference: ________________________________________________________
11. Does the proposal include use of combining characters and/or use of composite sequencesNo(see clauses 4.12 and 4.14 in ISO/IEC 10646-1: 2000)?
______________
If YES, is a rationale for such use provided?
______________
If YES, reference: _______________________________________________________Is a list of composite sequences and their corresponding glyph images (graphic symbols)
provided?
______________
If YES, reference: _______________________________________________________
12. Does the proposal contain characters with any special properties such asNocontrol function or similar semantics?
______________
If YES, describe in detail (include attachment if necessary)______________
No
13. Does the proposal contain any Ideographic compatibility character(s)?
______________
If YES, is the equivalent corresponding unified ideographic character(s) identified? ____________
If YES, reference: ________________________________________________________

1

Form number: N2352-F (Original 1994-10-14; Revised 1995-01, 1995-04, 1996-04, 1996-08, 1999-03, 2001-05, 2001-09)

N2352-F
2001-09-04

Page 2 of 3

Submitter's Responsibilities
The national body or liaison organization (or any other organization or an individual) proposing new
character(s) or a new script shall provide:1.
Proposed category for the script or character(s), character name(s), and description of usage.
2.
Justification for the category and name(s).
3.
A representative glyph(s) image on paper:
If the proposed glyph image is similar to a glyph image of a previously encoded ISO/IEC 10646
character, then additional justification for encoding the new character shall be provided.
Note: Any proposal that suggests that one or more of such variant forms is actually a distinct character
requiring separate encoding, should provide detailed, printed evidence that there is actual, contrastive use of
the variant form(s). It is insufficient for a proposal to claim a requirement to encode as characters in theStandard, glyphic forms which happen to occur in another character encoding that did not follow theCharacter-Glyph Model that guides the choice of appropriate characters for encoding in ISO/IEC 10646.
Note: WG 2 has resolved in Resolution M38.12 not to add any more Arabic presentation forms to thestandard and suggests users to employ appropriate input methods, rendering and font technologies to meetthe user requirements.

4.
5.

6.
7.

8.
9.

Mappings to accepted sources, for example, other standards, dictionaries, accessible publishedmaterials
Computerized/camera-ready font:Prior to the preparation of the final text of the next amendment or version of the standard asuitable computerized font (camera-ready font) will be needed. Camera-ready copy is mandatory
for final text of any pDAMs before the next revision. Ordered preference of the fonts is True Typeor PostScript format. The minimum design resolution for the font is 96 by 96 dots matrix, forpresentation at or near 22 points in print size.
List of all the parties consulted.
Equivalent glyph images:
If the submission intends using composite sequences of proposed or existing combining and noncombining characters, a list consisting of each composite sequence and its corresponding glyph
image shall be provided to better understand the intended use.
Compatibility equivalents:
If the submission includes compatibility ideographic characters, identify the equivalent unified CJK
Ideograph character(s).
Any additional information that will assist in correct understanding of the different characteristics
and linguistic processing of the proposed character(s) or script.

N2352-F
2001-09-04

Page 3 of 3

2150

Number Forms
215

216

2160

2161

2162

2173

2183

2164

2174

2165

2175

2166

2176

2167

2177

 Ⅸ ⅸ
2158

2168

2178

 Ⅹ ⅹ
2159

2169

2179

 Ⅺ ⅺ A
215A

B

2163

 Ⅷⅷ
2157

A

2182

 Ⅶⅶ
2156

9

2172

 Ⅵ ⅵ
2155

8

2181

⅔ Ⅴ ⅴ
2154

7

2171

⅓ Ⅳ ⅳ 1
2153

6

2180

Ⅲ ⅲ 0

2

5

2170

Ⅱ ⅱ /

1

4

218

Ⅰ ⅰ .

0

3

217

216A

217A

218A

⅛ Ⅻⅻ B
215B

C
215C

D
215D

E
215E

F
215F

216B

217B

 *
216C

217C

218B

C
218C

 + D
216D

217D

218D

 , E
216E

217E

218E

 - F
216F

217F

218F

218F

2153

Number Forms

Fractions
Other fraction number forms are found in the Latin-1
Supplement block.
→ 00BC ¼ vulgar fraction one quarter→ 00BD ½ vulgar fraction one half
→ 00BE ¾ vulgar fraction three quarters
2153 ⅓ VULGAR FRACTION ONE THIRD
 0031 1 2044 ⁄ 0033 32154 ⅔ VULGAR FRACTION TWO THIRDS
 0032 2 2044 ⁄ 0033 32155 3 VULGAR FRACTION ONE FIFTH 0031 1 2044 ⁄ 0035 52156 5 VULGAR FRACTION TWO FIFTHS 0032 2 2044 ⁄ 0035 52157 6 VULGAR FRACTION THREE FIFTHS 0033 3 2044 ⁄ 0035 5
2158 7 VULGAR FRACTION FOUR FIFTHS 0034 4 2044 ⁄ 0035 52159 9 VULGAR FRACTION ONE SIXTH
 0031 1 2044 ⁄ 0036 6
215A ; VULGAR FRACTION FIVE SIXTHS
 0035 5 2044 ⁄ 0036 6
215B ⅛ VULGAR FRACTION ONE EIGHTH
 0031 1 2044 ⁄ 0038 8
215C > VULGAR FRACTION THREE EIGHTHS 0033 3 2044 ⁄ 0038 8
215D ? VULGAR FRACTION FIVE EIGHTHS 0035 5 2044 ⁄ 0038 8
215E @ VULGAR FRACTION SEVEN EIGHTHS 0037 7 2044 ⁄ 0038 8
215F B FRACTION NUMERATOR ONE
 0031 1 2044 ⁄Roman numerals
2160 Ⅰ ROMAN NUMERAL ONE
 0049 I latin capital letter i
2161 Ⅱ ROMAN NUMERAL TWO
 0049 I 0049 I
2162 Ⅲ ROMAN NUMERAL THREE 0049 I 0049 I 0049 I
2163 Ⅳ ROMAN NUMERAL FOUR
 0049 I 0056 V
2164 Ⅴ ROMAN NUMERAL FIVE
 0056 V latin capital letter v
2165 Ⅵ ROMAN NUMERAL SIX
 0056 V 0049 I
2166 Ⅶ ROMAN NUMERAL SEVEN
 0056 V 0049 I 0049 I
2167 Ⅷ ROMAN NUMERAL EIGHT 0056 V 0049 I 0049 I 0049 I
2168 Ⅸ ROMAN NUMERAL NINE
 0049 I 0058 X
2169 Ⅹ ROMAN NUMERAL TEN
 0058 X latin capital letter x
216A Ⅺ ROMAN NUMERAL ELEVEN
 0058 X 0049 I

2183

216B Ⅻ ROMAN NUMERAL TWELVE
 0058 X 0049 I 0049 I
216C  ROMAN NUMERAL FIFTY 004C L latin capital letter l
216D  ROMAN NUMERAL ONE HUNDRED
 0043 C latin capital letter c
216E
ROMAN NUMERAL FIVE HUNDRED
 0044 D latin capital letter d
216F
ROMAN NUMERAL ONE THOUSAND
 004D M latin capital letter m
2170 ⅰ SMALL ROMAN NUMERAL ONE
 0069 i latin small letter i
2171 ⅱ SMALL ROMAN NUMERAL TWO
 0069 i 0069 i
2172 ⅲ SMALL ROMAN NUMERAL THREE 0069 i 0069 i 0069 i
2173 ⅳ SMALL ROMAN NUMERAL FOUR
 0069 i 0076 v
2174 ⅴ SMALL ROMAN NUMERAL FIVE
 0076 v latin small letter v
2175 ⅵ SMALL ROMAN NUMERAL SIX
 0076 v 0069 i
2176 ⅶ SMALL ROMAN NUMERAL SEVEN
 0076 v 0069 i 0069 i
2177 ⅷ SMALL ROMAN NUMERAL EIGHT
 0076 v 0069 i 0069 i 0069 i
2178 ⅸ SMALL ROMAN NUMERAL NINE
 0069 i 0078 x
2179 ⅹ SMALL ROMAN NUMERAL TEN
 0078 x latin small letter x
217A ⅺ SMALL ROMAN NUMERAL ELEVEN
 0078 x 0069 i
217B ⅻ SMALL ROMAN NUMERAL TWELVE
 0078 x 0069 i 0069 i
217C  SMALL ROMAN NUMERAL FIFTY 006C l latin small letter l
217D  SMALL ROMAN NUMERAL ONE
HUNDRED 0063 c latin small letter c
217E
SMALL ROMAN NUMERAL FIVE
HUNDRED 0064 d latin small letter d217F " SMALL ROMAN NUMERAL ONE
THOUSAND 006D m latin small letter m
2180 $ ROMAN NUMERAL ONE THOUSAND C
D
2181 % ROMAN NUMERAL FIVE THOUSAND
2182 & ROMAN NUMERAL TEN THOUSAND
2183 ' ROMAN NUMERAL REVERSED ONE
HUNDRED= apostrophic C• used in combination with C and I to form
large numbers

218A

Number Forms

Hexadecimal digits ten to fifteen
218A
218B
218C
218D
218E
218F

A HEXADECIMAL DIGIT TEN
 0041 A latin capital letter a
B HEXADECIMAL DIGIT ELEVEN
 0042 B latin capital letter b
C HEXADECIMAL DIGIT TWELVE
 0043 C latin capital letter c
D HEXADECIMAL DIGIT THIRTEEN 0044 D latin capital letter d
E HEXADECIMAL DIGIT FOURTEEN 0045 E latin capital letter e
F HEXADECIMAL DIGIT FIFTEEN
 0046 F latin capital letter f

218F

Background
The hexadecimal-radix (base 16) numbering system is well-known and widely used in all fashion ofcomputer and microprocessor programming environments and languages. Every hexadecimal digit
ressembles a group of four contiguous bits, called a nibble, and thus is quite convenient to represent thestate of any grouping of adjacent bits: 8, 16, 24, 32, 64, etc, inside a computer’s memory, CPU ports andintegrated circuits (IC) pins.
The hexadecimal-radix numbering system intrinsically needs sixteen different digits with positional
values in a range from zero to fifteen. In a lack of historical tradition in precomputer ages, and due tolimitations of available characters in the primitive encoding scripts as ITA-2 (also known –incorrectly– as
baudot code), FIELDATA, EDBIC or ASCII, arised the solution to use the decimal digits zero to nine forthe first ten hexadecimal digits (those whose positional values are the same in decimal-radix numbering)and the latin letters «a» to «f» for the last six hexadecimal digits with values ten to fifteen. The glyphs
usually used for that last hexadecimal digits are the upper case «A» to «F», due to primitive pre-ASCII
encoding charts have only uppercase form of latin letters—a telegraphic tradition. When a complete set ofboth upper and lower case basic latin letters became available, the hexadecimal numbers could be
displayed with the lowercase glyphs «a» to «f» as an alternate presentation, but never appears mixed thecapital and small forms together in the same printed hexadecimal number.
To contextually distinguish hexadecimal numbers in a plain text stream, specially when the hexadecimal
number was formed exclusivally by “decimal” digits, various kind of notation arise, generally specific ofa given environment. For example, the number 33 in decimal is represented in hexadecimal (21) in thefollowing ways,
as...

in...

$21
021H
0x21
\x21
H&21
%21
=21
#0000216502 assembler
8086 assembler
ANSI C/C++ direct value
ANSI C/C++ direct character by code inside a string literal
Microsoft VisualBasic direct value
URL direct character by code inside a calling parameter
MIME quoted-printable character by code inside a text/plain MIME-part bodyHTML RGB color code

This notations appears as-is in source code, following the specific sintax of every programming language
or encoding. But in books another conventions are in use, as 21h or 2116, meaning the same: “that number
is 16-radix”. In Unicode books, codepoints (which are hexadecimal numbers) are noted by U+0021
sintax.
About the need of new characters
Since programmers can directly write programs over a console (leaving away punched-cards), they use
fixed-pitch fonts to display source code and debugging output, either on screen and paper. At the
beginning this was not intentionally but by simply using the available hardware (80 column screens inclassical MDA video cards and compatibles, and teletype-like dolly printers). This implicit feature canprint either decimal (and other subdecimal numbering formats, as binary and octal) and hexadecimal
numbers in well tabulated columns.
Later, when high resolution raster devices became available, as EGA/VGA/SVGA video cards and 9- and24-pin dot matrix/ink jetting/laser printers, graphical user interfaces (GUI) tends to be WYSIWYG(“What-You-See-Is-What-You-Get”) capable. Among other things, this means the main use of
proportional fonts to display both plain and rich text, but programmers still prefer using fixed-pitch fonts
for source code and debugging output, just like memory dump. In some way, it emulates older console
devices.
This is also the common workaround when fragments of sample source code are printed in
documentation, as shown in the following figures.

Closing a window
You can close a window with the close method. You cannot close a frame without
closing the entire parent window.
Each of the following statements closes the current window:
window.close()
self.close()// Do not use the following statement in an event handler
close()
The following statement closes a window called msgWindow:
msgWindow.close()
Taken from “JavaScript Guide for JavaScript 1.1” Copyright ©1995-1996 NetscapeCommunications Corporation.

Creating a Foundation Project
You'll need to create a suitable Visual C++ project for this tour.
With no other workspace or project loaded in the Visual C++
integrated development environment (IDE), select New from theFile menu. Select the Files tab. Select C++ Source File, and enter
EC_Demo.cpp as the file name. You may enter a location of yourchoice. Click OK to create the file. Type the following source code
into the empty source file:#include <stdio.h>
int main(){
printf("Introducing Edit and Continue!\n");return 0;}
Taken from “Juny 1999 release of the MSDN Library” Copyright ©1999 Microsoft Corporation.

But out of showing source code samples, text books generally prints hexadecimal numbers using the «A»
to «F» latin capital letters, which are proportional in most of fonts, mixed with «0» to «9» digits, which
generally have figure-space pitch. Then, when displaying hexadecimal numbers of the same number ofdigits, they have different physical widths. This fact usually ruins the tabulated hexadecimal columns.
As said, the usual workaround is also to use a monospace or fixed-pitch font to print hexadecimal
numbers in tables. This is tolerable in technical programming and debugging environments, in which theprimary need is to monitorize memory binary data, but when printed, the tabulated hexadecimal values
looks clearly in a different font family than the rest of the table or page.
The next figure shows a display output that mixes well-formed and ill-formed tabulated hexadecimalvalues.

Note that at the right side, in the upper and middle lists, the columns labeled “Entry Point” displays 32
bits hexadecimal values with a proportional font, and hexadecimal digits are not well aligned. But in thelower list, in the column labeled “Base”, the 32 bit hexadecimal values are displayed with a monospaced
font and all the hexadecimal digits are well vertically aligned, although they do not share the same fontfamily than the rest of data.
Another example of ill-tabulated hexadecimal colums are taken directly from the Unicode book:
When referring to code points in the Unicode Standard, the usual practice is to referto them by their numeric value expressed in hexadecimal, with a “U+” prefix. (See
Section 0.3, Notational Conventions.) Encoded characters can also be referred to by
their code points only, but to prevent ambiguity, the official Unicode name of thecharacter is often also added; this clearly identifies the abstract character that is
encoded. For example:
U+0061 LATIN SMALL LETTER A
U+10330 GOTHIC LETTER AHSA
U+201DF CJK UNIFIED IDEOGRAPH-201DF
Such citations refer only to the encoded character per se, associating the code point(as an integral value) with the abstract character that is encoded.
Taken from “The Unicode Standard, Version 4.0, Chapter 2, General Structure” Copyright© 1991–2003 by Unicode, Inc.

Note that items “U+10330” and “U+201DF” has the same number of hexadecimal digits (five), butdifferent widths: the «F» do not fall exactly below the «0».
In the last example, this fact has a relative relevance, but in other material with larger descripting tables
this could became a serious one. This could be avoided by introducing a set of «hexadecimal digits ten to
fifteen» characters, which have similar glyphs that latin letters «A» to «F» have, but share the same figure
space width that decimal digits. These are the basics of this proposal.

Semantics and compatibility•

It is proposed to include this hexadecimal digits in the «number forms» script rather than others (like«letterlike symbols» script or any mathematical blocks) due to the intrinsic numeric value of every
hexadecimal digit. These values must be reflected in the Unicode Character Database.

•

The proposed code points U+218A..U+218F were selected due they terminate in the samehexadecimal values that the proposed characters have, and could be used as nmenonics.

•

The letter-like apparience of the hexadecimal digits ten to fifteen should be considered mere
coincidence, and thus no case pairs should be assigned in the Unicode Standard.

•

As compatibility forms, this hexadecimal digits could to default to the latin capital letters «A» to «F».
This is for display purposes only because they can show the same shapes of the hexadecimal digits
ten to fifteen, and inform of the value of the hexadecimal numbers to the users, although tabulation
surely becomes visually corrupted.

•

In any case it is not recommended to use greek capital letters or cyrillic capital letter as compatibility
forms. Latin capital letters «A» to «F» are the unique guaranteed to be present in any ASCII-based
font.

•

Note that there is no proposal here to include hexadecimal digits zero to nine; they are supposed to beunified with ASCII decimal digits, as in this sense the hypothaetical octal digits zero to seven andbinary digits zero and one are.

•

The non-contiguous ranges to both ASCII decimal digits and proposed hexadecimal digits it is not an
issue: the range of the ASCII latin capital letters are non-contiguous with digits, too.

Typographical remarks•

When present in a font, it is mandatory that proposed characters HEXADECIMAL DIGIT TEN to
HEXADECIMAL DIGIT FIFTEEN have the same figure-space pitch than decimal digits DIGIT ZERO to
DIGIT NINE of the source font.

123456ABCDEFABCDEF•

Digit figures

Hexadecimal digit figures

Proportional latin capital letters «A» to «F»

The glyphs for this hexadecimal digits should not to be the same than that mapped to LATIN CAPITALLETTER A to LATIN CAPITAL LETTER F when the font is proportionally spaced (the usual case), but theyshould have their own specific glyphs.
When the font is monospaced, proposed code points HEXADECIMAL DIGIT TEN to HEXADECIMAL DIGITFIFTEEN may share the LATIN CAPITAL LETTER A to LATIN CAPITAL LETTER F glyphs of the font, byappropiate mapping.
When decimal digits on the font are proportional (i. e., the width of the DIGIT ONE is less than the
DIGIT FOUR, for example), the font should lack this proposed characters. Such family fonts will beconsider decorative fonts, not suitable for technical documentation.

•

Hexadecimal digits should share the "personality" of the source font (same serifed or sans-serifed
look, same weight, escapement and orientation, etc.), and they should be affected in the same way

that decimal digits are when editing stylistic changes are made in a rich text document: sizing,
stretching, colouring, bolding, stroking, outlining, etc.
•

No switching must ocurr between capital and small size, i. e., there is only one case for this digits,
not two. It is not mandatory than hexadecimal digits ten to fifteen resembles the latin capital letters«A» to «F». It could be a font designers' choice to select the latin small letters «a» to «f» apparience,
although capital forms are preferred, or perhaps will be useful to standarize a variant selection of thetwo options, being the capital form the default and small form the variation.

•

Care should be taken in desinging the HEXADECIMAL DIGIT ELEVEN («B») and HEXADECIMAL DIGITTHIRTEEN («D») glyphs, due to their similarity with decimal digits eigth «8» and zero «0»,respectively. Generally this is not a trouble in serifed Times-like fonts, but in sans-serifed Helveticalike fonts could lead to confussion, specially at small points sizes or low resolution devices. It issuggested that even in sans-serifed fonts, the HEXADECIMAL DIGIT ELEVEN («B») and HEXADECIMAL
DIGIT THIRTEEN («D») glyphs renders with discrete serifs too.

Inputting and editing proposed methods (for advanced desktop publishing software only)•

For keyboard interfaces, some kind of toggle-command should be implemented to switch between
write "hexadecimal numbers A-F" and "latin letters A-F", in the same fashion as the bold, italics,
underlined, etc. classical toggles. While in "hex" mode, the latin capital letters «A» to «F» stroked on
the keyboard (and even the latin small letters «a» to «f») would be stored with U+218A..U+218F
proposed internal codes in memory.

•

For selected text, some kind of toggle-command should be implemented to switch between "tohexadecimal digits A-F ↔ to latin letters A-F", in the same fashion as the "to uppercase ↔ tolowercase" classical toggle. This toggle will affect only to the capital letters «A» to «F» presents inthe selected text, which becomes hexadecimal digits ten to fifteen, and these back to latin capitalletters when the toggle is executed again.

•

When inserting fullwidth letter forms in a far east language text that use fullwidth forms,
hexadecimal digits should render to the fullwidth forms FULLWIDTH LATIN CAPITAL LETTER A(U+FF21) to FULLWIDTH LATIN CAPITAL LETTER F (U+FF26), because all fullwidth latin letters anddigits have the same width, and the main goal with hexadecimal numbers is acomplished that way.
Thus, FULLWIDTH LATIN CAPITAL LETTER A to FULLWIDTH LATIN CAPITAL LETTER F characters could
be considered the "presentation forms" of the hexadecimal digits ten to fifteen when writting far east
languages fullwidth text.

Sample font provided
This PDF document has embebbed glyphs of a TrueType font made by me called “Hexadecimal Serif”,
based on popular “Times New Roman” regular font that came with standard installation of Microsoft
Windows 9x, copyrighted by The Monotype Corporation plc. The sample include only the original digits
zero to nine plus the latin capital letters «A» to «F» made in hexadecimal digits fashion (i.e., they havefigure space pitch), the last also mapped as the proposed hexadecimal digits ten to fifteen
U+218A..U+218F.
The glyphs are full camera-ready (in fact, they are just pure vectors), but the font lack on hinting
information—kerning is not needed in this case.
No copyright notice is supplied with this sample font; the goal is that at appropiate time the owner(Monotype) implements their own glyphs, full with hinting info.
The sample Truetype font file will be send as separate file if requested.

Issues of the proposal
The main question is if this new proposed characters should be mere presentation forms or if they shouldbe pure number forms. Both are also cases of disunification from the latin capital letters «A» to «F», aproccess that is discouraged by the Unicode Consortium.
It is true that, from an compositing point of view, proposed hexadecimal digits ten to fifteen are merely akind of alphabetic presentation forms of the latin capital letters «A» to «F», which shares the samegeneral visual apparience that the corresponding source font, but having a figure space pitch rather thanproportional pitch. If this was the case, it implies to consider the hexadecimal digits ten to fifteen asalphabetic characters. We read in The Unicode Standard, Version 4.0, Chapter 4 “Character
propierties”:
4.9 Letters, Alphabetic, and Ideographic
The concept of letters is used in many contexts. Computer language standards often
characterize identifiers as consisting of letters, syllables, ideographs, and digits, but do not
specify exactly what a “letter,” “syllable,” “ideograph,” or “digit” is, leaving the definitions
implicitly either to a character encoding standard or to a locale specification. The large
scope of the Unicode Standard means that it includes many writing systems for which these
distinctions are not as self-evident as they may once have been for systems designed towork primarily for Western European languages and Japanese. In particular, while theUnicode Standard includes various “alphabets” and “syllabaries,” it also includes writing
systems that fall somewhere in between. As a result, no attempt is made to draw a sharp
property distinction between letters and syllables.
Alphabetic. The alphabetic property is an informative property of the primary units ofalphabets and/or syllabaries, whether combining or noncombining. Included in this groupwould be composite characters that are canonical equivalents to a combining character
sequence of an alphabetic base character plus one or more combining characters; letter
digraphs; contextual variants of alphabetic characters; ligatures of alphabetic characters;
contextual variants of ligatures; modifier letters; letterlike symbols that are compatibility
equivalents of single alphabetic letters; and miscellaneous letter elements. Notably,
U+00AA FEMENINE ORDINAL INDICATOR and U+00BA MASCULINE ORDINAL INDICATOR are
simply abbreviatory forms involving a Latin letter and should be considered alphabetic
rather than nonalphabetic symbols.
We see that under this definition of “alphabetic” the proposed characters hexadecimal digits ten to fifteen
do not fit well, due they are not part of any alphabet nor syllabary per se, despite its shape of latin letters.
In other words, the hexadecimal digits have not any latin letter semantics, and thus, they cannot be
considered alphabetics in any way. Consecuently, they cannot be considered a mere presentation forms ofany true alphabetic latin letter character.
In the same sense, hexadecimal digits ten to fifteen cannot be considered letterlike symbols nor
mathematical symbols:••

hexadecimal digits ten to fifteen are not symbols anyway; they do not represent any abstract idea
individually but positional digits in a well defined numbering system, andhexadecimal digits ten to fifteen are not used in any mathematical nor physical ecuation; furthermore,they are not operators anyway.

Finally, we can consider the hexadecimal digits ten to fifteen as a new Number Forms sub-block. We readin The Unicode Standard, Version 4.0, Chapter 4 “Character propierties”:
4.6 Numeric Value—Normative
Numeric value is a normative property of characters that represent numbers. This group
includes characters such as fractions, subscripts, superscripts, Roman numerals, currency
numerators, encircled numbers, and script-specific digits. In many traditional numberingsystems, letters are used with a numeric value. Examples include Greek and Hebrew letters
as well as Latin letters used in outlines (II.A.1.b). These special cases are not included hereas numbers.

Decimal digits form a large subcategory of numbers consisting of those digits that can beused to form decimal-radix numbers. They include script-specific digits, not characters suchas Roman numerals (<1, 5> = 15 = fifteen, but <I, V> = IV = four), subscripts, or
superscripts. Numbers other than decimal digits can be used in numerical expressions, but it
is up to the user to determine the specialized uses.
The Unicode Standard assigns distinct codes to the forms of digits that are specific to agiven script. Examples are the digits used with the Arabic script, Chinese numbers, or thoseof the Indic languages. For naming conventions relevant to Arabic digits, see theintroduction to Section 8.2, Arabic.
The Unicode Character Database gives the numeric values of Unicode characters that canrepresent numbers.
We see now that the proposed hexadecimal digits ten to fifteen fits well under this definition of numericcharacters, because they have a well defined semantic of numbers, but it is true that they are not decimal
digits:•••they have precisally known numeric values: A=10, B=11, C=12, D=13, E=14 and F=15, and theUnicode Character Database can reflect that;
the Roman numerals exists as a precedent, with its own associated numeric values and with the addedthth
pseudorule to be mandatory serifed (for example, the text “Along 18 and 19 centuries...” should
be rendered in spanish as “Durante los siglos XVIII y XIX...”, not *“Durante los siglos XVIII y
XIX...” when using a sans serifed font);
they can not to be considered any traditional numbering system like ancient greek and hebrew, inwhich letters have numeric values, nor having the outline use of the latin letters. The hexadecimal
digits ten to fifteen are true numeric characters in their own right.

As they have no alphabetic semantics, they are not affected by casing: there is not “upper” nor “lower”
hexadecimal digits ten to fifteen, in the same way that there are not “upper” nor “lower” decimal digits
zero to nine. The option to present hexadecimal numbers with the small case of the latin letters «a» to «f»will be considered a font’s designers choice (although discouraged, because then the hexadecimal
numbers can not be capitalized, which can be confuse), or perhaps to be a variant selection of the “basic”
capital form of the hexadecimal digits ten to fifteen.
On the other hand, there is the question of the disunification of these characters from its ASCII
counterparts. In a strict sense, this is a strong disunification, due that in up-to-date lack of specialized
hexadecimal digits ten to fifteen, the common practice is to use the ASCII latin capital letters «A» to «F».
Then, the main costs of the disunification would be:••

the cost of accidental confusion and mis-identification: the glyphs for the latin capital letters «A» to«F» are almost the same except for the figure space pitch, andkeyboards from which it is easy to type the existing and now-disunified characters are practically all
in the world.

But the proposed characters are not intended to be used while writting program code (as source code isever plain text), but to be used in all kind of documentation, on paper or on screen output, where
hexadecimal values often occurr—just like Unicode books. Then, the proposed hexadecimal digits ten to
fifteen acts as a kind of specialized presentation forms of the latin capital letters «A» to «F» for purposesof desktop publishing of rich text.
The main goal is that allocating this proposed characters, the general purpose proportional, book-like andUnicode compatible fonts have an explicit placeholder to this figure spaced “variations” of the latin letters«A» to «F», with its own standard codepoints. In this sense, they suffer the same disunification costs thanthe Roman numerals «I», «V», «X», «L», «C», «D» and «M» (and some less perhaps, because Roman
numerals include the small forms «i», «v», «x», «l», «c», «d» and «m» too, while the proposed
hexadecimal digits ten to fifteen does not).
Following the cost/benefits analysis criteria found in the Principles and Procedures for Allocation of New
Characters and Scripts and handling of Defect Reports on Character Names (ISO/IEC JTC 1/SC 2/WG 2
N2352R), every question is listed below with a proposed answer.

I. Costs
1.

Is there a glyphic distinction? Yes in proportional fonts, although certainly slighty: the proposed
hexadecimal digits ten to fifteen have all a figure space pitch, the same that the decimal digits in thesame base font, while latin capital letters «A» to «F» are clearly proportional. In the case ofmonospaced fonts, there is no difference in principle, unless ad hoc differences would be introducedby font designers to distinguish more clearly latin capital letters «A» to «F» from hexadecimal digits
ten to fifteen. In proportional fonts, the proposed characters must be added to the glyph collection ofthat fonts; in monospaced fonts, they can internally map to the basic latin capital letters «A» to «F».
Decorative fonts, that is, those not suitable for technical documentation, should explicitaly lack thisnew characters, due to generally they have even proportional decimal digits zero to nine, that is, notfigure spaced ones.

2.

Is there a behaviour difference? Yes in proportional fonts, because hexadecimal numbers writtenwith these new proposed characters perfectly aligns vertically to form true hexadecimal numericcolumns in tables. This difference do not affect to monospaced fonts, of course. Also, thehexadecimal digits ten to fifteen are not affected by case changes (to upper, to lower) of selected textthat normally affects to latin letters «A» to «F» and «a» to «f». The first target is achieved by the own
glyph metrics of the new characters (all figure spaced pitch); the second, by asigning no alphabetic
property nor case mapping at all to these new characters in the Unicode Character Database.

3.

Is the use of the new character restricted to a new context (for example, use with a novel
script)? No. The hexadecimal numbering system is widely used.

4.

Is the use of the existing, ambiguous character instead of the proposed new character common,
prevalent or established practice? Yes, in lack of previous specialized and separate characters forthe hexadecimal digits ten to fifteen. But it is not the intended goal to substitute this common practice
but to add a new, best suited resource for future publications.

5.

Does the character exist in ASCII (ISO 646 IRV)? They are the U+0041 “A” LATIN CAPITALLETTER A to U+0046 “F” LATIN CAPITAL LETTER F, which are the most commonly used to write
hexadecimal numbers, and alternatively the U+0061 “a” LATIN SMALL LETTER A to U+0066 “f”
LATIN SMALL LETTER F. In fact, the latin capital letters «A» to «F» should be the compatibility
characters of these new proposed characters.

II. Benefits
1.

Appearance: does disunification help to allow multilingual monofont text in an environment
where this is commonly needed? Yes, in publications of specialized books of computers
programming and digital hardware. In what way? It allows to write true “pure” hexadecimal
numbers with the same font of the main running text, instead of use of two distinct fonts, both a
proportional and a monospaced depending of the context—running text or tabulated.

2.

Layout: does disunification solve common layout differences (this would mostly be true forpunctuation)? Yes, as noted before, doing the case of columns of hexadecimal numbers in tabulatedmaterial perfectly consistent with the rest of the hexadecimal and non-hexadecimal numbers of the
documents.

3.

Searching/sorting: Is there a common case where disunification allows better support forthese? No. The proposed hexadecimal digits ten to fifteen can collate as regular latin letters «A» to«F» (although in a more strict sense they should sort just after the decimal digit nine, and before thanthe latin letter «A»—or the first letter in every alphabet available).

4.

Mapping to another standard: Is there a widely used standard that disunifies the characters inquestion? No known standard actually defines these characters. Are the characters in question the
only ones that prevent cross mapping? Actually there are not any cross mapping needs.

III. Alternatives
1.

Can the desired effect be achieved by changes to the display layer? No, while using a single
proportional font.

2.

Can the desired effect be achieved by changes to protocols? There are no current protocols foracomplish that task.

3.

Can the desired effect be achieved by processing algorithms? No.

Conclussion
The asserted main cost is the adding of the new six glyphs to a collection of widely used fonts for books(those which are Times-like, Helvetica-like and Courier-like, principally). Font vendors should update its
main products. However, rich text documents made with this new characters generally can haveembebbed font subsets (EPS, PDF), so it is not necessary to update every font installation—a prepress
service bureau can generate correct plates without having the explicit font files installed. The worst caseis the same that for the Roman numerals: if a given font lack to have these, the text must to switch to its
compatibility forms: the latin capital letters «I», «V», «X», «L», «C», «D» and «M», in the case of the
Roman numerals, and the latin capital letters «A» to «F» in the case of the hexadecimal digits ten to
fifteen.
Another main cost is the adding of a new interface for inputting these new characters. In general desktop
publishing software, this could be acomplished thru some kind of specialized plug-in extension—just likethat to write mathematical formulae or musical scores—or by customization thru user’s scripting macros.
De facto standard word processors usually have an “insert character” input feature to arbitrary choose any
Unicode character, and they do not explicitly needs new inputs methods (but every implementation will
be welcome).
The only one asserted benefit is to raise hexadecimal digits ten to fifteen to the same numeric formal andtypographical range than decimal digits zero to nine have: to have all figure space pitch and casepreventing with the same fonts than the running text in technical specialized documents.

About the author
Ricardo Cancho Niemietz was born in Madrid, Spain, in may 9 of 1969. He begans to program with theSinclair ZX Spectrum BASIC when he was fifteen years old. Few years after, in 1988, he joined thegreatest spanish company of entertainment home software, ERBE Software, thru its seal Topo Soft.
Between 1989 and 1991 he left the “Z80 videogames-age” behind and evolved to professional digital
image processing, desktop publishing and PostScript printing PC software programming in both 8086
assembler and C. Since 1993 and up to 2002 he was one the software partners of the Agencia EFE, themain spanish international press agency. Along this years digital photo capturing, retouching, transmitting
and receiving software, news client and word processor applications in both latin and arabic scripts, andmany communication I/O techniques and protocols developed and implemented for the central andsubsidiaries information-switching CPU systems of that agency, written in C/C++ under a variety ofMicrosoft platforms (from DOS to Windows 3.x/9x/NT/2000), are his more remarkable works. Also, hework closely with AT&T/Lucent Technologies factory in Tres Cantos, Madrid, in some production
improvement software for their clean-room, and even a new video digital format driver called
SuperAVI® was integrally developed by him under MS Windows 3.x for the main spanish CD factory,
Iberofon-Ibermemory (but this had no continuity in newer Win32 environments).
Also, he is a children books writer and illustrator. Now, he is trying to publish his work.
He still lives in Madrid, and his current electronic address is <rcancho@tiscali.es>. His mail address is:
José de Cadalso 75, bajo A
28044 Madrid – Spain