Windows symbol fonts and Unicode

FontCreator - Font Editor FontCreator - Discussion
1

I have been using Font Creator to create and maintain Windows symbol fonts for some time.

If I view the glyphs with Unicode code points on the caption bars, then it appears that the characters (hex) 20-FF get translated to code points U+F020 to U+F0FF.

Now these are within the private use area of the BMP, and so this seems a not unreasonable place to put miscellaneous symbols. But is there any genera rule that Windows symbol fonts should translate into this chunk of the private use area, or is it a choice made by Font Creator because it is as convenient as any other?

[The reason I ask is that I’m considering abandoning Windows symbol fonts, with their limit of rather less than 255 characters, in favour of Unicode fonts where I plan to make heavy use of the private use area for miscellaneous symbols. And I feel I ought to understand what is going on here!]

David Webber
Mozart Music Software

2

Yes, Symbol fonts are almost obsolete now. It is far better to create Unicode fonts with symbols in the appropriate character sets and code-points assigned by the Unicode Consortium.

There are many symbols in the Miscellaneous Symbols character set, and those are the code-points that you should use if your symbols are the same or very similar.

There are many other character sets for symbols besides that one. Geometric Shapes, Letterlike Symbols, etc. What kind of symbols are you creating?

3

It is a collection of music symbols.

Now there is a Unicode ‘musical symbols’ area, but it is not well designed for my purposes. It is outside the BMP (U+1D100-U+1D1FF) which indicates possibly that it wasn’t thought overwhelmingly important, and tends to make it a pain to use by music notation programs. (And I know of none which use it.)

To draw music using it would require not just finding symbols from a font of a given size, but selecting symbols at different sizes, stretching some vertically but not horizontally, some horizontally but not vertically, creating mirror images of others, connecting them with ligatures, ... This may be possible with OpenType fonts (something I need to learn about), but a much easier approach is to use line-drawing code to put in straight line elements of varying length, and just write the glyphs from the font where they are needed. Trying to represent music by a sequence of characters alone (as you can do with text) just isn't going to work, and I think this is recognised by just about every music notation program in existence.

And different music programs have different sets of symbols which they need. For example I include the three clefs at the two sizes which are needed, using 6 code points in all, like upper and lower case CSXcsx even though the shapes might be identical. Other programs just have the larger set (analogous to CSX) and select the font at a smaller size when the smaller ones occur. OTOH other programs regard a clef with a little 8 or 15 drawn above or below it as separate clef symbols, resulting in 5 versions of essentially the same clef, whereas I just draw the 8 or 15 as separate glyphs. (The Unicode Musical Symbols area is intermediate: it has separate G and F clefs with 8’s, but not C clefs with 8’s, and none with 15’s.)
</music technical>

The upshot is that different programs disagree about what glyphs they consider fundamental, and which should be built up from two or more.

So my plan is to define the glyphs I need for Mozart (http://www.mozart.co.uk) in the private use area of the BMP, which seems to be what it is for. But that is U+E000-U+F8FF so I was curious to know if there’s a reason why Font Creator seems to map Windows Symbol Fonts (or mine at least) onto the 256 characters starting at U+F000 (about 2/3 of the way through if my hexadecimal mental arithmetic serves me).

Dave

4

It is a Microsoft rule. FontCreator is simply applying the Microsoft rule.

William Overington

20 August 2013

5

Please be aware that there are some application programs where one cannot access characters that are in the Private Use Area.

I have various projects where I make extensive use of the plane 0 Private Use Area.

However, sometimes I need to make, for want of a better term, a bodge font where the special characters are placed where glyphs for letters like a b c and so on should go. For example, for use with Serif ImpactPlus.

So it is a good idea to check that the application program can access Private Use Area characters. Many programs can these days, yet not all.

Also, it is a good idea to include some ordinary characters from below U+00FF as some application programs can go peculiar sometimes if there are no printing characters in that range in the font. I cannot justify that, just a note from my experience some years ago.

William Overington

20 August 2013

6

[Windows symbol fonts → U+F000-U+F0FF]

This is excellent news!

My music software has to find out a lot about the geometry of glyphs it is using, for which it uses the Windows API function GetGlyphOutlineA( ) and passes in the index of the symbol of interest in the Windows Symbol font in the range (0,255).

Now get GlyphOutlineA() is the old-fashioned ASCII version of the API: the modern Unicode one is GetGlyphOutlineW( ) with W for ‘wide (UTF-16) character’. I suspect that if I use that one on the old fashioned Windows Symbol Font, I’ll have to add the magic F000 to the symbol index which I supply to the function. Some experimentation will be necessary, but if that works, at least I can rely on it as being a Microsoft standard behaviour!

Dave

7

I’m not too concerned about programs in general. The fonts I’m supplying are for the music notation software I’ve written. (If anyone else can use them, then that’s fine, but it isn’t really a design consideration.) I am aware that I’m going to have to modify my code to handle this, but as long as I don’t have to venture outside the BMP it doesn’t look too hard!

It is one of my specific objectives to include the entire Latin character set (accented characters and all) as well as one or two others - like the flat sharp and natural signs from the miscellaneous symbols area. There’s an illustration at http://www.mozart.co.uk/information/illustrations/mozartjazzfont.htm.

In the upper piece of music, the text is drawn with my own Unicode text font “Mozart jazz Text” and the music symbols with my Symbol font “Mozart Jazz”. (Both done with Font Creator 5) The plan is to combine these (using Font Creator 7) into a single Unicode font with the symbols in the private use area.

In the lower illustration, the symbols are my “Mozart classic” font (originally written with an old program called Fontographer) but maintained for many years now with Font Creator), but the text is the standard Times New Roman. I want to combine these music symbols too with a suitable Unicode Latin text font, and I have just discovered ‘Google fonts’ which come with a free licence for you to modify and distribute them, under conditions which are easy to comply with. One of these will be ideal for the text glyphs. So it looks like all systems are go!

