A Roguelike TTF/OpenFont font: Is there interest in such a thing?

[yam655]

Character-based Roguelike games could really benefit from some of the great Unicode codepoints now available as standard features.

What sort of codepoints?

How about fullwidth ASCII to go along with the fullwidth CJK for full access to the CJK glyphs while still being true fixedwidth?

How about heiroglyphs? Perhaps http://unicode.org/charts/PDF/U10980.pdf or http://unicode.org/charts/PDF/U13000.pdf

Alchemical symbols? http://unicode.org/charts/PDF/U1F700.pdf

The standard emoticons? http://unicode.org/charts/PDF/U1F600.pdf

Or some of what I really want to see: http://unicode.org/charts/PDF/U1F300.pdf http://unicode.org/charts/PDF/U1F680.pdf http://unicode.org/charts/PDF/U2600.pdf

You can have churches, cemeteries with crosses of various shapes -- and even pentagrams. You can also have maps with real map symbols on them.

The only problem is there doesn't appear to be a font catering to our unique need.

Now, a good free Unicode font should be usable by all Roguelike games using a character-based interface. Old-school curses using PuTTY (or your favorite terminal application for Mac OS X or Linux) would be able to use it just as easily as a more GUI-based solution.

It would benefit almost everyone in the community.

We would want to start with one of the good-looking "console" or "programming" fonts -- designed for looking at for long hours. The steps are: 1. gauge interest. 2. pick a license. 3. pick a starting point that doesn't suck. 4. prioritize codepoints and regions. 5. make it easy for folks to contribute.

There are a lot of potential starting points depending on what sort of license would be suitable for folks.

My personal preference is to focus on two fonts -- both true fixed width -- with one being full-width and one half-width. (Latin characters are half-width. CJK (Chinese/Japanese/Korean) characters are full-width.) Depending on the tools and the build environment, it may be possible to compile a dual-width font out of the two -- with specific Unicode ranges either being fullwidth or halfwidth -- but that's a lesser priority.

[AgingMinotaur]

I think that could be interesting, although I'm going the graphical route for my personal project. In any case, I'd definitely recommend an open license, or a lot of developers won't be able to  profit from your work. I can't see a closed font gaining much momentum in the RL community.

As always,
Minotauros

[yam655]

I think that could be interesting, although I'm going the graphical route for my personal project. In any case, I'd definitely recommend an open license, or a lot of developers won't be able to  profit from your work. I can't see a closed font gaining much momentum in the RL community.

As always,
Minotauros

I'm not really a fan of closed source products. In this context closed-source would likely be free-to-use (at least for non-commercial purposes).  I'm really just trying to gauge interest.

I want a developer to be like, "I really want codepoint <FOO> for my game, but it's not in the font yet. How can I help?" Then we say, "Use this Inkscape template and sketch it up as an SVG file. Contribute it back to the project and we can easily roll you a copy of the font before our next major release." In an open-source community this is easy and allows everyone to benefit.

