Add box- and block-drawing symbols to Mono

[codeman38]

Many Windows and Unix console apps make use of the characters from the box-drawing (0x2500-0x257F) and block-drawing (0x2580-0x259F) Unicode ranges. Would it be possible to add support for these ranges in Plex Mono?

At the very least, the subsets of those Unicode ranges that overlap with DOS/Windows code page 437 (http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP437.TXT) feel like they should be supported.

[bartsnapp]

I've been having trouble with ascii art rendering correctly with Mono Plex in emacs (but not nano...) This could be the same issue. Or it might be an issue with emacs... Or it might be that I have something configured incorrectly...

[BoldMonday]

Good suggestion. We'll consider it for a future update.

[mjabbink]

@BoldMonday did we get this in v2?

[BoldMonday]

No, this has not been discussed yet when to include.

[frankrolf]

@BoldMonday @mjabbink Feel free to use this: https://github.com/adobe-type-tools/box-drawing

[BoldMonday]

@frankrolf We happily used it already for Nitti some time ago. :)

[GrahamHannington]

My use cases (why I'm interested in this issue)...

In 2009, I developed a proprietary, in-house tool named Capter that uses the IBM Personal Communications (PCOMM) terminal emulator to capture IBM 3270 terminal screens, with all attributes (such as underlining and color) intact, to various text-based formats, including DITA, XHTML, and (for Microsoft Office applications) RTF.

Today, I use Capter with IBM Plex Mono to render IBM 3270 terminal screens in PowerPoint, for YouTube videos. (Actually, these captures in PowerPoint don't use box drawing characters; but that's another story, specific to PowerPoint.)

I've also been successfully using Capter to reproduce IBM 3270 terminal screens in IBM product documentation. For example:

• HTML format in IBM Knowledge Center
• PDF (see PDF sheet 94; footer page number 82)

In IBM Knowledge Center, the CSS specifies IBM Plex Mono for these screen captures, but I can see that, for the box drawing characters, my web browser (latest Chrome on Windows 10) falls back to Courier New.

Not entirely by chance, the example screen captures to which I've pointed you here only use horizontal line box drawing characters. I have other examples, not on the public web, that use other box drawing characters, such as corners, vertical lines, and intersections. So far, I've been using other fonts for those captures.

I haven't yet experimented using IBM Plex Mono with these more complex screen captures in my browser; to see, for example, whether there will be alignment issues with the mix of IBM Plex Mono and Courier New.

Mostly, though, I'm writing this comment because I'm concerned about IBM product publication PDFs. Currently, for terminal screen captures, IBM product publication PDFs use the BookMaster font, which does have box drawing characters. I'm anticipating that, at some point, IBM will retire BookMaster from PDF production in favor of IBM Plex Mono. I hope Plex Mono gets box drawing characters before that happens. Otherwise, terminal screen captures in IBM product documentation that use box drawing characters (not just mine; this is not specific to Capter) will "break".

(Not the right forum for this comment? I would welcome the opportunity to discuss this issue on a more specific forum.)

[GrahamHannington]

@codeman38 wrote:

Many Windows and Unix console apps make use of the characters from the box-drawing [...] Unicode ranges

:+1:

So do many IBM z/OS ISPF apps.

[BoldMonday]

@GrahamHannington Thank you for the extensive feedback. This is certainly helpful to set priorities for adding these glyphs to IBM Plex Mono.

Is there somewhere a technical overview of the BookMaster fonts, showing character sets etc.?

[GrahamHannington]

Is there somewhere a technical overview of the BookMaster fonts, showing character sets etc.?

Unfortunately, I do not know of any public website where you can find such details. I recommend that you ask your contacts at IBM for more information, including a copy of the IBM BookMaster fonts.

No offense intended: I'm surprised that you ask. I would have thought—but clearly, I'm wrong—that IBM BookMaster would have been one of the references for your design of IBM Plex Mono.

I've just taken a minute to test IBM Plex Mono in my browser with a terminal screen capture that contains vertical line drawing characters. The result is as I feared:

My CSS:

font-family: "IBM Plex Mono", monospace;

Chrome (latest on Windows 10) reports (in Dev Tools/Elements/Computed/Rendered Fonts) that it is using the Consolas font to render the box drawing characters.

That result prompted me to use Google to search for a top-left corner box drawing character in IBM Knowledge Center:

┌ site:ibm.com/support/knowledgecenter

I found this topic, among other results:

https://www.ibm.com/support/knowledgecenter/en/SSWRCJ_3.5.0/com.ibm.safos.doc_3.5/DISPLAY_RESULTS_Example_2.html

This particular topic is interesting because, in this case, the use of box drawing characters is not for a terminal screen capture, it's for "character graphics". This is what IBM information developers (including me) did back in the day when we were writing documentation in BookMaster GML on 3270 terminals (yes, I am that old). We typed those box drawing characters manually (or rather—too much info, sorry—we typed characters that we then converted into box characters via a macro). Such character graphics have mostly been replaced by diagrams drawn using tools such as CorelDRAW.

Good news: the box drawing characters in that graphic are correctly aligned. At least, it looks okay to me. (I'll let someone else worry about the line height. One issue at a time!)

Here's the corresponding IBM Knowledge Center CSS:

font-family: "ibm-plex-mono","Menlo","DejaVu Sans Mono","Bitstream Vera Sans Mono",Courier,monospace

With these font-family specs, Chrome reports that it is falling back on Courier New for the box drawing characters.

If I return to my local test case, and insert "Courier New" ahead of monospace, the box borders are now correctly aligned.

The only explanation I have—I'd be happy to be educated otherwise—is that IBM Plex Mono has identical, or near-identical, metrics to Courier New. (I think this is unlikely to be a coincidence.)

So, as far as this research shows, my fear of endemic misalignment of box drawing characters in IBM Knowledge Center appears to be unfounded.

[GrahamHannington]

I wrote:

I'll let someone else worry about the line height. One issue at a time!

That gappy line height is a crime against typography in general and IBM Plex Mono in particular.

I invite you to contact the designers of the IBM Knowledge Center CSS and get them to fix this. They might respond with something like: "Character graphics are legacy markup that should be replaced by diagrams created using modern tools. This is a semantically inappropriate use of code block markup." (In fact, I have some sympathy with that position.)

In which case, point them here:

https://www.ibm.com/support/knowledgecenter/SS2L7A_5.4.0/com.ibm.cics.cm.doc/ccv-tutorial-1-020.html

That topic shows a terminal screen capture marked up in the original DITA source using a semantically appropriate screen tag, but still rendered with ugly gaps between the vertical lines that do not accurately represent the original screen. In the examples I pointed you to in my earlier comment, I override the default KC CSS to prevent this issue. Don't get me started on the lack of shrinkwrapping on the gray screen background :smile:.

[GrahamHannington]

@BoldMonday,

The omission from IBM Plex Mono of box-drawing characters—more specifically, the omission of APL characters, including box-drawing characters—makes me wonder about the brief that IBM gave you, the type designers.

From my perspective, one of the primary use cases of IBM Plex Mono is for 3270 terminal screens. Am I alone in this? As an information developer (technical writer), I'm primarily interested in capturing terminal screens for documentation. IBM Plex Mono could also be the future face of 3270 terminal emulation; for example, the default font for IBM Personal Communications (PCOMM). But not yet. Not without all the characters supported by 3270 terminals.

Have you had any conversations with the PCOMM developers about the possible future use of IBM Plex Mono in PCOMM? (Or in other terminal emulators?) Perhaps you should. Or is that wildly outside the scope and ambition for IBM Plex Mono?

I'm concerned that you might not have known—you might not have been briefed by IBM—to test IBM Plex Mono with tight leading: with characters sitting directly on top of each other, with no additional space, so that the vertical lines of box-drawing characters are unbroken between rows.

In terms of priority, for the terminal screens that I typically capture, I'd like to see in IBM Plex Mono the APL box-drawing characters that correspond to the following 11 "BOX DRAWINGS LIGHT ..." Unicode characters:

2500 ─ BOX DRAWINGS LIGHT HORIZONTAL 2502 │ BOX DRAWINGS LIGHT VERTICAL 250C ┌ BOX DRAWINGS LIGHT DOWN AND RIGHT 2510 ┐ BOX DRAWINGS LIGHT DOWN AND LEFT 2514 └ BOX DRAWINGS LIGHT UP AND RIGHT 2518 ┘ BOX DRAWINGS LIGHT UP AND LEFT 251C ├ BOX DRAWINGS LIGHT VERTICAL AND RIGHT 2524 ┤ BOX DRAWINGS LIGHT VERTICAL AND LEFT 252C ┬ BOX DRAWINGS LIGHT DOWN AND HORIZONTAL 2534 ┴ BOX DRAWINGS LIGHT UP AND HORIZONTAL 253C ┼ BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL

That would be a start.

[BoldMonday]

Dear @GrahamHannington, thank you for your extensive explanation so far.

So far we had no conversations about support for 3270 terminals. But if you look at the IBM Plex website you will see that IBM Plex Mono is certainly based on IBM’s heritage. But one different from the realm of computers: typewriters.

While I understand how important a version of IBM Plex Mono will be for your duties within the company, it is impossible for me as an outsider to assess its priority. We have other people from the IBM design team reading this discussion too, and I suggest to take up this matter with them.

Also understand that the support for multiple scripts and languages, including ones such as Vietnamese that require stacked diacritics, might require more linespacing than what you are typically used to in terminal environments.

Thank you.

[mjabbink]

@GrahamHannington We are planning to include this in 2019. To date we have prioritized the language support of IBM Plex over Box Drawings and math symbols for example. I realize there are plenty of use cases but the development of the Sans in Arabic, Cyrillic, Devanagari, Greek, Hebrew, Thai (looped and loop-less) and Hangul have been prioritized. In 2019 we are budgeting for math symbols for Sans and hopefully Serif and Box Drawings to be great additions for obvious reasons. When we get to box drawings would you like to be an advisor?

[GrahamHannington]

@BoldMonday,

Re:

your duties within the company, it is impossible for me as an outsider to assess its priority

I develop IBM product documentation, but I am not employed by IBM; I am not an IBMer. I work outside the IBM firewall.

I don't have direct contact with the IBMers who are responsible for developing the IBM product documentation PDF toolchain. I've tried but so far failed to make contact. That's one reason I'm commenting here, on this issue; it occurs to me that you, the type designers, might have better luck; or that IBMers reading this discussion might be interested.

What I'm most concerned about is this: that IBM might, in the near future, be considering retiring the IBM BookMaster font in favor of IBM Plex Mono for product documentation PDFs, to render content that includes box-drawing characters. IBM has already updated the IBM Knowledge Center CSS to use IBM Plex Mono for such content. Fortunately, in that context, browsers can fall back on a font that contains those missing characters; and, if that fall-back font has the same metrics as IBM Plex Mono, the result looks okay. But in a PDF, the last time I checked—and here, I'll confess, that was years ago, when we generated PostScript and distilled it into PDF, rather than generating PDF directly—at best you'll get a "replacement" character (typically, a black diamond with a white question mark or an empty square box) where you wanted box-drawing characters.

Perhaps I'm worrying too much. Perhaps it's all in hand. Perhaps the technology has moved on, and it's straightforward for a PDF to fall back on a particular font for characters not available in the current font. I want to help—to avoid a potential pitfall—not meddle.

I'm glad I did that search in IBM Knowledge Center for box-drawing characters. At least I know that if the rendering of "my" content (the IBM product documentation that I write) breaks, I won't be alone.

[GrahamHannington]

@mjabbink,

Thanks for the info.

Re:

When we get to box drawings would you like to be an advisor?

That's a very kind invitation. However, with sincere thanks, I'll decline. Without irony, but with a smile: I'm not worthy! There will be many IBMers with much deeper knowledge and experience on this subject than me.

I can offer this much advice: to fully support 3270 terminal screen captures, you only need a small subset of the Unicode box-drawing characters, but you also need other characters, outside of that box-drawing range. I'll leave it at that for now; like I say, there are many IBMers better versed on this subject than me. Besides, if rendering 3270 terminal screens is not a goal of IBM Plex Mono, then it's not your problem.

While I'm here, on a slightly different note: I love your work. Thank you—and @BoldMonday—for IBM Plex. I've spent many years creating PowerPoint presentations to promote IBM products. For various reasons, until recently I've felt compelled to stick to using Arial for headings and body text, and Lucida Console or Consolas for code blocks or terminal screens. Now, as you'll see from that YouTube video link in my earlier comment, I've switched over to IBM Plex (except for the limited cases where I need box-drawing characters). My presentations and videos look much better for it. Chapeau!

[GrahamHannington]

I've belatedly recalled another use case for box-drawing characters in IBM product documentation, and for the BookMaster font in PDFs: railroad syntax diagrams. (Yes, I realize the diagrams at that link do not use box-drawing characters. There's an opportunity here for a box-drawing-equipped IBM Plex Mono to make a significant impact on the quality of IBM product documentation, especially in IBM Knowledge Center. More on this later, if I get time.)

This settles my fears about IBM retiring the BookMaster font in favor of IBM Plex Mono in PDFs before IBM Plex Mono gains box-drawing characters: while I'm paranoid enough to imagine support for APL characters, including box-drawing characters, being overlooked in 3270 terminal screen captures, railroad syntax diagrams are too common to be overlooked. (It's possible that IBM could replace the current box-drawing character-based method of rendering syntax diagrams with something else, but I've seen no sign of that happening.)

[GrahamHannington]

@mjabbink, @BoldMonday,

I wrote:

There's an opportunity here for a box-drawing-equipped IBM Plex Mono to make a significant impact on the quality of IBM product documentation, especially in IBM Knowledge Center

Here's a web browser screen capture of a syntax diagram in IBM Knowledge Center, rendered in IBM Plex Mono:

Here's an Adobe Reader screen capture of the same syntax diagram in a PDF, rendered in BookMaster:

Notice that syntax diagrams in KC do not use proper box-drawing characters. This issue pre-dates IBM Plex Mono. It might have made technical sense years ago to not use box-drawing characters, due to browser limitations at the time, but I am unaware of any such limitations in modern browsers in 2018. The syntax diagrams in KC are an eyesore.

Changing both KC and PDF to use an appropriately equipped IBM Plex Mono for syntax diagrams, with proper box-drawing characters in KC, would greatly improve the quality of the diagrams in KC, and improve the consistency across KC and PDF.

It's possible that IBM might improve the appearance of syntax diagrams in both KC and PDF by replacing the current entirely character-based rendering method with SVG. In which case, box-drawing characters in IBM Plex Mono cease to be an issue for this use case; still, any such re-implementation would benefit from your input, especially because it would be likely to use IBM Plex Mono.

[GrahamHannington]

Another example railroad syntax diagram, this time hand-coded by me in a Word document using the Consolas font:

To anyone formatting syntax diagrams with Unicode box-drawing characters: note the rounded corners (arcs). I think they work better than sharp corners (I can explain why, if asked).

Unicode characters:

256D ╭ BOX DRAWINGS LIGHT ARC DOWN AND RIGHT 256E ╮ BOX DRAWINGS LIGHT ARC DOWN AND LEFT 256F ╯ BOX DRAWINGS LIGHT ARC UP AND LEFT 2570 ╰ BOX DRAWINGS LIGHT ARC UP AND RIGHT

(I don't mean to suck the oxygen out of this comment thread, but, frustratingly, I don't have direct contact with the people who are responsible for railroad syntax diagram formatting in IBM product documentation, and there's a small but real chance that such people might read this issue.)

[GrahamHannington]

On 22 August 2018, @mjabbink wrote:

We are planning to include this in 2019.

Do you have a planned date for this?

[mjabbink]

@GrahamHannington No real date yet.

[sr105-tm]

Adding another example (the boxes are too narrow for Mono space): https://github.com/syl20bnr/spacemacs/blob/623ca354fec360c6ef4e0055f00427aa0e27ad4f/core/banners/000-banner.txt

the text:

Welcome to
███████╗██████╗**█████╗**██████╗███████╗███╗***███╗*█████╗**██████╗███████╗ B
██╔════╝██╔══██╗██╔══██╗██╔════╝██╔════╝████╗*████║██╔══██╗██╔════╝██╔════╝ E
███████╗██████╔╝███████║██║*****█████╗**██╔████╔██║███████║██║*****███████╗ T
╚════██║██╔═══╝*██╔══██║██║*****██╔══╝**██║╚██╔╝██║██╔══██║██║*****╚════██║ A
███████║██║*****██║**██║╚██████╗███████╗██║*╚═╝*██║██║**██║╚██████╗███████║
╚══════╝╚═╝*****╚═╝**╚═╝*╚═════╝╚══════╝╚═╝*****╚═╝╚═╝**╚═╝*╚═════╝╚══════╝

using IBM Plex Mono in Emacs:

using Source Code Pro:

[vsalvino]

Since we have been waiting for this for several years, I managed to make a patched version with box drawing characters:

👉 https://github.com/vsalvino/terminex

Edit: I renamed the font and added the license to remain compatible with the license.

[BoldMonday]

@vsalvino happy to hear you found your own solution.

While everyone is allowed to use and modify IBM Plex for their own purposes please note that there are a number of conditions that come with the Open Font License (OFL). https://github.com/IBM/plex/blob/master/LICENSE.txt

In particular I suggest to look into the following matters: • “IBM Plex” is a reserved name and may not be used for derivative works; • Derivative works must be released under the same OFL license. A copy of the license should be included with the files; • In order to stimulate further development it is requested to make source files available for projects released under the OFL.

[mjabbink]

We have some box Glyphs in Plex Korean as it’s a standard to include it. We can look through this all and more easily plan to include into Mono. Thank you for contributing and I ask to please be patient because as I’ve stated before we have prioritized CJK which already takes time, resources and money to accomplish.

[shoober420]

I’ll chime in and show another use case for box glyphs. While using cmus audio player with IBM Plex Mono, I experience missing glyphs as well. https://github.com/91861/wayst/issues/12

[mjabbink]

@BoldMonday Let’s connect on this as a possible near future add by utilizing the Box glyphs from IBM Plex KR.

[BoldMonday]

Block drawing glyphs have been added in Plex Mono v2.3 (part of Release v6.0.0). The issue can be closed now.

[GrahamHannington]

Belated thanks for the box-drawing characters! 👍

I've attached an example 3270 terminal screen containing box-drawing characters, set in the updated IBM Plex Mono.

omegamon-e3270ui-banner.pdf