Does anyone have a good list of unicode values for ornaments, dingbats, piece borders, and other non-type glyphs? The ones I'm Googling all seem pretty thin.
Related: what are best practices for adding ornaments to a typeface when they have no unicode values?
0
Comments
There is, of course, the Ornamental Dingbats block, the original Dingbats block, which contains both ornaments and symbols.
With regard to unencoded ornaments, much depends on how you anticipate them being used. Some font makers like to have ornaments accessible via standard keyboards, so prefer to map them to alphabetic characters via the Ornaments feature. Of course, this presumes that the feature is accessible in software, which is neither a safe assumption nor a robust one. Personally, I think it makes sense to apply Private Use Area codepoints to ornament glyphs, and recommend to users to access the glyphs in this way (even if also mapped to ASCII characters in the Ornaments feature). Yes, this means having to use glyph palettes or character insert tools, rather than the standard keyboard, but means that the ornaments stand some chance of surviving text interchange across applications.
Not sure how to think about the question of how I anticipate the ornaments being used—is there more than one way? I do want to make it easy to compose borders and cartouches out of modular pieces, as in the old metal days.
Part of me wants to go old school and add a separate ornaments font to the family, and map the ornaments (and especially the border pieces) to letters and numbers for easy access thru single keystrokes: a, b, c, 1, 2, 3. The pdf specimen would provide a keyboard layout, and when the pdf went missing, the glyph palette would serve as backup. This is probably a dumb idea, but can you tell me why it's dumb?
((swirl)) a coil...handy for obfuscating curses
((zigzag)) an angry vertical scribble
((skull)) a skull and crossbones (solid version in the bold styles)
((scribble)) a criss-cross scribble
((cloud)) a white cloud with lightning (black cloud in the bold styles)
((scrawl)) or ((scribble2)) = a long, horizontal scribble. (angrier in the bold styles)
((lightning)) a lightning bolt (solid version in the bold styles)
((!!!)) A cluster of three heavy exclamation points (solid version in the bold styles)
((knife)) a dagger (solid version in the bold styles)
((star)) a big star (solid version in the bold styles)
((star2)) a medium star (solid version in the bold styles)
((star3)) or ((stars)) two small stars (solid version in the bold styles)
I coded it so it'll work in a dozen languages. If you type ((crâne)) instead of ((skull)) and you'll get the same result.
As a general rule, if an element of text has any semantic value then it should be encoded in the text with an appropriate Unicode character code. So I think it is a mistake for fonts e.g. to use GSUB to map the sequence - > to an arrow glyph, rather than using the arrow character code →.
If an element of text does not have semantic value, e.g. an ornament, or is not suited to standard character encoding, e.g. a logo, then really it doesn't matter what mechanism is used to input, store or display that element.
I respect what John is saying, but this is a popular approach. I believe {dlig} is a reasonable feature for this.
To provide such a shortcut and still respect underlying encoding, as John advocates, one could duplicate the encoded uni2192 (arrowright) glyph as unencoded uni002D_uni003E and use the latter as the replacement for the {dlig} substitution.
(I suppose hyphen_greater would probably also be an acceptable AGLFN name.)
This not only avoids messing with the semantics of the underlying text layer. It also works system-wide and independent of OpenType support, and one doesn’t have to memorize which font used —> and which one –›.
Since the only purpose of the parseable glyph names is Acrobat text reconstruction from GIDs in PDFs distilled from print streams, and presuming that the arrow glyph exists in the document because the author wanted an arrow glyph, I think the duplication is unnecessary, and that if one feels one must use {dlig} in this way, then the best thing to do is to map directly to the /uni2192/ glyph.