This tutorial describes Unifont, a bitmap-based font covering the Unicode Basic Multilingual Plane and beyond, and its utility programs.

Copyright © 2008--2014 Paul Hardy

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and no Back-Cover Texts.

Introduction
************

This document describes the process of using the GNU Unifont utilities to create a font.  The steps described in the "Using Graphical Tools" section in the "Tutorial" chapter are more or less the steps that I (Paul Hardy) followed to add thousands of glyphs to GNU Unifont, except that I didn't have the luxury of just typing make to make a new font while adding those glyphs in the beginning.

I streamlined the font build process after I was done drawing the Unicode 5.1 glyphs.

I know that plain ASCII text is *so* last millennium, especially for a package related to Unicode.  Yet ASCII can be read with anything; hence this format.

If you have questions, please email unifoundry@unifoundry.com. You can check for the latest Unifont news at http://savannah.gnu.org/projects/unifont and http://unifoundry.com. You can also submit a bug report through the http://savannah.gnu.org/projects/unifont page.

DISCLAIMER: Donald Knuth warned in his Metafont book that if someone started designing type, they would never again be able to look at a page of text normally and just read its content.  There is a point of no return beyond which a serious font designer begins looking at how individual letters in a font on a page are drawn, and how they might be improved.  Be warned!

--- Paul Hardy (unifoundry@unifoundry.com)  2008, 2013

Tutorial
********

This chapter provides a step-by-step tutorial on using the Unifont utility programs to modify a font in the GNU Unifont format.

Unicode
=======

Unicode is an international standard to encode all the world's scripts with one universal scheme.  Unicode is the default encoding for web pages and is gaining popularity in many other applications. To learn more about Unicode, look at code charts, and see the latest developments, check out

     http://unicode.org

Unifont follows the Unicode encoding scheme.  Unicode defines the numeric value of a character, but does not define one particular font.  There can be (and are) many fonts that support a subset of Unicode characters.

In 1998, Roman Czyborra observed that there was still no font, free or commercial, with complete Unicode coverage.  He envisioned a low-quality bitmapped font as an easy way to produce a font that covered much of the Unicode standard.

Unifont Structure
=================

GNU Unifont is a bitmapped pixel font, which is also converted to an outline TrueType font.  Roman Czyborra began this font in 1998 with a goal of having one glyph rendered for each visible character in the Unicode Basic Multilingual Plane (Plane 0, the first 65,536 characters).  His original writing on this is at http://czyborra.com/unifont/.

(Note that the term "character" is used very loosely here for simplicity; the Unicode Standard has a stricter definition of what constitutes a character.)

The font is dual-width.  Each character is 16 pixels tall, and either 8 or 16 pixels wide.  The characters are stored in a unique .hex file format invented by Roman Czyborra as a convenient way of giving each character exactly a one line specification. Conversion between this .hex format and BDF font format is trivial.

Hex File Format
===============

By convention, files containing the Unifont native font format have the extension ".hex".  Their format is extremely simple, consisting of two fields separated with a colon (":") and ending with a newline.

The first field is the Unicode code point, in hexadecimal.  For all Plane 0 code points, this is a four digit hexadecimal number.  Hexadecimal digits are (in order) 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, and F.  The Unicode Standard uses a hexadecimal number to assign each character a location.  These locations are called "code points" and their range is 0 through 10FFFF, inclusive.

The range 0000 through FFFF, inclusive, is called the Basic Multilingual Plane (BMP), or Plane 0.  This plane contains glyphs for most of the world's modern writing scripts.

Unifont utilities support glyphs across the entire Unicode range. The current distribution includes glyphs for Unicode's Plane 0, Plane 1 (the Supplemental Multilingual Plane, or SMP), and others. Coverage of the SMP is only partial.

The first field in a .hex file should be either four digits long for the Basic Multilingual Plane, or six digits long for higher Unicode planes, following the convention of the Unicode Standard.

The second field is a string of hexadecimal digits.  There are 32 digits for a character that is 8 pixels wide, and 64 digits for a character that is 16 pixels wide.

The good news is you don't have to worry about these long digit strings.  Roman Czyborra wrote a utility, hexdraw, to convert .hex fonts to a form that can be edited with a plain text editor, then converted back into .hex format.

