Incorporating custom character declarations
The GlyphPicker plugin gets its input data from the contents of a TEI file's <charDecl>
elements. In order to provide custom
character declarations, create a TEI file containing all the character declarations and add a new entry in the plugin's
settings dialog. Provide a reference to your TEI file in the field Path to Character Declarations
.
For example files containing multiple character declarations, see the ENRICH gBank (get the ZIP file) and the SMuFL-Browser.
The plugin maps the content of the <charDecl>
elements in the following way:
The content of the
<desc>
child element is interpreted as the 'range' description of all characters defined in that<charDecl>
. If you want to distinguish between different ranges, put your characters in separate<charDecl>
elements, and provide the name of the range in the<desc>
child element.Each
<char>
or<glyph>
child element is interpreted as a separate character / glyph declaration. Anxml:id
on<char>
and<glyph>
is necessary to provide an id reference to the character declaration in the plugin's XML output.The character name is read from the content of the last ancestor element with the name
desc
,charName
orglyphName
When a
<charProp>
element containing a child element<localName>
with the valueentity
is present, the text content of the following child element<value>
gets written to the "entity" field.As described in the TEI Guidelines, the
<mapping>
child element of<char>
/<glyph>
"contains one or more characters which are related to the parent character or glyph in some respect, as specified by the type attribute" (see guidelines, mapping). The TEI schema allows single character / glyph declarations to contain multiple<mapping>
child elements, but font-based character rendering in the GlyphPicker plugin depends on a single mapping. If there are multiple mappings in the character declaration, it's necessary to specify which one to use for rendering in the GlyphPicker settings dialog. Mappings can be selected by providing a@type
or@subtype
attribute (or both). If there are multiple<mapping>
elements matching the criteria, the plugin only takes the first one into account. If the@type
or@subtype
field is empty, it will not be taken into account.The content of the
<mapping>
element may either consist of characters and numeric character reference like
or of unicode code point references likeU+E002
. The first one requires the "parse mapping/text()" option to be unchecked; the second needs it to be checked. There is basic support for<g>
references in<mapping>
, allowing to declare characters composed of other characters declared in the same file. When text content is provided in a<g>
element, the plugin includes the text content instead of evaluating the reference target's character mapping.If you want to render characters as bitmap images, add a
<graphic>
child element to<char>
/<glyph>
and put the absolute or relative graphic path into the@url
attribute. Relative paths are assumed to be relative to the XML file containing the character declarations. (If you intend to extract glyph images from a font file, theotf2png
converter used in the SMuFL-Browser project might be helpful.)
Extending the plugin's TEI data mapping capabilities should be simple in most cases; for additions / modifications, please send a feature or pull request at https://github.com/richard-strauss-werke/glyphpicker.