David Webber

8

[Windows Symbol Font character n → Unicode FF00 + n]

Magnificent! I can (in C++) draw a string of single byte characters from the Windows Symbol Font with the routine TextOutA() passing it a string of characters n1 n2 n3 … with each of the n’s in [0,255] - the old ASCI character code.

Using the same font, I can draw the same characters using the UTF16 version of the text drawing function TextOutW() by passing it a string of code points F000+n1, F000+n2, F000+n3 …

This bodes very well!

David Webber

9

Timestamped 19 Aug 2013 22:46

Timestamped 22 Aug 2013 12:47

The two are not the same. The first was correct for hex 20 through to hex FE, though I am unsure about for hex FF.

Microsoft used to use U+F001 for a fi ligature glyph and U+F002 for a fl ligature glyph.

Your project is very interesting.

If you find time to post items to the Gallery section of this forum that would be of great interest.

I cannot justify this, but when I use the Private Use Area I tend to avoid U+F000..U+F0F just in case some software packages might make some assumption about the application being something about a Symbol font. Just me maybe, but I thought that I would mention it.

William Overington

22 August 2013

10

Sorry, I was speaking rather loosely. The first point I even consider is exactly hex 20. There are other points which should apparently be avoided in Windows Symbols Fonts. Here’s a comment from my code (with decimal character numbers):

// NB Do not use positions 127 or 160 (see Fontographer 4.1 manual p173)
// Now also do not use positions 127,128,129,141,142,143,144,157,158,160
// (see Macromedia knowledge base).

I have to confess that I started the Windows Symbol Font around 1991 when TrueType came out in Windows 3.1. It’s probably sacrilege around here but I used a program called Fontographer which I really liked. But it seems it was given up by its authors to a company called Macromedia. All development appeared to stop, they regarded it as a ‘cash cow’ I think, and it never AFAI-Knew-Until-A-Moment-Ago-When-I-Checked made it out of the world of 16 bit computing. Anyway the above information came from the manual and support forum.

[I see the Wikipedia article on it says ‘development was halted from 1991-2006’ (15 years!!!) so maybe it has been resuscitated, but in the mean time I discovered Font Creator, with which I am sufficiently impressed that I feel no desire to go back! ]

Anyway, the upshot is that I avoided (decimal) code points 0-31, 127,128,129,141,142,143,144,157,158,160 (and am nervous of 255!) leaving 213 of the possible 256 slots. And I filled most of them, so it’s definitely time to go to Unicode!

Your project is very interesting.
If you find time to post items to the Gallery section of this forum that would be of great interest.
I cannot justify this, but when I use the Private Use Area I tend to avoid U+F000..U+F0F just in case some software packages might make some assumption about the application being something about a Symbol font. Just me maybe, but I thought that I would mention it.

Well my font is a Symbol font at the moment, but the replacement Unicode font will use a selection from U+E000 to about U+E400 initially. My thoughts were vague but not entirely different from yours :slight_smile:

I’m new around here (though not to Font Creator) and I didn’t know about the gallery. I’ll take a look and consider what I might add.

David Webber

11

I’m aware I’m a bit late with my reply, but better late than never…

To switch your current Symbol font to Unicode, do select Tools → Convert Font → Convert to Unicode Font. That should at least ensure the code points and several internal settings are converted.

12

Thanks! But I suspect this will be problematic.

At the moment I am leaving the font completely unchanged, and have simply changed my program which accesses it. Sorry if the following is rather Windows-specific but…

I am still loading the font with CreateFontIndirect() and providing a LOGFONT structure, with the face-name and (importantly) the character set defined as SYMBOL_CHARSET. But previously I output the symbols with an ASCII version of the text drawing API passing it characters 0x20-0xFF. Now I’ve changed it to use the Unicode version of the text drawing API and passing it Unicode points U+F020-U+F0FF. This works perfectly.

And importantly, it means that I haven’t actually touched the font, and so I’m in no danger of breaking earlier versions of my program which use the same font! I suspect that if I converted the font to Unicode with the method you suggest, I’d also have to specify DEFAULT_CHARSET to load it. [That turned out to be necessary to start using my embryonic new Unicode font with symbols stored in U+E000 onwards.]

This change from referencing ASCII 0x20-0xFF to Unicode U+F020-U+F0FF in the Symbol font, is just an interim step in my current developments: ultimately the development version of my program will dispense with the Symbol font, and use my new Unicode font instead: but I have a bit more work to do before that can happen!

Dave

13

Sounds logical to me. In the past we made ot way to easy for people to make Symbol fonts. Now we still support it, but it is more hidden.