Unicode console font

ilyaz's picture

I put the pre-alpha (but very usable for low enough resolutions) version of monospaced scalable variant of Unifont font to http://ilyaz.org/software/fonts.

It is constructed by a scanner/stroke-designer backend running over the 16×8, 16×16 bitmaps of Unifont. The scanner/designer are written in Perl; the scanner is ready, the designer 70% ready. (Of course, it turned out to be a much more complicated task than I expected at the start — 6 months ago!)
The frontend converting strokes to a font is EXTREMELY primitive (cooked in a day, and hitting new and new bugs in FontForge — sigh…). So I'm afraid any critique at this moment would be very premature…
I'm hitting my head again and again with .notdef; it does not work in Windows console if I include U+0000 and U+0001 glyphs. So currently I just omit these glyphs — is there any alternative? The recommendations in http://www.microsoft.com/typography/otspec/recom.htm are not very helpful: how can one include .null into a monospaced font?
Any help with this would be greatly appreciated.

ahyangyi's picture

I think .null and .notdef are perfectly valid in a monospaced font. Apparently Consolas includes them...

ilyaz's picture

Maybe I just cannot find the magic incantation in FontForge. If I use the sequence .notdef/0002/0003/0004/0005/etc, everything works OK. Inserting glyphs named 0000/0001 after .notdef makes the glyph 0000 used instead of .notdef.

Consolas has

StartChar: .notdef
Encoding: 65536 -1 0
Width: 1126

StartChar: glyph1
Encoding: 0 -1 1
AltUni2: 000000.ffffffff.0
Width: 1126

StartChar: uni000D
Encoding: 13 13 2
Width: 0

StartChar: space
Encoding: 32 32 3
AltUni2: 0000a0.ffffffff.0
Width: 1126

which, on the surface, is contrary to M$ recommendations: CR should have non-0 width, second glyph should be named .null and it should have 0-width. Moreover, M$ says that a console font should be monospaced — but above CR has width 0….

John Hudson's picture

In a monospaced font, *all* glyphs should have the same advance width, and this overrides other recommendations such as that which says NULL should be zero-width. If a monospaced font contains glyphs that do not share the common width, it can cause major problems, because software tends to cache the width value for monospaced fonts.

Note also that the proper name of this glyph is NULL, not .null. The only glyph in a font whose name begins with something other than A-z is .notdef.

ilyaz's picture

Thanks, John! The question remaining is: what you say, is it just “common knowledge”, or is it documented somewhere? What I was quoting was the cited MS's document; one does not expect it to be even close to being perfect, but it would be nice if one knew something more authoritative, and still kind of comprehensive.

I do not say that your word is less authoritative than the MS's document; it it just that what you say is one (or two) tidbits at a time ;-).

Please bear with me, this is my first foray into non-bitmap world…. Of course, in what I released every char is of the same width — I just was not sure which card bits which when different recommendations are concerned. ― And note that in Consola 000D has width 0, contrary to “consoleness” — which for me implies being monospaced; and the recommendation above says that 000D should be non-0 width….

Michel Boyer's picture

On my mac (Office 2011, Consolas version 5.22), all glyphs in Consolas have width 1126 except the following (obtained from a ttx output with grep '<mtx' Consolas.ttx | grep -v 1126 and then some clean up):

    "afii299" width="0" lsb="-36"
    "afii300" width="0" lsb="-431"
    "afii301" width="0" lsb="-219"
    "afii61664" width="0" lsb="-36"
    "glyph00002" width="0" lsb="0"
    "uniFEFF" width="0" lsb="0"

As for NULL, it is called uni0000 according to ttx but Fontforge and DTL OT Master give me some different information... Hmm.

And as for proper documentation, if you find any, please tell us.

PS. Raph Levien's font Inconsolata defines no NULL character.

John Hudson's picture

With regard to glyph names, Consolas, like the other CT fonts, has a format 3 post table, so does not contain any glyph names. The names you see in TTX or other tools are being generated by that software.

ilyaz's picture

    "afii299" width="0" lsb="-36"
    "afii300" width="0" lsb="-431"
    "afii301" width="0" lsb="-219"
    "afii61664" width="0" lsb="-36"
    "glyph00002" width="0" lsb="0"
    "uniFEFF" width="0" lsb="0"


Just to have reference nearby (from http://partners.adobe.com/public/developer/en/opentype/aglfn.txt):

200E;afii299;LEFT-TO-RIGHT MARK
200F;afii300;RIGHT-TO-LEFT MARK
200D;afii301;ZERO WIDTH JOINER
200C;afii61664;ZERO WIDTH NON-JOINER

FEFF	ZERO WIDTH NO-BREAK SPACE                                    ; from NamesList.txt


Do not know what glyph00002 is used for….

Update: doing grep -B 5 -A 5 "Width: 0" Consolas.sfd , I see

StartChar: uni000D
Encoding: 13 13 2
Width: 0
GlyphClass: 2
Flags: W
LayerCount: 2
EndChar


which, by exclusion, must be what you see as glyph00002….

Michel Boyer's picture

Concerning glyph00002, the sfd file produced from Consolas on my mac gives this:

StartChar: glyph1
Encoding: 1 -1 1
AltUni2: 000000.ffffffff.0
Width: 1126
GlyphClass: 2
Flags: W
LayerCount: 2
EndChar

StartChar: glyph2
Encoding: 2 -1 2
Width: 0
GlyphClass: 2
Flags: W
LayerCount: 2
EndChar

StartChar: uni0009
Encoding: 3 9 3
AltUni2: 0000a0.ffffffff.0 000020.ffffffff.0 00000d.ffffffff.0
Width: 1126
GlyphClass: 2
Flags: W
LayerCount: 2
EndChar

and glyph00002 is simply glyph2.

The uni0000 produced by ttx must come from AltUni2: 000000.ffffffff.0

And concerning uniFEFF ZERO WIDTH NO-BREAK SPACE it has width 1233 in DejaVuSansMono.ttf version 2.33.

Syndicate content Syndicate content