Glyph Names I can understand

[Mike Thompson]

I have created about a dozen Open Type fonts using microsoft VOLT.
The scripts for Open Type features all contain glyph names of my own choosing such
as alefmapiq for the Unicode HEBREW LETTER ALEF WITH MAPIQ.
The name of the glyph in Font Creator was uniFB30 but I did not mind
as I did not use it.

Now with Font Creator V7, I have to use the uniFB30 or change it.
This is because the glyph name identifies a glyph in the Open Type script.
I want the Open Type scripts to be readable (by me) so I will definitely change
the glyph names. This is also important as most of my fonts share their Open Type
scripts with other fonts.

Changing the glyph names by hand on a dozen fonts is onerous!
Is there an easier way of doing this?
Mike

[Bhikkhu Pesala]

Change them on one, then copy, paste special.

[Erwin Denissen]

I like the idea of making this easier. Since we will improve glyph naming next week this might be something to think about as well.

No garantuees but lets talk about this some more early next week.

[Erwin Denissen]

I'm sorry but we were too busy this week. I will contact you early next week.

[Mike Thompson]

It would be good to be able to import and export the glyph names together with their Unicode values.

I have no experience (yet) of dealing with glyphs that do not have Unicode values.

I had a problem with a VOLT file that was indexed by Glyph number. Adding a new glyph in the
middle of the file involved hand editing of all the glyph numbers for the glyphs following the
inserted glyph. That was not nice!

I look forward to some kind of solution to these problems.
Mike

[William]

Suppose that FontCreator 7 were to have the following two facilities added to it: would that solve the problem?

1. Import a postscript and code point file.

The font designer selects a number of cells in the overview window.

Import postscript and code point file
FontCreator 7 would ask for a file name, a text file.

The file is read.

If, say, 50 cells are highlighted and the file has 50 lines, then the postscript name if any) and the code point (if any) on line 1 of the file is assigned to the first highlighted cell, the postscript name and the code point (if any) on line 2 of the file is assigned to the second highlighted cell, and so on, for all 50 cells.

If, say, 50 cells are highlighted and the file has 40 lines, then the postscript name (if any) and the code point (if any) on line 1 of the file is assigned to the first highlighted cell, the postscript name and the code point (if any) on line 2 of the file is assigned to the second highlighted cell, and so on, for the first 40 cells: the remaining cells are unaltered.

If, say, 50 cells are highlighted and the file has 60 lines, then the postscript name if any) and the code point (if any) on line 1 of the file is assigned to the first highlighted cell, the postscript name and the code point (if any) on line 2 of the file is assigned to the second highlighted cell, and so on, for all 50 cells: the information on the last 10 lines of the file not being used.

2. Export a postscript and code point file.

The font designer selects a number of cells in the overview window.

Export postscript and code point file
FontCreator 7 would ask for a file name, a text file.
If the file does not already exist then the file is generated or, if the file does already exist then the font designer is asked if the existing file can be overwritten.

The file is written.

If, say, 50 cells are highlighted then the file has 50 lines. The postscript name (if any) and the code point (if any) of the first highlighted cell is written to line 1 of the file, the postscript name (if any) and the code point (if any) of the second highlighted cell is written to line 2 of the file, and so on, for all 50 cells.

----

Format of each line of the postscript and code point file.

Each line of the file can be of one of four formats. Here shown for a cell with a glyph of a ct ligature using ct as the example postscript name and U+E707 as the example code point.

ct $E707

ct

$E707

blank, that is nothing at all, not the word blank as such

----

The text file could be produced or edited in WordPad or Notepad if so desired.

Would this facility solve the problem? Or could the above idea be improved at all and a better specification produced?

If so, such a facility could be requested in the FontCreator - Requests and Enhancements section of this forum.

William Overington

18 May 2013

[Bhikkhu Pesala]

Kerning data files are tab delimited text files like this:

