Ornaments and Unicode

Max Phillips

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?

John Hudson

The number of purely ornamental characters in Unicode is pretty small; most have some kind of symbolic function.

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.

Max Phillips

Thanks, John. This is really helpful.

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?

John Hudson

A separate ornament font definitely isn't a dumb idea.

Max Phillips

John Hudson told me I wasn't dumb!  My day is improving.

Michael Jarboe

Is there a best feature to use if you want to use OpenType key/letter combinations to make symbols/ornaments. I feel like I've seen fonts where certain key combinations combine to make arrows, etc. but can't recall what OT Feature they utilize for this.

Ray Larabie

I released a comic book typeface this year with ornament shortcodes. I figured the kind of people using it probably aren't typographers but would be likely to use ornaments quite a bit.

((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.

John Hudson

Care should be taken not to confuse key combinations with character or glyph combinations. Keystrokes, like other input systems, are entirely arbitrary mechanisms to input character codes, either individually or multiple characters. The character codes are then mapped to default glyphs via the font cmap table, and then OpenType Layout GSUB features and lookups map to variants, ligatures, or decomposed elements. So OTL is happening two steps removed from input.

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.

Max Phillips

Ray, I thought shortcodes were just a WordPress thing. Are they more broadly applicable?

María Ramos

You could also use the unicode values for geometric shapes http://www.unicode.org/charts/PDF/U25A0.pdf

Kent Lew

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 →.

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.)

Florian Hardwig

Frequent users of arrows and other characters that are hard to input via the keyboard should better set up such shortcuts as text replacements, be it via the System Preferences in OS X (Keyboard → Text) or third-party tools like Typinator, TextExpander etc. I’m sure there are similar tools for other platforms, too.
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 –›.

John Hudson

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.

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.

Erwin Denissen

I agree with John; in general avoid using substitutions (and if you do there is no point in duplicating a glyph for this purpose) to provide easy access to characters with semantic value.

Ray Larabie

@Max Phillips  I borrowed the shortcode term from Wordpress; I like the sound of it.