Blockzone.ttf missing glyphs

[andyherbert]

The Blockzone.ttf font appears to be missing the glyphs for codepage 437 values less than 32:

I'm assuming that they may reside at unicode code points that I'm not testing for, but the values I'm using are taken from the table located at this page:

http://en.wikipedia.org/wiki/Code_page_437

[ByteProject]

Is the screenshot from my font? Because I see the characters on it :)

Ok, let's explain some design concepts of BlockZone:

Generally, the font follows the specs from IBM, published in 1984 (and 1986) which defines character 1-32 as control characters. Further, here is what Fred writes about these characters on ascii-codes.com: The first 32 characters are control characters (also called non-printable characters), which are used to control data streams as well as devices such as printers.

Depending on with what and of course how you are testing, there is a good chance you are not able to see these characters because they get interpreted as control characters (which is correct, e.g. CR/LF in a text editor).

Since all encodings included in BlockZone have these characters in common, they are part of the glyph table but not part of the specific encoding. Instead they are available to each of the supported encodings. So to answer your question, the characters are not missing in BlockZone. Here is the glyph table:

Furthermore, here is a list of the supported encodings of BlockZone:

Hope this helps! Can I close the issue? ;)

[andyherbert]

I suspected that the glyphs were already included, but the problem with mapping the control characters at their exact code point values is that they're interpreted as non-printable characters in terminal applications. For example, you can't display the 'bell' character for your font in Terminal.app, but you could if the glyph was inserted at U+2022 ('Bullet').

All the rest of mappings between the codepage 437 control characters and their unicode equivalents are available on the Wikipedia page I linked to in the first post.

[ByteProject]

Yes, I understand your intention in how to use this font. I think this is the wrong place to discuss additional features for BlockZone. Ascension is not Terminal.app. We should keep in mind that BlockZone was created for the purpose of rendering .NFO/.DIZ documents in Ascension. Unlike Terminal.app, Ascension actually renders in CodePage437 (it does not work with Unicode internally because there is no need to). When you create a new NFO, or when you open an existing NFO you are live watching/editing in 437 encoding. In addition, if you use the encoding dropdown to convert any NFO document to Unicode, Ascension takes care of mapping the characters to their Unicode counterparts in the conversion process (by code). To work correctly in a text editor, which Ascension is, it was necessary to map non-printable characters to their real code point values.

It's important to note that what we got here is not an issue, furthermore and most notably not an issue of Ascension. Ascension renders .NFO files correct when using BlockZone. The font works correct when using with Ascension. The question how the font performs with other applications shouldn't be subject in the Ascension issues section.

Maybe I can add the feature for you, so one could use BlockZone "out of the box" in Terminal applications. Unfortunately I don't have much time at the moment to deal with that and I wouldn't classify it as high on my priority list so I have no idea when I'm able to dig into it sigh maybe you want to have a look at it yourself? FontForge recently got revived (looks gorgeous), so if you want to update BlockZone or do other nasty things to it, feel free to do so :)

[andyherbert]

I'll have a look at FontForge.

I hope that you'll reconsider your position, because currently you have the extended-ascii set mapped to their unicode equivalents (see screenshot) but not the control codes which, as well as being internally inconsistent, makes displaying them in anything outside of Ascension (and not just Terminal.app) difficult or impossible.

[ByteProject]

I'm totally with you, Andy. It's a good idea of making the font work with any application. My problem is that the font was created for Ascension, where it works. BlockZone gets bundled into the resources of Ascension when compiled, and the font doesn't get installed when running Ascension on the target system. Just Ascension is accessing the font. It's not available to other applications in the system. I'm just saying Ascension works with the font and the font works with Ascension. BlockZone was never intented to be installed as a system font and it was initially not created for being available to other applications on the target system.

I'm just saying we don't have an issue here that should be tracked in the Ascension issue tracker.

Right now my very limited spare time is focused on releasing Ascension III which is still some work to do. As Ascension performs 100% correct with the font, this is not an issue and thus has no high priority to me. I would maybe consider this as a feature request. The font comes with Ascension. So there could be an option to install BlockZone on the system. If I implement this feature, the font has of course to work. I put it on my todo list and see if I manage to make this happen. Since I'm running out of time I'd really appreciate if you could dig into that, so I would just add the feature of installing the font to Ascension's preferences :)

[andyherbert]

I just took a pass at this, and fortunately it was a rather painless operation in FontForge. I'm not sure if you would accept a pull request with the updated font, but I've inserted the control character glyphs at their unicode equivalents. Here's a side-by-side comparison with TerminusVector:

Left: BlockZone, Right: Terminus

[ByteProject]

Wow, that was fast. I'd be happy to accept your pull request. I will add an option to optionally install the font :) thanks :)

[andyherbert]

Done. I've documented all the remappings that were required in the commit message.