Kerning Pair, Kerning Value, Name of Left glyph, Name of Right glyph
“M -267 quotedblleft M
“O -65 quotedblleft O
“Q -65 quotedblleft Q
" -100 onequarter.afrc quotedbl
" -100 onehalf.afrc quotedbl

Glyph Names could be stored in a similar way.
To make the glyph index order unimportant store the codepoint and the glyph name.

Codepoint, Glyph Name
77 M
78 N
79 O
80 Q
8220 quotedblleft
58188 onequarter.afrc
58189 onehalf.afrc
58190 threequarters.afrc

Unmapped glyphs would have to be stored as glyph indexes

Glyph Index, Glyph Name
#2327 sunrise
#2328 newmoon
#2336 a.subs
#2337 b.subs
#2338 c.subs

[William]

Thank you for replying.

Kerning data files are tab delimited text files like this:

I have never liked things with the tab character in them. If I try to edit them in a text editor they tend to go all over the place: maybe it is just me, but I tend to avoid the tab character whenever I can.

To make the glyph index order unimportant store the codepoint and the glyph name.

Unmapped glyphs would have to be stored as glyph indexes

That is the balance.

The problem is then what happens if one needs to add an extra glyph earlier in the font as the glyph indices would then change. I was trying to get away from using glyph index at a global level in the font.

Also, although I did not mention it, I had in mind the possibility that such a postscript and code point file could be shared in a forum post. For example, one could then have a postscript and code point file for blackletter ligatures, such as ba be bo da de do ha he ho etc where most, maybe all, of the lines in the postscript and code point file would not have a code point.

There could perhaps also be a file of OpenType code to go with the postscript and code point file.

I had started by just using postscript names for the import data, then added the possibility that some of the cells would have a Unicode code point assignment as well.

When it came to the export of the data, I felt that I needed to cover every possibility that could arise.

William Overington

18 May 2013

[Erwin Denissen]

With the latest version we added two file into the FontCreator installation folder.

Glyphlist and glyphnames

They are used when importing and exporting fonts.

I'll go into more detail on Tuesday, but feel free to make changes. A restart of FontCreator is required. Then open a ttf or otf to see the results.

[Bhikkhu Pesala]

Thanks for the update. That explains the odd spelling of Lambda a.k.a. Lamda.

Code: Select all

039B;Lambda;GREEK CAPITAL LETTER LAMDA

I suspect this will do just what we're asking for when we figure it out. This is presumably what is referred to as "Smart Glyph Naming" in the Maintenance Release Announcement.

[Erwin Denissen]

We weren't sure which one is correct. Lambda is decribed here:
http://en.m.wikipedia.org/wiki/Lambda

3BB also mentions it:
http://www.unicode.org/charts/PDF/U0370.pdf

Should it be changed back to lamda?

[Bhikkhu Pesala]

Since the UnicodeData.txt file also contains both spellings, I suspect that you have done it right. Presumably "Lamda" is a legacy spelling, while "Lambda" is now the accepted spelling.

[vanisaac]

"Lambda" has always been the preferred Unicode spelling. However, when it was unified with ISO 10646 for Unicode v 1.1, some spellings were changed to "Lamda" for compatibility with source code pages.

[Bhikkhu Pesala]

With the latest version we added two file into the FontCreator installation folder.

Glyphlist and glyphnames

The are used when importing and exporting fonts.

I'll go into more detail on Tuesday, but feel free to make changes. A restart of FontCreator is required. Then open a ttf or otf to see the results.

I opened a TTF and found no change to the names. Euro was named as "uni20AC" and clicking the button on the Glyph Properties toolbar made no change.

I then exported it to TTF (without default OpenType features) and OTF (with them), and reopened those fonts. For both, "uni20AC" was now renamed as "Euro", but clicking the button on the Glyph Properties toolbar renamed it to "uni20AC."

I think, if the name is going to be changed automatically on export, then it should change on import and when using the Glyph Properties toolbar too.

[Erwin Denissen]

We need to include the Euro indeed. Thank you for letting us know.

For now you could manually add it to the glyphnames.dat file.