The GPLv3 -- because it isn't being "linked" to a program -- shouldn't cause license pollution. While there is a GPL "font exception clause", it only exists because of font embedding -- this is literally taking the contents of a TTF (or other) font file and shoving them inside the body of a document. (See http://www.fsf.org/blogs/licensing/20050425novalis ). Referencing a font, or even installing it for the end-user in your installer, is perfectly acceptable with a GPL v3 licensed font so long as the user (1) has access to the source, (2) can modify it, and (3) can install a modified version for use by your program.

Ideally, a really great font and a few applications that take advantage of it should cause developers to second-guess whether they really want to go with a tile-based approach or not.

For our purposes we could take advantage of some of the private use area to add things like, say, architectural symbols so that a building can look like building plans. (So that, say, when the player gets building plans, the background flushes blue, and they have the option to look at floor plans for floors they are not on.) -- After all, there are already established simple symbols for components of maps of all sorts...

Cheers,
Steven Black

[kraflab]

Ideally, a really great font and a few applications that take advantage of it should cause developers to second-guess whether they really want to go with a tile-based approach or not.

It seems to me that those applications would be essentially tile based.  You can put it in a font but that doesn't make it not tiles.

[yam655]

Ideally, a really great font and a few applications that take advantage of it should cause developers to second-guess whether they really want to go with a tile-based approach or not.

It seems to me that those applications would be essentially tile based.  You can put it in a font but that doesn't make it not tiles.

How many tile-based games allow dynamic resizing of the window and auto-resize their tiles? This should be a trivial operation.

It's gotten so bad that even character-based Roguelikes don't recognize it as something that should be easy to support.

Now, if you're talking about the difference between scalable vector-based tiles with antialiased black-and-white lines which are recolored and resized as appropriate, then -- yes, it's the same as using a font. (Except for being able to accent things without precomposed tiles.)

Cheers,
Steven Black

[Tapio]

It sounds to me you are talking more about a monospace unicode font than specifically a roguelike font. Are you suggesting adding custom glyphs outside the Unicode? How is CJK helpful in roguelikes, unless you are making translations?

[yam655]

It sounds to me you are talking more about a monospace unicode font than specifically a roguelike font. Are you suggesting adding custom glyphs outside the Unicode? How is CJK helpful in roguelikes, unless you are making translations?

In a perfect world we could use any old monospace Unicode font, yes.

Have you looked at the codepoint selection of the monospace Unicode fonts? Big on various languages, light on interesting symbols.

Since the font makers have been lax to create the glyphs that would most benefit us, why not add them ourselves? If that's the only goal -- strictly limiting it to Unicode -- we could easily contribute it back to the original font folks and not bother with "Roguelike extensions."

For a fullwidth font, CJK provides a large set of visually interesting symbols. CJK support is basically a freebie because most, if not all, of the fonts we would start from would have it. To get reasonable CJK support what we need is a reasonable full-width font. A full-width font is handy for some of the more detailed glyphs -- there are some codepoints that are unfeasible in a half-width font. (Some things expect a square cell instead of a rectangular cell.)

To my knowledge there are no fixed-point fullwidth Unicode fonts.

Now, while we could just limit it to Unicode there are Private Use Areas for a reason. We could go with a true Roguelike font with glyphs optimized for our genre. I've mentioned the lack of architectural symbols in Unicode. There may be other things that would benefit us as a whole.

[kraflab]

Ideally, a really great font and a few applications that take advantage of it should cause developers to second-guess whether they really want to go with a tile-based approach or not.

It seems to me that those applications would be essentially tile based.  You can put it in a font but that doesn't make it not tiles.

How many tile-based games allow dynamic resizing of the window and auto-resize their tiles? This should be a trivial operation.

It's gotten so bad that even character-based Roguelikes don't recognize it as something that should be easy to support.

Now, if you're talking about the difference between scalable vector-based tiles with antialiased black-and-white lines which are recolored and resized as appropriate, then -- yes, it's the same as using a font. (Except for being able to accent things without precomposed tiles.)

Cheers,
Steven Black

My point/question is why would anyone see this font and suddenly abandon tiles (which is what you say will happen in an ideal circumstance), when they could just as easily make a tile for the extra glyphs you have.  There are plenty of free graphics sets, so availability is also not an issue.  I'm just curious why you think this would be so great, since I expect people who are really devoted to ascii will also think that this is more of a tileset than a character set.  Your argument above is a complaint about implementation (which you even acknowledge is committed by font users as well), and not an actual reason why someone would want to switch to this font from tiles.

I'm not arguing with you here, I sincerely want to know why you think this way, because it seems like such a dramatic limitation to me and, while I certainly see the appeal of ascii, using a bunch of custom made characters seems to be heading away from that ideal.

(This is not to mention that I think, tiles or else, having a set of visuals that a lot of people use is absolutely horrible for the genre)

[yam655]

My point/question is why would anyone see this font and suddenly abandon tiles (which is what you say will happen in an ideal circumstance), when they could just as easily make a tile for the extra glyphs you have.  There are plenty of free graphics sets, so availability is also not an issue.  I'm just curious why you think this would be so great, since I expect people who are really devoted to ascii will also think that this is more of a tileset than a character set.  Your argument above is a complaint about implementation (which you even acknowledge is committed by font users as well), and not an actual reason why someone would want to switch to this font from tiles.

I'm not arguing with you here, I sincerely want to know why you think this way, because it seems like such a dramatic limitation to me and, while I certainly see the appeal of ascii, using a bunch of custom made characters seems to be heading away from that ideal.

(This is not to mention that I think, tiles or else, having a set of visuals that a lot of people use is absolutely horrible for the genre)

You do have a good question.

It fundamentally boils down to my existing prejudices against tiles: Raster-based tiles are hard to tell apart when they can easily become a smear of color with a single pixel being the difference between two different things. Additionally, I'm prejudiced against Roguelike games having a minimap. In a Roguelike game, the main map screen is the minimap. Tiles tend to need to be massive for them to be both distinguishable and to have any sort of the visual meaning that a graphic image would normally imply.

I'm not even saying I think people will see it and suddenly abandon their tiles. That's a matter of dreaming big. That's really a goal of any project of mine.

What's the fundamental difference between a character-based and a tile-based game? A character-based game is color-limited -- not in terms of the number of colors available, but in terms of the number of colors used in a single cell. A character-based game has simple line-art that is easily recognizable at very small sizes.

So, being both color-limited and visually simple, character-based displays can fit far more cells on the screen while still being visually distinguishable than can usually be done with a tile-based game. Of course, to be visually distinguishable it also helps to have a fixed palette for things of particular importance. (You can't have the only difference between two wildly different things be +/- 2 on a single color channel.)

Will people abandon raster--based tiles for SVG-based tiles that scale with the window so they can do things that are trivial to do with fonts? Goodness, that would be a fantastic idea. The problem there, though, is that because of the lack of simplicity and the number of colors, you still can't get the number of cells on screen without making them look like a font.

People make graphics look like fonts all the time. That's standard practice for some libraries. Still, though, raster-based graphics don't scale.

Ultimately, I don't care if people say, "This is so awesome, I want to drop graphics" or they say, "This is so awesome. I want to do something like this with graphics." Anything advancing the genre in new and interesting directions is good.

In a perfect world, we could just use normal reasonably complete Unicode fixed-width fonts. We'd have enough even if we didn't have architectural symbols. They wouldn't be custom, they would be what is defined in the spec. It's a very large spec.

Some of the things missing should be reasonably adaptable to a variety of fonts. It is possible that instead of pushing for a single font family we could push for the advancement of a number of popular fonts.

I'm not actually against tile-based graphics. As I said, in many cases tile-based graphics look like character-based graphics, so it can be hard to tell the two apart. What I want -- with character-based graphics or tile-based graphics -- is simple graphics which are color-limited per cell, easy to tell apart, and easily scale to any size.

(ASCII-based visuals are fundamentally a common set of clearly distinguishable visuals used by a wide variety of games.)

Cheers,
Steven Black

[getter77]

Oddly enough this sort of thing, albeit in a strange tangential manner, was/is one of the various things I'd been plotting on for awhile now---though out of my depth on all ends as of yet, as per always.     My angle was more "What if?" history based and tied to gameplay directly---but the whole Raster versus Vector part also rang my bell....though also under the first clause from my art tutorial hunting days before my creative spark had escaped me.

That said, and I imagine of at least some interest given the subject, this thing just happened:

http://doryen.eptalys.net/2012/07/the-font-from-outer-spaaaaace/

More details in the forum thread there

In terms of random license thinkings, um, some strange corners of what I track have went to zlib, which seems pretty ideal in terms of being moreso straightforward than the personally confusing GPL situation while just a sidestep or so away from public domain.

[yam655]

Oddly enough this sort of thing, albeit in a strange tangential manner, was/is one of the various things I'd been plotting on for awhile now---though out of my depth on all ends as of yet, as per always.     My angle was more "What if?" history based and tied to gameplay directly---but the whole Raster versus Vector part also rang my bell....though also under the first clause from my art tutorial hunting days before my creative spark had escaped me.

That said, and I imagine of at least some interest given the subject, this thing just happened:

http://doryen.eptalys.net/2012/07/the-font-from-outer-spaaaaace/

More details in the forum thread there

In terms of random license thinkings, um, some strange corners of what I track have went to zlib, which seems pretty ideal in terms of being moreso straightforward than the personally confusing GPL situation while just a sidestep or so away from public domain.

That's really kind of sad, considering the Basic Multilingual Plane (BMP) of Unicode (the first 16-bit plane) totally fails the Japanese community. ( http://tronweb.super-nova.co.jp/unicoderevisited.html ) -- This from an article I actually just ran across last night. (While the article is actually quite old, the BMP's been relatively constant for some time.)

Yamamushi used the "unifont" which only supports a fraction of the Unicode 5.1 spec, and only at horribly small sizes. -- The font's originally a bitmap font and has been converted to a truetype font through a method that leaves it, well, pixellated-looking at larger sizes. The smaller sizes are suitable for Roguelike games -- but talk about no ability to scale up for larger monitors... ouch. (That font's whole purpose is to have complete BMP coverage -- not complete Unicode coverage -- See http://unifoundry.com/unifont.html )

In my initial call to arms, I referenced Unicode code ranges above the 0xffff mark. In fact, only one of the ranges I mentioned was in the BMP at all.

For those paying attention, it means that if using 16-bit "wchar_t" values (as Yamamushi implies he is using in his Doryen forum post) you will need to use "surrogate pairs". That is, to show one codepoint you need to write a pair of 16-bit values. If LibTCOD doesn't support this then it doesn't support Unicode as surrogate pairs have existed since Unicode 2.0. (Linux (and probably Mac OS X), including the ncursesw library, use 32-bit values for wchar_t. Windows, for historical compatibility, is guaranteed to use only 16-bit wchar_t values.)

See the Unicode spec Chapter 5 ( http://www.unicode.org/versions/Unicode6.1.0/ch05.pdf ):

The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently,
programs that need to be portable across any C or C++ compiler should not use wchar_t
for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide
characters, which may be Unicode characters in some compilers. However, programmers
who want a UTF-16 implementation can use a macro or typedef (for example, UNICHAR)
that can be compiled as unsigned short or wchar_t depending on the target compiler
and platform. Other programmers who want a UTF-32 implementation can use a macro or
typedef that might be compiled as unsigned int or wchar_t, depending on the target
compiler and platform. This choice enables correct compilation on different platforms and
compilers. Where a 16-bit implementation of wchar_t is guaranteed, such macros or
typedefs may be predefined (for example, TCHAR on the Win32 API).

This isn't new. The Unicode 4.0 spec said basically the same thing. The difference is in the 6.1 spec it recommends the use of char16_t and char32_t for UTF-16 and UTF-32 values.

For those wondering, yes, since Java defines a "char" as being 16-bits, to pass around a complete code-point you need to either use an int or a String. The Character class has a whole set of functions supporting this.

As for licenses... When the FSF -- a group that sincerely cares about licenses -- says "merely referencing the font (as in the CSS font-face: caslon;) does not create a derivative work of that font. So why did we worry about font licensing at all?" then goes on to talk specifically about font-embedding as being the reason that fonts need specific types of licenses... I think there's some confusion about them. Loading a font in your program is just referencing it, after all.

Still, as I said earlier, if our goal is to get the missing codepoints in to fonts, (and not to also create Roguelike additions)... We can do this by using the most lenient of the possible licenses (public domain) and working with the other font folks to adapt our glyphs to fit their font styles. The key thing there would be whether we needed to do some sort of assignment-of-copyright thing to get the glyphs used by various font products. Though, if our output is dual-licensed Public Domain and CC0 -- http://creativecommons.org/about/cc0 -- it should be usable world-wide without restriction. (This is important because "Public Domain" doesn't exist in some countries.)

Cheers,
Steven Black

[Ancient]

Reading top-down I had a look at poll choices first. To me, the obvious choice (No, 32-bit unicode is enough) was suspiciously absent.

To be blunt: I am interested in such endeavor. My most frustrating experience with unicode was trying to use elder Futhark runic characters for magic book symbols. I could not find a font that would make runes look good with the rest of symbols. As if every font maker out there thought along the lines "almost nobody uses them so these can be significantly different than the rest of characters". Also, I need runes to be fixed width as well. Now finding that would be a miracle.

When the idea takes off you can ask me to help with runic range. I need runes so chances are high there will be time for it.

[yam655]

Reading top-down I had a look at poll choices first. To me, the obvious choice (No, 32-bit unicode is enough) was suspiciously absent.

That's exactly what I was talking about. A true fixed-width glyph for every Roguelike-interesting codepoint. There are a lot of Roguelike-interesting codepoints outside the BMP.

This will be happening. It's just a matter of when.

I do the Java-based Blacken Roguelike library. Since it should be possible to accept SVG-based contributions to the font, I'm going to see if I can use the Apache Batik SVG library to allow previewing vector tiles before they get rolled in to a font.

Which is to say: Working on a font isn't on my schedule until next year.

I'm working on finishing Blacken 1.1 for the Annual Roguelike Release Day (it's mostly feature complete now), then I want a complete tutorial by the end of November. After that, I'll start to work on the Blacken 2.0 features. The font work will spin up after the initial batch of changes are in trunk.

I expect it to miss the 2013 7DRL unless someone else wants to start this project before then.

If someone else wants to lead this effort before then, I would be happy to assist. This can be done using open-source tools -- there's a learning curve for the tools but no purchases required. (We're also talking about vector graphics. You don't need to be a traditional artist.)

Cheers,
Steven Black

[Ancient]

I am busy with stuff until ARRP 2012 too but November looks like fine time to get involved. No idea how hard would be to start such a project but I am likely to at least look for right tools and try my hand at it. We shall see how it turns out.

[yam655]

I am busy with stuff until ARRP 2012 too but November looks like fine time to get involved. No idea how hard would be to start such a project but I am likely to at least look for right tools and try my hand at it. We shall see how it turns out.

The right tools are simple:

1. Inkscape (For single-glyph detail work in SVG)
2. FontForge (for actually editing fonts)

On Windows FontForge can be "tricky" to install. (It needs Cygwin and X.) While there is documentation on how to do it, for those with the system resources they could alternatively download a free virtual machine host and a Linux ISO image and be all set.

Worst case, it's a matter of spending time with the important glyphs in Inkscape. (Glyph compositing can be done in FontForge, so the e + ^ = ê stuff can skipped.)

Then it's a matter of picking the font (and license) to work from. Each font has a license you're bound to -- except public domain fonts can be derived and relicensed at will. A font with variable-width glyphs we want may be easier to adapt to fixed-width while retaining the same style.

That really should be about it. Some fonts have fancy build systems that can strip out glyphs or join them from multiple sources, but other fonts just use the TTF/OTF font file themselves as the only source. If I went with a dual-width font -- like some terminals support -- I would exclusively use such a build system.

Cheers,
Steven Black