Proposal to add name string ID(s) for the UVS collection name

[suzuki toshiya]

Dear SC29/WG11 font AHG experts,

I want to propose an addition of name string ID(s)
to declare UVS collection. Please give me some comments
on such idea.

Regards,
suzuki toshiya, Hiroshima University, Japan

--

* Abstract
I propose to add name string ID(s) to store Unicode
Variation Selector collection name.

* Background
Currently, Unicode Technical Standard #37,

http://www.unicode.org/ivd/

Unicode Ideographic Variation Database, has 2 named
collections; Adobe-Japan1 (by Adobe) and Hanyo-Denshi
(by Japan National Body). Although some of their glyph
images have quite similar shapes, their VS sequences
are not shared at all. Therefore, it is not so difficult
for the font drivers to guess which VS collection is
supported by a given font.

However, on ISO/IEC JTC1/SC2/WG2/IRG 41st meeting
in the last week, Japanese National Body introduced
their next registration named Moji_Joho collection
and Moji_Joho might share some VS sequences with
Hanyo-Denshi. In addition, the relationship between
Hanyo-Denshi and Moji_Joho is not under the simple
superset/subset relationship. They would be a
different collection with some crossing sections.

http://appsrv.cse.cuhk.edu.hk/~irg/irg/irg41/IRGN1959_Japan_Activity.doc

It is not practical solution for the font drivers
to have a list of the VS sequences to be checked
to detect the supported VS collection by a given font.
Also it is not pragmatic to expect a font driver
updating such list automatically.

CFF OpenType can hold Registry-Ordering-Supplement
info (e.g. Adobe-Japan1-6) in CFF table with PostScript
syntax, but such storage is not stablized in TrueType-like
OpenType. In fact, the free-charged font distributed by
Japanese governmental organization for Moji_Joho is not
CFF OpenType but TrueType-like OpenType.

As a result, there is a difficulty for the font driver
to detect the supported VS collection for a given font.

* Proposal
As the simplest solution, I propose to register
a name string ID to declare the VS collection name,
via name table in OpenType. The names of IVS collection
is stably registered in UTS#37, so there would not
be an ambiguity, in comparison with the charset names
registered in IANA. The cost of heuristic detection
of the VS collection by known VS list might be difficult
to estimate, but the cost of the deducive detection
by the name string would be easy to estimate.

* More items to be discussed
Some VS collections may have some additional info
to declare the revision, the subset, the implementation
levels etc, because IVS does not request the full support
of the registered VS collection. If the collection name
could be stored in the name table, any subset info is
expected to be stored in the name table?

For example, in the scope of Adobe-Japan1, there was a
revision number - due to the development cost for the
huge glyph collections, some fonts are still left in
smaller collection, like, Adobe-Japan1-4, and the fonts
with actively maintained support the latest/largest
collection, Adobe-Japan1-6.

In the case of Hanyo-Denshi, there were 2 batch different
registrations - the first registration on 2010-11-14
was the collection whose base characters are limited to
regional charset standard JIS X 0213:2004, the second
registration on 2012-03-02 was for the glyphs whose base
characters are not included in existing regional charset
standard.

The version of IVD registry is given by the year-month-date
string, but sometimes more flexible syntax is expected
(because, the IVD registry version date is not a solution
to declare the older subset of Adobe-Japan1 before 2007).
Is it pragmatic to register yet-another name ID for free
form text to declare the subset of the declared VS collection?