NAME

       PDF::Builder::Resource::Font - some common support routines for font files. Inherits from
       PDF::Builder::Resource::BaseFont

METHODS

       $font->automap()
           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.

perl v5.32.1                                       2021-09-15                  PDF::Builder::Resource::Font(3pm)