summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-05-14Add glyph-headersHEADmasterDavid Herrmann6-262/+334
Similar to a global header, we now add a header to each glyph. This makes extending single glyphs much easier and we don't have to append it at the end. Also replace the previous test with a more advanced one. Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2014-05-14test: skip tests if the font-file is not availableDavid Herrmann1-6/+9
"make distcheck" runs "make check" before running "make install" so the font-file might not be available. Skip the tests if so. Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2014-05-14build: include compile-unifont.py in distDavid Herrmann1-0/+1
We require compile-unifont.py to actually build the font file, so include it in dist-tarballs. Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2014-05-14build: add DOCUMENTATIONDavid Herrmann1-1/+129
Add a format/package documentation so users actually know how mmap-unifont works. Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
2014-05-14Initial importDavid Herrmann15-0/+64358
Import new mmap-unifont package, a pre-compiled version of the GNU-Unifont font files: GNU-Unifont is a bitmap Unicode font with almost complete Unicode coverage. It is perfectly suited for low-level system binaries, as fallback font, in emergency situations, and more. mmap-unifont compiles a binary font format based on GNU-Unifont. This compiled file can be memory-mapped by applications to get direct font-access. This extremely simplifies font-usage for system-applications. Advantages over using the original BDF font are: * On-demand glyph loading: The whole font is pre-compiled with fixed offsets. The header includes offsets and limits. Hence, an application can directly access the memory-location of a glyph on-demand. The operating-system can load the required memory-pages on first-access, thus reducing the memory footprint considerably. With BDF fonts, the application has to scan the whole BDF file to find a given glyph. This requires loading 9MB of font-data just to display the U+FFFD glyph. * No need to write a BDF-format parser: While BDF is a quite simple format, it still requires a parser. This is tedious and overkill, if you don't intend to use other fonts than GNU-Unifont. * Stronger guarantees: GNU-Unifont has some very handy features, which cannot be expressed in most font-formats. While it is possible to rely on them using any font-format, you usually violate the rules of the font-format and thus make your application dependent on GNU-Unifont (questioning why you wrote a BDF-parser in the first place). Those features include: * fixed size for all glyphs * fixed underline position and thickness * fixed horizontal/vertical advancement * ... * Additional annotations: Given the very precice use-case of mmap-unifont, we can add additional glyph-annotations that simplify rendering. For instance, combining-characters require you to draw multiple glyphs on top of each other. The mmap-unifont package provides annotations that describe the relative positioning of the glyphs when drawn together. mmap-unifont is strongly targetted at system-applications. It has no external dependencies, is very memory-friendly, but still provides a font with full Unicode-coverage. However, please note that it does not provide any advanced layout-features (like RTL/LTR annotations). To render fully-internationalized text, a layout-engine like HarfBuzz/Pango is required. Signed-off-by: David Herrmann <dh.herrmann@gmail.com>