Skip to content

Symbol display mapping #428

@danbalogh

Description

@danbalogh

Dear @arlogriffiths and @manufrancis , as you know, we now have "mapping" for a preferred Unicode character with which encoded symbols can be displayed. When a symbol is encoded with a token and the mapping for that token is not empty, then the display algorithm will show the mapping, regardless of the content and @type of the <g> element. You can see some examples of this in Michaël's gaiji test page (best switch to logical view).
In setting up the authority file, I've assigned a wide variety of Unicode characters to many of our symbols. Some of these characters, however, have poorer font support, which may mean that they won't be properly displayed in some software environments. So alternatively, we could use just a smaller set of mapping equivalents: no mapping at all for some symbols (in which case the "name" from the authority file will be displayed), and undifferentiated mapping for some species and subspecies.

The symbol replacements spreadsheet has now been split into two separate worksheets. On the second sheet, called "taxonomy content", you can see what used to be the right-hand-side columns of the original sheet, summarising what the taxonomy says about each new token (no longer with absolute accuracy, since the authority file is now the master version). This sheet also shows the current mapping in the authority file, and next to it, a possible set of simpler mapping equivalents.

What I'd like you to do is to give your opinion (here in this thread) on whether we should simplify the mapping. If you think we should, please check through the two relevant columns of the table and see if you agree or would prefer to do something different. Comment in the google sheet. There are a number of sensible alternatives, e.g. we could remove mapping altogether for some or all of: florets, flourishes (i.e. gomūtras) and spirals.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions