Using hbf2gf
-------------

hbf2gf converts CJK bitmaps with an HBF header file into .gf-files (and
consequently into .pk fonts).


Syntax:

    hbf2gf configuration_file

Keywords in the configuration file must start a line, the appropriate values
being on the same line separated with one or more blanks or tabs.


Here is an example configuration file jfs56.cfg (please refer to hbf2gf.dvi
for a description of the keywords):

hbf_header     jfs56.hbf
mag_x          1.482
design_size    10.0
target_size    12.0
x_offset       3
y_offset       -8
comment        jianti fansongti 56x56 pixel font scaled and adapted to 10pt

nmb_files      -1
tfm_files      yes

output_name    gsfs10

checksum       123456789

dpi_x          600
dpi_y          600

coding         codingscheme GB 2312-80 encoded TeX text

pk_directory   d:\china\pixel.ljh\720dpi\
tfm_directory  d:\china\tfm\

rm_command     del
cp_command     copy
long_extension off
job_extension  .cmd


And here the results:

    input files: jfs56.a - jfs56.e, jfs56.hbf

    program call: hbf2gf jfs56.cfg

    intermediate files: gsfs10.cmd, gsfs1001.gf - gsfs1032.gf, gsfs10.pl

    batch file call: gsfs10.cmd

    output files: d:\china\pixel.ljh\720dpi\gsfs1001.pk - gsfs1032.pk,
                  d:\china\tfm\gsfs1001.tfm - gsfs1032.tfm


[gsfs: GuoBiao simple encoded FanSong style
       ^       ^              ^  ^
It's hard to overcome the DOS restriction of 8 characters in a file name if
you need two characters as a running number...]


It is possible to convert bitmap fonts to .pk files almost automatically. The
HBF header file already has the entry `HBF_BITMAP_BOUNDING_BOX' which defines
vertical and horizontal offsets (in pixels), but these values are not in all
cases optimal for the desired target size. If you omit `x_offset' and
`y_offset' in the .cfg file, the third and fourth parameter of
`HBF_BITMAP_BOUNDING_BOX' is used, scaled to design size and magnified to
target size (to say it with other words: x_offset and y_offset will always
apply to the designsize to be synchronous with the .tfm files).

In the sample, you have a 56x56 bitmap font which will be scaled to 10pt and
then magnified to 12pt having a resolution of 600 dpi (in the ordinary case
you would suppress the creation of .tfm files for magnified fonts):

        1 pt are 600 / 72.27 = 8.3022 pixel;
        10 pt are 8.3022 x 10 = 83.022 pixel;
        thus the theoretical magnification value is 83.022 / 56 = 1.4825 .

But especially for small sizes, this may be not the best value if the font
should harmonize with, say, Knuth's Computer Modern fonts. I recommend to set
`nmb_files' to a value of 5 (or something similar) to compute 5 .pk fonts,
then check the CJK font with different TeX fonts to see whether the offsets
and/or the magnification value is good. If all is OK, set `nmb_files' to -1 to
get all .pk fonts. The greater the designsize the finer you can control the
offsets---as an example you could use a designsize of 30pt and a target size
of 12pt (nevertheless there is a compile-time constant MAX_CHAR_SIZE which
limits the maximal character size; default is 255 pixels).

If you have found optimal offsets, you can produce many different
magnifications of the CJK font using the same set of .tfm files analogous to
ordinary TeX fonts; just change target_size to the desired font size:

Assuming you've created a complete set of hanja fonts ksmi10 for 10pt
designsize, the proper entry in Uhanja.fd would be

\DeclareFontShape{U}{hanja}{m}{mj}{<5><6><7><8><9><10>
                                   <10.95><12><14.4>
                                   <17.28><20.74><24.88> CJK * ksmi10}{}


Compiling hbf2gf
----------------

You need GNU make and a GNU gcc; an executable for DOS and OS/2 is already
part of the package.

Say `make' to see the possible options. If necessary, touch hbf2gf.c (in case
you don't have ctangle).