Paul Hardy wrote two utilities to do the same thing except with bitmapped graphics images for editing with a graphics editor: unihex2bmp converts a block of 256 characters into a graphics file, and unibmp2hex converts such a graphics file back into .hex format.  These bitmaps display the 256 characters in a block arranged in a 16 by 16 character grid.  The graphics editor must maintain the image as a monochrome (black and white) file, with one bit per pixel.  After conversion from a .bmp file back to a .hex file, the next step is conversion to a BDF font file.  A BDF file can only encode a pixel being on or off (i.e., black or white only with no intermediate shades of gray).

Andrew Miller later converted unihex2bmp and unibmp2hex to Perl, then transformed them into unihex2png and unipng2hex, respectively.  These programs convert Unifont .hex files to and from Portable Network Graphics files.

These programs will probably handle glyphs beyond the BMP properly, but that capability is considered experimental, as the focus was to cover the BMP.  The unihex2png and unipng2hex programs handle the full Unicode code point range of 0x000000 through 0x10FFFF.  The unihex2bmp and unibmp2hex programs support the full 32-bit unsigned integer range of 0x00000000 through 0xFFFFFFFF, but have not been tested extensively beyond the Unicode BMP.  The range of the C programs might be truncated in the future to only cover to 0x10FFFF, the limit of the Unicode code point space.

The latest release of the hexdraw program works correctly with .hex files having code points in the full Unicode range of U+0000 through U+10FFFF.

Hex File Format
===============

Let's look at an example.  Suppose you want to modify the Coptic letters in the range U+2C80..U+2CFF ("U+" is Unicode shorthand).  These letters are in the upper half of the block U+2C00..U+2CFF.  The Unicode utilities in this package refer to this as "page" 2C. ("Page" is not a Unicode term --- it is just a term unique to this package to refer to a block of 256 code points/characters).

The steps to follow will be:

 1. Convert .hex version of the page 2C range as a 16 by 16 bitmapped grid.

 2. Modify the bitmap in any graphics editor, being careful to re-save it as a Windows Bitmap (.bmp) or Wireless Bitmap file when finished.

 3. Convert the modified bitmap back into a .hex font file.

 4. Merge the results with the original unifont.hex file (or whatever its name might be).

 5. Run unidup on the resulting file to guard against duplicate character definitions.

 6. Create the new bitmapped version of the font.

 7. Check the compiled font for duplicates.

 8. If there are duplicates, remove them and go back to Step 5.

 9. Create the new TrueType version or other versions of the font.

If the script has combining characters (such as accent glyphs), also add their code points to the proper *combining.txt file in the directory for the corresponding Unicode plane.  That way, when the font is converted to TrueType those glyphs will have zero space.  For a script with combining characters, all glyphs that can appear with combining characters must have the same width so that the combining characters will be properly positioned.

Step 1: Convert the .hex range into a bitmap grid. Assuming our font file is named unifont.hex, type

     unihex2bmp -p2C < unifont.hex > uni2C.bmp

Step 2: Modify uni2C.bmp with your favorite graphics editor. Note that whatever graphics editor you use must preserve the file as a black and white bitmap (monochrome), with one bit per pixel.  During editing, you can draw guidelines outside the actual 16x16 font pixel area; they will be ignored when converting back into .hex format.  You can also erase the grid borders between code points on purpose or by accident, and it will have no effect on the generated .hex file.  Just don't erase the code point numbers on the outer edges of the grid.  The conversion from .bmp back to .hex only looks at the "U+0000" in the upper left-hand corner of the bitmap graphic and other code point numbers, and at each code point's 16x16 pixel area inside its 32x32 pixel grid area.  Every other artifact in the final graphics file outside these areas is ignored.

If a new version of Unicode adds glyphs to a page that were previously unassigned, be sure to remove the newly-assigned code points from the unassigned.hex file because the code point is no longer unassigned.

Step 3: Convert the edited .bmp file back into .hex format:

     unibmp2hex < uni2C.bmp > uni2C.hex

Note that the conversion from a bitmap image to a .hex file can't distinguish between a legitimate single- or double-width space character and a code point that does not have an assigned value.  Therefore, space glyphs are separately contained in the spaces.hex file.

Step 4: Merge the results with the original unifont.hex file. This requires several sub-steps:

  * Edit the original unifont.hex file and delete the lines that begin with "2C".

  * Insert the uni2C.hex file into unifont.hex, either with a text editor such as emacs or vi, or with a GNU/Linux command such as:

          sort uni2C.hex unifont.hex > new-unifont.hex

     This second option (using sort) is preferred, because unidup (in Step 5) might miss duplicate code points if your final result isn't in proper order.

