thanks. I see some font has .notdef at u10000, a rectangle with a question mark inside. Now, I have more questions with these keys: Nul, Tab, Esc, Backspace, Insert, Delete, Shift, Alt and Ctrl keys. Where they are and what is their code numbers? Is GID 0 NULL character? Can I use which of them in the font? and how? Thanks
As noted by @André G. Isaak above, this is incorrect. It should be unencoded
> Is GID 0 NULL character?
Noo, the .notdef glyph should be at GID 0. (Again, André is correct.)
> these keys: Nul, Tab, Esc, Backspace, Insert, Delete, Shift, Alt and Ctrl keys
None of these require glyphs in a font, and most apps treat these characters as non-marking control characters and will not render them even if they are present. (Nul has a bit more history, but is also not needed.)
I am still confused with .notdef. See images above that even Microsoft System fonts have two different use of that slot GID 0. In Arial font, it is used as .notdef and placed a rectangle and in Calibri it is used as NULL with 0 width glyph. So, it is valid usage in both? Other things were that in Arial font most of beginning slots assigned for control characters were removed but not in Calibri. I thought we should not touch these slots. So, which font is implemented correctly in here? But my main question is - GID 0 is for .notdef or NULL? I am very grateful for all your teaching/helping me here. Thanks
I'm not familiar with the font editor you're using to display the above images, but I have a suspicion that the first image is displaying glyphs sorted by GID and the second is displaying them sorted by unicode value. NULL should have a unicode value of 0 and a GID of 1.
I use FontForge and both fonts are displayed in Unicode. So, GID 0 = -1 in Unicode? Yes it is, see image. But it is placed at U+10000 slot. So, it is correctly implemented in Calibri, then?
It doesn't matter what order FontForge displays your glyphs in: it will order them correctly when you generate a font, with .notdef first.
When FontForge displays -1 in the "Unicode Value" field of the "Glyph Info" dialog, that means the glyph is unencoded. Not that the Unicode value is actually -1: that's just a placeholder number that FontForge uses for all unencoded glyphs. It means that in the generated font there will be no mapping of that glyph to a Unicode value in the cmap table.
Another thing about your image, @WAY KYI. There are two numbers displayed at the top of the Font View window, just below the menu. The first, reported in both decimal and hex (for .notdef, it's 65536 (0x10000), has to do with how Fontforge orders glyphs internally. It has nothing to do with the Unicode value, and it doesn't have to match the order of glyphs in the generated font.
The other number is the Unicode value, here reported as U+????. That means the same thing as -1 in the "Unicode Value" field of the "Glyph Info" dialog"--that is, no encoding at all for the .notdef glyph.
I'm not familiar with the font editor you're using to display the above images, but I have a suspicion that the first image is displaying glyphs sorted by GID and the second is displaying them sorted by unicode value. NULL should have a unicode value of 0 and a GID of 1.
So, where do you create .notdef with rectangle with question mark inside? So, GID 0 is where? Sorry, I am confused with GID and Unicode. Now I know they are two different things. Can you point me to any reading about GID? Thanks
Another thing about your image, @WAY KYI. There are two numbers displayed at the top of the Font View window, just below the menu. The first, reported in both decimal and hex (for .notdef, it's 65536 (0x10000), has to do with how Fontforge orders glyphs internally. It has nothing to do with the Unicode value, and it doesn't have to match the order of glyphs in the generated font.
The other number is the Unicode value, here reported as U+????. That means the same thing as -1 in the "Unicode Value" field of the "Glyph Info" dialog"--that is, no encoding at all for the .notdef glyph.
Thank you very much for your explanation. I always thought ( 0xNumbers ) is same as U+????. I never went over PUA and that is the case. So .notdef won't be encoded in Calibri, right? So where do you encode .notdef and which slot to use? Sorry bear with me and please help me get it right. Thanks
You don't have to worry about where .notdef goes: Just let FontForge put it anywhere.
Do this: on the Encoding menu, choose "Add Encoding Slots," and enter the number 1 when prompted. This creates (despite the name of the menu item) an unencoded slot. Scroll (if necessary) to the very bottom of the font view window: the slot you created will be the very last one in the font.
Open the glyph and draw what you want apps to display when a character is missing. Then open your character info dialog, name the glyph .notdef, and you should be done. FontForge will do the right thing with the glyph when it generates the font.
The GID is simply the index number of the glyph in the font. The first glyph is 0, the second 1, and so on, to the end of the font. Software uses it to retrieve glyphs from the font. The Unicode number is the encoding assigned to a character by the Unicode Consortium. A character's GID may be different from font to font (except for those first few GIDs). The Unicode number, on the other hand, is always the same. A text is a sequence of Unicode numbers. An application displays or prints text by looking up the Unicode number in the cmap table, getting the GID there, and using that to retrieve the glyph from the font.
GID = Glyph ID = the numerical index of glyphs stored in the font’s glyf table (TTF) or CFF/CFF2 table. The count starts at zero, and both the TrueType and OpenType specifications require that the first glyph, GID 0, is /.notdef/.
It used to be the case that glyph ordering in fonts could be largely arbitrary, since users would be interacting with the glyph set only via character (encoded glyph) input and layout features, and the only people who ever looked at the GID order would be the people who made the fonts. When Adobe introduced glyph palettes in InDesign and Photoshop etc., and allowed for these to be displayed by glyph order, it became more useful for font makers to manage glyph ordering, so that users can be presented with some kind of inituitively ordered set within which to search visually. Tidily managed glyph order is also helpful when collaborating on font development, or when making open source projects that may get extended or modified by other people.
I don’t know enough about FontForge to advise on how to manage glyph order in that program. In Glyphs, the glyph order can be specified as a simply comma separated list of glyph names within the .glyphs source file. In FontLab, glyph order is managed via .enc files, which are plain text list stored as user resources.
Interesting. I thought GID was still pretty arbitrary and didn't know it made any difference in how glyphs were displayed in palettes. I don't think FontForge gives you a way to control the order. For a while (back when I used FontForge) I did that via the Adobe Font Development Kit, but I gave it up because I couldn't see the point. But maybe there is one.
It's definitely worth sorting the glyphs sensibly if possible. As a user, I always find it aggravating when the glyph palette has characters scattered around in random order. For encoded glyphs, unicode order is generally fine , though grouping by script also makes sense. For unencoded glyphs, I prefer these to be grouped together sensibly (i.e. all small caps together, ligatures together, swash characters together, etc) and alphabetized within groups (or sorted numerically for alternate figures).
Note that I rarely enter characters/glyphs via the glyph palette. But it's extremely useful for getting an overview of what's available in a given font.
I've found lots of fonts where all glyphs are sorted alphabetically by glyph name. This is particularly irritating since figures and punctuation are scattered throughout, ß comes next to g, etc.
I've found lots of fonts where all glyphs are sorted alphabetically by glyph name. This is particularly irritating since figures and punctuation are scattered throughout, ß comes next to g, etc.
I think I used to do this. Quite right: it made no sense at all.
Wow... this is so nice of you guys for your helping hands. Now I am a lot smarter So, what I did was, I went back to FF and found something about CID ( but very buggy and crashes me doing things there ). So, I am ok now with knowing how to create a .notdef and not worry about it any more. Thanks
While not familiar with FontForge, I suspect that the CID option you found is most likely for creating CID-keyed fonts. CID-keyed fonts are used for Chinese/Japanese/Korean fonts.
CID-keyed fonts are a special Postscript font format for efficient packaging of East Asian characters by having the character encoding and name data stored externally to the font and mapped from the glyph index order. So yes, GID is important to CID, but they are not the same thing. If FontForge is able to make CID-keyed fonts, though, that suggests there is some way to manage glyph order.
Do not attempt to use FontForge to make CID-keyed fonts. (Well, of course, we cannot demand you do or not do anything, it's free software, so this is just a strong recommendation hehe.)
CID-keyed fonts are a legacy font format, including
so-called "SFNT-wrapped" CID-keyed fonts. Of course, we still will merge
code that fixes them, but making new ones (especially) is not a
development priority.
To use a CID-keyed font as the base of a new font, you should flatten it first. See №3955 for more information.
There is truly nothing but misery to be experienced for using FontForge for anything but flattening a CID-keyed font. The code is very buggy, I have no idea why George thought his implementation of certain functions would be better than no function at all.
Do not attempt to use FontForge to make CID-keyed fonts. (Well, of course, we cannot demand you do or not do anything, it's free software, so this is just a strong recommendation hehe.)
Hi Fredrick, thank you very much for your info. First, I love FF very much not that it is FREE but its workspace and navigations are simple, clean and not clustered. The best thing is Opentype features are so easy to create without knowing a thing about scripting. I used Fontographer ( long time ago ), FontCreator, VOLT and other for Opentype features and I was confused a lot in there. The UI of FF Lookups are so easy and I created Ligatures, Stylist Alternatives, Aalt, Marks and Kerning classes in no time without needing to know about how to code them in scripting. That is the best of FF. FF developers also helped me a lot there too with my silly or naïve questions. I recommend friends to FF not only it is FREE but also it is so easy to master those high-end font functionality. It certainly is the best for first learner like me with type creation. Please keep up the good works.
The format looks fairly straightforward, although more complex than that for FontLab where Unicode mapping and glyph order are managed in separate files, making the latter a super simple list of glyph names. [FontLab also gives users the ability to drag and drop glyphs into a specific order in one font window mode, which is great.]
Getting back to the original /.notdef/ topic, I am guessing that FontForge might have code that automatically locates a glyph with that name at GID 0?
Possibly a silly question, but why is glyph order within the binary font something that designers expect to control? There are both cmap and layout (coverage table) optimisations available by reordering the glyphs and assigning different GIDs and thereby getting different table formats. Is it about order in character pickers?
Possibly a silly question, but why is glyph order within the binary font something that designers expect to control? There are both cmap and layout (coverage table) optimisations available by reordering the glyphs and assigning different GIDs and thereby getting different table formats. Is it about order in character pickers?
Character pickers can be a reason, yes. InDesign character palette can be sorted by unicode index or by GID. The latter can be much easier to navigate when the font contains lots of unencoded glyphs -- such as sets of numerals -- that can be grouped together in a custom order.
Another reason for us is proofing tools that use glyph order to display all glyphs in a font. We always create specific glyph layouts for all our fonts, and it is a great help to see all glyphs in the same order in our editors as in our proofing tools.
It is about that, but also it can help during development. When I was using FontLab, I mostly worked in the Index view since I could rearrange the glyphs in a way that made sense to me, with related glyphs near each other, rather than in some encoding or Unicode order in which they are not. Glyphs can do this too, but its default way of displaying the glyphs in a font is also logical. I still like to control it for the character pickers even in Glyphs.
The order in the font editor does not need to match the export order, but keeping the same order in both cases makes it easier to navigate and proof an exported font file. So while GIDs could be reorganized on export for a smaller cmap table, the size benefits were never significant in my tests.
I can imagine a compressed export option that would be enabled for webfonts or similar environments where byte count is paramount.
The format looks fairly straightforward, although more complex than that for FontLab where Unicode mapping and glyph order are managed in separate files, making the latter a super simple list of glyph names. [FontLab also gives users the ability to drag and drop glyphs into a specific order in one font window mode, which is great.]
Getting back to the original /.notdef/ topic, I am guessing that FontForge might have code that automatically locates a glyph with that name at GID 0?
Just to report all of you that, there is auto GID function in FF. When you do it thru this menu Encoding/ re-encode / Glyph Order. It creates GID view with GID 0 = .notdef and GID 1 = NULL and so on. Thanks
There's one situation I deal with where I need to control the glyph order: fonts for closed caption systems for North American television sets. Some chipsets still require a specific CCTV encoding from the 1970's.
Comments
As noted by @André G. Isaak above, this is incorrect. It should be unencoded
> Is GID 0 NULL character?
Noo, the .notdef glyph should be at GID 0. (Again, André is correct.)
> these keys: Nul, Tab, Esc, Backspace, Insert, Delete, Shift, Alt and Ctrl keys
None of these require glyphs in a font, and most apps treat these characters as non-marking control characters and will not render them even if they are present. (Nul has a bit more history, but is also not needed.)
Shift, alt, control, etc. aren't even characters. They're keys which allow you to make other characters. :-)
I am still confused with .notdef. See images above that even Microsoft System fonts have two different use of that slot GID 0. In Arial font, it is used as .notdef and placed a rectangle and in Calibri it is used as NULL with 0 width glyph. So, it is valid usage in both? Other things were that in Arial font most of beginning slots assigned for control characters were removed but not in Calibri. I thought we should not touch these slots. So, which font is implemented correctly in here? But my main question is - GID 0 is for .notdef or NULL? I am very grateful for all your teaching/helping me here. Thanks
It used to be the case that glyph ordering in fonts could be largely arbitrary, since users would be interacting with the glyph set only via character (encoded glyph) input and layout features, and the only people who ever looked at the GID order would be the people who made the fonts. When Adobe introduced glyph palettes in InDesign and Photoshop etc., and allowed for these to be displayed by glyph order, it became more useful for font makers to manage glyph ordering, so that users can be presented with some kind of inituitively ordered set within which to search visually. Tidily managed glyph order is also helpful when collaborating on font development, or when making open source projects that may get extended or modified by other people.
I don’t know enough about FontForge to advise on how to manage glyph order in that program. In Glyphs, the glyph order can be specified as a simply comma separated list of glyph names within the .glyphs source file. In FontLab, glyph order is managed via .enc files, which are plain text list stored as user resources.
Note that I rarely enter characters/glyphs via the glyph palette. But it's extremely useful for getting an overview of what's available in a given font.
I've found lots of fonts where all glyphs are sorted alphabetically by glyph name. This is particularly irritating since figures and punctuation are scattered throughout, ß comes next to g, etc.
CID-keyed fonts are a legacy font format, including so-called "SFNT-wrapped" CID-keyed fonts. Of course, we still will merge code that fixes them, but making new ones (especially) is not a development priority.
To use a CID-keyed font as the base of a new font, you should flatten it first. See №3955 for more information.
The format looks fairly straightforward, although more complex than that for FontLab where Unicode mapping and glyph order are managed in separate files, making the latter a super simple list of glyph names. [FontLab also gives users the ability to drag and drop glyphs into a specific order in one font window mode, which is great.]
Getting back to the original /.notdef/ topic, I am guessing that FontForge might have code that automatically locates a glyph with that name at GID 0?
Character pickers can be a reason, yes. InDesign character palette can be sorted by unicode index or by GID. The latter can be much easier to navigate when the font contains lots of unencoded glyphs -- such as sets of numerals -- that can be grouped together in a custom order.
Another reason for us is proofing tools that use glyph order to display all glyphs in a font. We always create specific glyph layouts for all our fonts, and it is a great help to see all glyphs in the same order in our editors as in our proofing tools.
I can imagine a compressed export option that would be enabled for webfonts or similar environments where byte count is paramount.