Wrong plane numbers

Ken Whistler kenwhistler at att.net
Fri Feb 6 09:50:21 CST 2015

Markus has already explained this. But the following explanation
fills out some details. These @@ lines are conveniences for chart
production. They are headers read by the unibook chart layout
tool, which help guide where chart layout for a block starts and stops.

The @@ lines are *NOT* block boundary definitions. So please do not
try to interpret them as such.

The normative definitions of block boundaries can be found in:


Incidentally, the block for the Supplementary Private Use Area-A
*does* end at FFFFF, not at FFFFD, as demonstrated by the
*normative* block definition from Blocks.txt:

F0000..FFFFF; Supplementary Private Use Area-A

The syntax used in the NamesList.txt file to drive chart production
is fully described in:


Much of the content of NamesList.txt is indirectly normative, of course, 
it is used to generate the code charts for versions of the Unicode Standard,
but much of the content of the file is just markup that assists in the
layout of the charts and/or various informative, annotational material.
It is *NOT* safe or recommended to attempt to reverse engineer
content out of the bare text file, nor to try to infer content implications
for the standard by extracting it from the bare text file.

Also, the unibook tool is regularly used by proposal writers to do chart
layout for encoding proposals, where block definitions obviously do
not even exist yet. The @@ header lines are used there, too, to
specify ranges used in the charts for the proposals.

By the way, there is over fifteen years of development history here for
the interaction of syntax in NamesList.txt and the ongoing maintenance
of the unibook chart production tool. The mismatch between @@ blockheader
ranges and normative block definitions has been noted (and explained)
a number of times now.


On 2/6/2015 7:15 AM, Jean-François Colson wrote:
> Le 06/02/15 16:06, Markus Scherer a écrit :
>> These are not block boundaries. These lines are for book chart 
>> production, where we don't need to print every unsigned code point.
>> markus
> OK. But what about
> @@    FFF80    Supplementary Private Use Area-A    FFFFF
> ?
> The Supplementary Private Use Area-A doesn’t begin at FFF80: it begins 
> at F0000.
> It doesn’t end at FFFFF: it ends at FFFFD.
> In
> @@    1E00    Latin Extended Additional    1EFF
> 1E00 and 1EFF are the limits of the block “Latin Extended Additional”.
> Why isn’t it so with
> @@    FFF80    Supplementary Private Use Area-A    FFFFF
> ?
> _

More information about the Unicode mailing list