Step 5: Make sure there are no duplicates with unidup:

     unidup < unifont.hex

or

     unidup < new-unifont.hex

depending on the name of your final font file.  If there is no output, your modified font contains no duplicates.

This editing is best done on an input .hex file, such as unifont-base.hex.

Step 6: Create the new bitmapped version of the font.  In the font/ directory, type

     make hex

Step 7: Check the compiled font for duplicates.  Change to the font/compiled/ directory and run

     unidup < mynewfontfile.hex

for whatever font file you created.

Step 8: If there are duplicates, remove them in the font/ directory and go back to Step 5.

Step 9: Create the new TrueType version of the font and all other bitmapped versions.  From the font/ directory, type

     make distclean && make

Then be prepared to wait a long time unless you are using a computer with plenty of RAM and CPU horsepower.  Your computer should have at least 256 Megabytes of virtual memory (RAM), and at least 250 Megabytes of free disk space.

To only create a BDF font, in the font/ directory just type

     make bdf

To only create a BDF and PCF font, in the font/ directory type

     make pcf

Creating a BDF font is the first step in creating a PCF font (not counting generating the compiled master ".hex" input file). BDF fonts can be created just with the tools in this package. PCF fonts are created by running bdftopcf on the BDF font. TrueType fonts require FontForge.

The Unifont package also includes two new programs for working with Portable Network Graphics (PNG) files instead of BMP files.  These utilities are unihex2png and unipng2hex.  They work in a similar manner to the corresponding programs unihex2bmp and unibmp2hex, respectively.

To use unihex2png instead of unihex2bmp, continuing the example of the Coptic script in the U+2Cxx range, type:

     unihex2png -p 2C -i unifont.hex -o uni2C.png

Note that with unihex2bmp specifying input and output files is optional, while with unihex2png at least the PNG filename must be specified explicitly.  More specifically, unihex2png will read a .hex file format input from STDIN if no "-i" argument is specified, but the name of the binary PNG file must always be specified with the "-o" option.

Then edit the resulting PNG file to your heart's content.  When done, convert the file back into a unifont.hex format file.  In this example, type:

     unipng2hex -i uni2C.png -o uni2C.hex

Similar to unihex2png, the binary PNG file must be specified with "-i" but the .hex format file will be written to STDOUT if the "-o" option is omitted.

Finally, merge  your changes in with your main .hex font file as described previously in this section.

Using Hexdraw
=============

Roman Czyborra's original utility to edit glyphs is the hexdraw Perl script.  Using the same script as in the previous chapter, Coptic, here are the steps for modifying unifont.hex using hexdraw.

First, realize that Unifont has tens of thousands of glyphs (characters, using the term character loosely).  In this example, out of the tens of thousands of glyphs, we want to modify the range U+2C80..U+2CFF (only 128 glyphs).

The range U+2C80..U+2CFF could be extracted from unifont.hex by using the egrep utility to look for lines beginning with "2C8" through "2CF", or that range could be isolated by copying unifont.hex into another file, and deleting all lines except the desired range.

The following steps will probably minimize typographical errors, but they aren't the only way.

 1. "Grep" the desired block of 256 glyphs (using the grep utility) and convert this into a text representation for editing.

 2. Edit the block with a text editor, such as emacs or vi.

 3. Convert the edited text file back into .hex format.

 4. Delete the edited block range from the original font file.

 5. Merge the two .hex files into one file.

 6. Check for duplicates with unidup.

 7. Generate new fonts as described in the "Using Graphical Tools" section above.

Step 1: Extract the desired block with grep:

     grep "^2C" unifont.hex | hexdraw > uni2C.txt

Step 2: Edit uni2C.txt with a text editor.

Step 3: Convert the text file back into .hex format:

     hexdraw < uni2C.txt > uni2C.hex

Step 4: Delete the lines in the original unifont.hex file that begin with "2C".

Step 5: Merge the two files:

     sort unifont.hex uni2C.hex > new-unifont.hex

or use Roman's hexmerge utility:

     hexmerge unifont.hex uni2C.hex > new-unifont.hex

Step 6: Check for duplicates:

     unidup < new-unifont.hex

Of course, remove any reported duplicates.

Step 7: Build the font as in the "Using Graphical Tools" section above.  This can be as simple as typing

     make

