Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console Windows’ fonts #1410

Open
ilyaza opened this issue Jun 14, 2014 · 5 comments
Open

Console Windows’ fonts #1410

ilyaza opened this issue Jun 14, 2014 · 5 comments

Comments

@ilyaza
Copy link

ilyaza commented Jun 14, 2014

(I made a new release of de-rasterized Unifont; see http://ilyaz.org/fonts.) As in all (working ;-) releases, I’m forced to remove Katakana, Bopomoto, and Hangul Jamo from the font — otherwise it is not recognized as a “suitable for Console” font on Windows.

Reading http://support.microsoft.com/kb/247815 again, it says:

If it is an Asian TrueType font, it must also be an Asian character set.

Could somebody explain what can this mean in context of FontForge?

BTW, another requirement:

If it is a TrueType font, it must be FF_MODERN.

is also not clear in the FontForge context (although judging by the fact that removing about 200 characters out of 15000 makes thing work, this is already covered by my setup). Comments?

@ilyaza
Copy link
Author

ilyaza commented Jun 16, 2014

OK, I suspect that the solutions looks like this:

What http://support.microsoft.com/kb/247815 (apparently) omits, is
   If it is an Asian TrueType font, it won’t be loaded on non-Asian installs of Windows.
And this is controlled (in the case of my font) by 3 codepages in the OS/2 list, which FontForge calls (in Element/FontInfo/OS2/Charsets/MSCodePages):

  • 932, JIS/Japan
  • 936, Simplified Chinese
  • 949, Korean Wansung

To disable these codepages, I needed to insert into .sfd:

OS2CodePages: 600101ff.ffff0000

(this overrides the auto-generated value 600f01ff.ffff0000).

Any more comments (so I may close it)?

@ilyaza
Copy link
Author

ilyaza commented Jun 16, 2014

Actually, I myself have a comment:

Is not it a FontForge bug that:
   a font in which only Asian characters in range U+30a0…U+31fe are present is marked as supporting codepages 932, 936 and 949?
(Well, my fonts also support a small handful of [narrow] characters in other ranges too. Anyway, these are HUGE codepages, and fonts support only a teeny-weeny fraction of them!)

@mozbugbox
Copy link
Contributor

You should be able to edit mscodepage in FF by Element->Font Info->OS/2->Charsets->MS Code Pages. Use ctrl-click to toggle single selection.

@ilyaza
Copy link
Author

ilyaza commented Jun 17, 2014

You should be able to edit mscodepage in FF by Element->Font Info->OS/2->Charsets->MS Code Pages. Use ctrl-click to toggle single selection.

As I pointed in my message, it was via this menu entry that I discovered what made the crucial working change. However, for my workflow, I have absolutely no interest in interactive fixes.

@be5invis
Copy link

For a console font it should specify xAvgCharWidth manually to the width of Latin characters, however Fotnforge always calculate this value on its own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants