Encoding for frames, borders, ornaments

bichoverde's picture

Hello people of typophile!

First of all, english is not my native language, so i hope not to make too much mistakes in my communication! I've been a reader of the forum for years, and by now I thought that my first post would have been for the release of a typeface, but nope.. not yet...

I'm designing a display typeface and I want to include a small set of ornaments, many of them to build frames, borders, divisions and patterns. So for example, let's say i have 4 glyphs that make for the corners of a frame (top left, top right, bottom left, bottom right) and the glyphs for the borders between the corners; then, is there any common disposition of them in the keyboard? I couldn't find info for this. Tried to find user's guide from the foundries explaining to the final user how to build the borders using fonts like that. I don't own any font of the kind.

Maybe there is some common used encoding for these symbols. Besides frames and borders, I have tiles for making background patterns and decorative elements for the begining and end of a text line.

I hope someone could point me in the right direction, and hope i wasn't confusing so you can understand me!

Greetings and thanks for reading.


Theunis de Jong's picture

I don't think there are any rules, per se, for ornaments & borders. There are a lot of discussions, though.

There used to be an Opentype feature for Ornaments, but I think there is so little support for it, it quietly got ditched. See Open Type Ornaments in Indesign? (How to) for some sample OTF code for this (and additional remarks on using them in InDesign), and Opentype Access to unencoded ornaments & dingbats for comments on a designer with the same question.

As for encoding, you can (a) use 'alternates' for various characters -- a..z, for example -- to 'switch on' your borders, (b) use a single alternate to access all of them -- the bullet seems to be Adobe's preferred catch-all --, although this has various related drawbacks (esp. when using InDesign -- see Adobe Forum: Opentype ornaments for a complaint related with this method), or (c) assign unique Unicodes to your ornaments (it's up to you whether or not to assign unique Unicode codes, as this has no effect on any Opentype features you might want to add to support your ornaments).

If you do assign Unicodes, then use the PUA range for this. If an application does not support the OTF feature you use, and you did not assign Unicodes, there is no way to get your borders into a document!
The PUA range is the "Private Use Area" (or sth. similar); you can assign whatever character you like to the code range U+E000..U+F8FF. Adobe's Thomas Phinney's (2006) thoughts on using the PUA for ornaments (Eliminate Private Use Encoding in Revised Fonts?):

About the only thing we’d use PUA for in new fonts would be ornaments or dingbats that really don’t have their own codepoints.

.. followed by a list of comments six times longer than his thoughts ;-)

oldnick's picture

Tried to find user´s guide from the foundries explaining to the final user how to build the borders using fonts like that. I don´t own any font of the kind.

Here’s one way to do it...


bichoverde's picture

Thank you both for your replies! I feel like a dork for using the word 'coding'. I edited the post, changed it to 'encoding'. Thanks Theunis.

Interesting Nick, I guess it's up to the designer then to choose the "logical" way to arrange the elements in play, so it makes some sense for the user.

Somehow I thought that every alternate had to be be placed in the PUA, those kind of things you learn once and repeat forever.
Reading Theunis reply makes me realize it's taken for granted that these ornaments should be included in the one and only final OTF file. But, I wonder: is it anachronistic to deliver the borders and ornaments in a separate file? Is it a "don't" by today standards? Otherwise I feel those treats would be kinda buried in the font, which will probably have its own set of alphabetic alternates as well.

Thanks again.


JamesT's picture


The nice thing about having them in the same font is that it would be one less font to worry about. Not to mention the fact that most of the separate fonts use code points assigned to other symbols (i.e. a = left upper corner), if the font is changed, than the characters are changed. Also, if the characters aren't converted to outlines, I assume, the final output (if it were a PDF), would have the borders be searchable characters in the document.

Also, if it's in the same font, you can use the CALT or one of the SS features to transform something like "<---~~-->" into an ornament.

I'm working on this issue myself as I'm making my first typeface which includes borders. I'm planning on keeping the ornaments in the same font and use the CALT method. I'm not sure if I'll be using the PUA or not, once I've done some more testing I'll make that decision.

Syndicate content Syndicate content