in the font/ directory.

I (Paul Hardy) had only used hexdraw in the very beginning of my work on Unifont.  Once I got my graphics programs working, I ignored it for months.  Then I wanted to go through all of the Yi Syllables and Yi Radicals --- over 1000 glyphs --- to fine-tune their horizontal alignment after I drew them.  hexdraw turned out to be the perfect tool for this.  By printing hyphens ("-") as place holders where a pixel is off, it allowed me to verify space to the left and right of each character.  I later used hexdraw for similar fine-tuning of spacing on Hangul and other glyphs. It is ideal for the task.

Checking Coverage
=================

There should never be duplicates in a .hex file.  If there are, remove them before the .hex font is turned into a BDF or other font file.  The recommendations above include making liberal use of unidup to avoid such a situation.

The unipagecount program will print a hexadecimal number of code points that have coverage within each 256 code point block.  The hexadecimal number will therefore range from 0 (no coverage) to 100 (= 256 decimal; full coverage).  If a number is ever more than 100 hexadecimal, there's an extra character (glyph) for that page.

To further look at the coverage within just one 256 code point page (using page 2C, containing Coptic, as our example) use

     unipagecount -p2C < unifont.hex

Note that the "page number" can use upper- or lower-case letters: -p2C or -p2c will both work.  That will print a 16 x 16 grid of U+2C00..U+2CFF.  Of course, without placeholder glyphs for the unassigned code points from unassigned.hex in the U+2C00..U+2CFF range, unipagecount can give a lower number than the true coverage.

Using the -l flag with unipagecount will produce an HTML table with links to corresponding graphics images.  You can get an idea of how this works in the font/compiled/ directory after running make; the index.html file in that directory will have a table with links to the 256 glyph maps in the font/compiled/bmp/ subdirectory.

With unipagecount, the background color of the cells will range from red (for 0% complete in that 256 code point block) to orange (a little coverage) to yellow (more coverage) to green (complete coverage).  If a cell looks light red or pink, the corresponding code page probably has duplicate characters. Verify that with

     sort unifont.hex | unidup

(substituting the name of your .hex file for unifont.hex).

To see the coverage of each Unicode script, copy the file font/coverage.dat into the same directory as the unifont.hex file you're examining.  Then run

     unicoverage < unifont.hex > coverage.out

This will give you all the scripts within the Unicode Basic Multilingual Plane, in order, with a percentage (0.0% through 100.0%) of each script's coverage.  Note that to get the true coverage of assigned code points, you'll have to merge unassigned.hex with the rest of unifont.hex if not done by default in your setup.

