This applies to core fonts
("$pdf->corefont()") and PostScript
fonts ("$pdf->psfont()"). These
cannot use UTF-8 (or other multibyte character) encoded text; only single
byte characters. This limits a font to a maximum of 256 glyphs (the
"standard" single-byte encoding being used). Any other glyphs
supplied with the font are inaccessible.
"automap" splits a font
containing more than 256 glyphs into "planes" of single byte
fonts of up to 256 glyphs, so that all glyphs may be accessed in
separate "fonts". An array of new fonts will be returned, with
[0] being the standard code page (of the selected encoding). If there
are any glyphs beyond xFF on the standard encoding page, they will be
returned in one or more additional fonts of 223 glyphs each. Why
223? The first 32 are reserved as control characters (although they
have no glyphs), and number x20 is a space. This, plus 223, gives 256 in
total (the last plane may have fewer than 223 glyphs). These
"fonts" are temporary (dynamic), though as usable as any other
font.
Note that a plane may be empty (only space at
x20 and possibly an unusable character at x21) if the previous plane was
full. You might want to check if any character in the plane has a
Unicode value (if not, it's empty).
The ordering of these 223 glyphs in each following
plane does not appear to follow any particular official scheme,
so be sure to reference something like
"examples/020_corefonts" to see what
is available, and what code point a glyph is at (e.g., an 'A' in the
text stream will print something different if you're not on plane 0).
For a given font file, they should be consistent. For
instance, in Times-Roman core font, an \x21 or ! in plane[1] should
always give an A+macron. Further note that new editions of font files
released in the future may have changes to the glyph list and the
ordering (affecting which plane a glyph appears on), so use
automap() with caution. It appears that glyphs are sorted by
Unicode number, but if a new glyph is inserted, it would bump other
glyphs to new positions, and even to the next plane.
An example:
$fnt = $pdf->corefont('Times-Roman', -encode => 'latin1');
@planes = ($fnt, $fnt->automap()); # two planes
$text->font($planes[0], 15); # or just $fnt will work
$text->text('!'); # prints !
$text->font($planes[1], 15);
$text->text('!'); # prints A+macron
If you had used 'latin2' encoding, an \x21 on plane 1 will
give an inverted ! (¡ HTML entity).
Note that
"$planes[$n]->fontname()" should
always be the desired base font (e.g., Times-Roman), while
"$planes[$n]->name()" will be the
font ID (e.g., TiRoCBC) for plane 0, while for other planes there
will be a unique suffix added (e.g., TiRoCBCam0).
If you have just an occasional non-plane 0 character (or run
of characters), it may be tolerable to switch back and forth between
planes like this, just as typing an HTML entity once in a while when you
need a Greek letter on a web page is acceptable to most people. However,
if you're typing a lot of Greek text, a dedicated keyboard may be better
for you. Like that, switching to a TTF font in order to be able to use
UTF-8 may be easier.