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

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

http://origin.myfonts.com/s/aw/original/99/0/50807.pdf

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.

Gabriel

Gabriel,

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.