Previously, we described how we represent glyphs and how we store them in a texture. This approach is great for one channel textures. Unfortunately, single channel textures are not generally supported on WebGL devices. The only texture format that is widely supported is the RGBA (32 bit) texture, so to efficiently use GPU memory we need to pack four single channel textures into one RGBA texture.

You can notice that we do not store glyphs at regular distances, but try to utilize texture space as efficiently as possible.

It seems we have everything we need now: we are able to store an almost unlimited number of glyphs efficiently and stream only those that we need. Unfortunately, this is not enough. Some writing systems rely heavily on glyph substitution. For example, in Arabic texts certain combinations of two glyphs are replaced by a special glyph and sometimes this substitution depends on whether these glyphs are at the beginning, middle or the end of the word. Some of these special glyphs do not even have Unicode numbers.

For these cases the font has to contain predefined rules to determine which glyphs need to be replaced by others. There are standards like AAT (Apple Advanced Typography) and OT (OpenType) which try to solve this problem. You may be wondering how many types of these rules exist – short answer is many. Probably more than a hundred and sometimes you can achieve the same result by using a different combination of rules.

It is up to the font designer what rules will be used in the font. For obvious reasons we do not try to reinvent a new set of rules so we just adapted existing ones from the OpenType standard. We use all information from an OpenType font, the only difference is that we replace the geometry part by raster data. The font always consist of a file that we can call a header and this header file is almost identical to a TTF/OTF font. The geometry part of the font is removed and replaced with information about the position of each glyph in the texture (file number, coordinates and size). The remaining files contain textures with the glyphs.

The advantage of this approach is that we only have to load the header file, which contains information about all supported glyphs, their size and spaces between them. We can generate all text structures (vertices, texture coordinates) before the actual textures are loaded. Our map browser does not yet support all GPOS, GSUB rules defined by the OpenType standard, but we do support the most used ones and the number of supported features will grow over time.

Do not forget to try our map browser link. Any contribution to our code base on the GitHub is always welcome.

David Levínský, Frontend Developer

Former game developer and author of the first major WebGL based raster image editors, David has long since pushed the envelope of web-based computer graphics. Within Melown Technologies, David is a crucial contributor to the vts-browser-js, the JavaScript client library forming part of VTS 3D Geospatial Software Stack.