Using the .hex files in font/plane00/, you can create a font with all available glyphs with

     sort font/plane00/*.hex >unifont-whole.hex

and run unicoverage using the resulting unifont-whole.hex file.

Custom Builds
=============

The font can be built from within the font/ directory by simply typing

     make

From the top-level directory (one level above the font/ directory), typing

     make BUILDFONT=1

will also build the font.  The font is not built by default by typing make from the top-level directory, because a pre-built version already exists in the font/precompiled/ directory.  Font files are architecture-independent, so the only reason to build the font is if you modify its composition.

By default, source glyphs are read from the font/plane00/ directory. Glyphs for unassigned code points are built into the font by default, but glyphs for Private Use Area code points are not built into the font.

All of the .hex file names can be replaced selectively on the make command line to override their default values. Their locations are relative to the font/ directory. The list of component hex file variables is:

UNIFONTBASE
     The bulk of Unifont scripts

CJK
     Most of the CJK Ideographs

HANGUL
     Hangul Syllables block

SPACES
     Space glyphs, single- and double-width

UNASSIGNED
     Glyphs for unassigned code points

PUA
     Glyphs for the Private Use Area

So, for example, to build a font that includes four-digit hexadecimal code point glyphs (as white digits on a black background) for the Private Use Area, type

     make PUA="plane00/pua.hex"

because those glyphs reside in the font/plane00/pua.hex file.

To build a font that includes your own special PUA glyphs, type

     make PUA="my-cool-PUA.hex"

or whatever the name of your PUA glyph .hex file is named.

To create a build that includes the supplied PUA glyphs but not the unassigned code point glyphs, type

     make PUA="plane00/pua.hex" UNASSIGNED=""

If you create a custom font build of your own in one gigantic file, you can build with just this file by declaring all the ordinary files to be null:

     make UNIFONTBASE="mycustomfont.hex" \

     CJK="" HANGUL="" UNASSIGNED="" PUA=""

Note that this command did not include an override for the glyphs for spaces contained in the font/plane00/spaces.hex file; that is, the variable SPACES was not redefined on the command line.  You could also pass the argument SPACES="", but just be aware that those spaces glyphs are in a separate file for a reason.  When graphical (".bmp") glyph files are converted back into hex string (".hex") format, the unibmp2hex utility doesn't know if a blank glyph area is a space glyph or not, so it doesn't encode anything.  The font/plane00/spaces.hex file contains glyphs that are strings of 0s, with length depending on whether the space is nominally a single- or double-width space.  (Unifont does not distinguish between finer spacing used in traditional typesetting, such as a thin space, en space, em space, or quad space; all spaces are either 8 pixels wide or 16 pixels wide.)

Seeing the Big Picture (Literally!)
===================================

The GNU Unifont 6.3 release introduced a new program, unifontpic. This produces a chart of all the Basic Multilingual Plane glyphs in Unifont.  By default the chart is arranged as a 256-by-256 glyph table.  Specifying the -l option produces a chart that is 16 glyphs wide by 4,096 glyphs long.  See unifontpic(1) for more information.

The "long" version, created with unifontpic -l, only produces 16 glyphs per row.  This is more useful for scrolling through on a computer screen.

GIMP, the GNU Image Manipulation Program, will properly display the resulting long .bmp file (at least under GNOME), but not all graphics utilities can.  The output file is over 65,536 pixel rows tall, which causes problems with some graphics programs.

To generate a chart with all your glyphs in one giant unifont.hex file, type the command

     unifontpic < unifont.hex > unifont.bmp

The output is a monochrome Bitmap Graphics Format (.bmp) file. If you prefer PNG files, use your favorite graphics program or conversion program to convert the BMP file to a PNG file.

This utility is especially useful if you're customizing the font, for example if adding your own Private Use Area glyphs.

The default 256-by-256 code point chart will render satisfactorily on a sheet of paper approximately 3 feet by 3 feet (1 meter by 1 meter) at 120 dots per inch.  Thus the square format is suitable for printing.

Combining Circles
=================

The earliest versions of Unifont (before the 5.1 release) used glyphs that showed dashed circles for combining characters.  This is how the glyphs appear in The Unicode Standard code charts.  In version 5.1, Paul Hardy was able to get combining characters to appear superimposed correctly in the TrueType version of the font.  (There are no plans to try to get combining characters to work in a BDF or PCF version owing to the limitations of those bitmapped font formats.)

With combining characters working in the TrueType font, Paul Hardy created variations of Unifont with and without combining circles, the idea being that the version without combining circles would be used to create the TrueType font.  The variation with combining circles was kept for reference.

Unifont Version 6.2 simplified the build to produce only one font variation, without combining circles.

Unifont Version 6.3 introduced a new utility, unigencircles, to superimpose combining circles over glyphs with code points in a combining.txt file.

The latest Unifont release contains a parallel set of font files named unifont_sample.*.  These "Unifont Sample" font files contain glyphs with combining circles where appropriate.  The "Unifont Sample" font is therefore not intended for general-purpose writing, but only for illustrating each individual glyph as represented in The Unicode Standard.

To run unigencircles, start with the file font/ttfsrc/combining.txt and type a command of this form:

     unigencircles combining.txt < unifont.hex > unifont-circles.hex

where unifont.hex is a single file containing all the glyphs you wish to render.  You could create such a file from the font/ directory with the command

     sort plane00/*.hex >unifont.hex

Because the output is another .hex file, you can use all Unifont utilities with this resulting file just as you would with the .hex files in font/plane00/.

If you want to build a font from this generated unifont.hex file, you could type

     make UNIFONTBASE="unifont-circles.hex" CJK="" HANGUL="" \

     UNASSIGNED="" PUA=""

as discussed above.  In this case, if you included font/plane00/spaces.hex in the unifont.hex input file, you should also set SPACES="" on the command line so that you only read in your final custom unifont-circles.hex file.

Installing Fonts on GNU/Linux
=============================

The original standard font format of Unifont was a BDF font.  The newer PCF font format loads much faster when a program begins, and so is preferable for installations using the X Window System and similar environments.

Compress PCF fonts using

     gzip -9 fontname.pcf

Copy the resulting fontname.pcf.gz file to /usr/share/fonts/X11/misc/ or place in a local font directory if your windowing software supports that (for example, ~/.fonts/).

Copy TrueType fonts to /usr/share/fonts/truetype/ uncompressed or place in your local font directory.  Note: on some versions of Unix, such as Solaris, the name of the TrueType directory might be TrueType and might be under /usr/share/fonts/X11/ --- examine the system fonts directories, then modify the font make install rule accordingly.

On most flavors of GNU/Linux with the latest xset utility (including the latest Debian and Red Hat releases), the following command should allow you to start using the font immediately:

     xset fp rehash

The safest way to make sure the system knows about the new fonts will be to restart the X Window System or even reboot.

Creating a Brand New Font
=========================

The original tools will only produce glyphs that are 16 pixels tall, and either 8 or 16 pixels wide.  The utilities unihex2png, unipng2hex, hexdraw, and hex2bdf now also support glyph heights of 24 and 32 pixels, and glyph widths of 8, 16, 24, and 32 pixels, but this is not fully tested.  These new dimensions are currently available for experimental use.  See the respective sections for each of these programs in the Reference chapter of this document, or their respective man pages.

To create a brand new font (or even to add a new script to Unifont in the future), plan out the basic dimensions of the characters:

  * How far above the lowest pixel will the baseline appear (in other words, how many rows are necessary for descenders such as in the glyphs for `g', `q', and `y')?

  * How many pixels must be empty on top and bottom for accents (in other words, what will the height of capital letters be)?

  * Must glyphs be centered, left-aligned, or right-aligned?

  * For a Latin font, what will the "x-height" be (the height of a lower-case "x" and related letters, such as "n" and "r")?

Consistent capital heights, x-heights, descender depths, and centering will produce a better looking font.  Look over the entire script and plan out a template grid that is consistent for the entire script. Then use that template for each glyph you draw for the script.

Unifont characters for the most part leave the left-most or right-most column of pixels blank if possible (consistent within each script) for left-to-right scripts.  Centering is done around the fourth pixel (if a glyph is eight pixels wide) or around the eighth pixel (if a glyph is 16 pixels wide).

Experimenting and (above all) having fun with these utilities is the best way to learn.

Updates to Unicode
==================

If a currently unassigned code point is assigned to a character in the future, the font can be updated as follows:

 1. Delete the code point's entry from font/plane00/unassigned.hex, as that code point will no longer be unassigned.

 2. Determine which existing .hex file should contain the newly defined character (examine the files to see which one contains other glyphs in the script.

       * unifont-base.hex contains most scripts

       * wqy.hex contains most CJK ideographs; its name pays homage to the Wen Quan Yi font, the source of almost all of its glyphs

       * hangul-syllables.hex contains the Hangul Syllables block (U+AC00..U+D7A3); this should never have new code points added as it covers the fixed range of the Unicode Hangul Syllables block

       * spaces.hex contains the list of single- and double-width spaces

     If in doubt (for example, if a new script is added to Unicode and you're not sure which .hex file to augment), add the new glyphs to unifont-base.hex.

 3. Update the appropriate .hex file.

 4. Consider if font/coverage.dat has to be updated. Follow its existing format to insert a new script, being sure to change any previously unassigned ranges before or after the newly added script.

 5. Make a new .hex version of the font, and verify that you didn't introduce any duplicates.

 6. Run unipagecount and/or unicoverage as described previously to verify that you have not mistakenly deleted any existing characters.

Enjoy!

Reference
*********

     [file bdfimplode.texi not included]
     [file hex2bdf.texi not included]
     [file hex2sfd.texi not included]
     [file hexbraille.texi not included]
     [file hexdraw.texi not included]
     [file hexkinya.texi not included]
     [file hexmerge.texi not included]
     [file johab2ucs2.texi not included]
     [file unibdf2hex.texi not included]
     [file unibmp2hex.texi not included]
     [file unicoverage.texi not included]
     [file unidup.texi not included]
     [file unifontchojung.texi not included]
     [file unifontksx.texi not included]
     [file unifontpic.texi not included]
     [file unigencircles.texi not included]
     [file unigenwidth.texi not included]
     [file unihex2bmp.texi not included]
     [file unihex2png.texi not included]
     [file unihexgen.texi not included]
     [file unipagecount.texi not included]
     [file unipng2hex.texi not included]