Re: Type 42

[David Turner]

Hi Sivan,

> 
> Hi,
> 
> I am going to supervise a group of students who will do a project
> whose aim is to produce postscript font files to include in print
> jobs. (That is, the printer driver will ask this piece of software
> to generate font files for the fonts in a document, to be included
> in the postscript output file; most likely this will be used
> in a printer driver for Qt/KDE). Ideally these fonts would be
> only the subset of the glyphs needed for a particular document.
> 
> There are 3 or 4 ways to produce the font files for downloading:
> 1) produce bit maps; we can use FreeType with the existing API
> 2) produce unhinted outlines (either at device resolution or device
> independent); same here.
> 3) produce a Type42 font file, which is a postcript wrapper
>    for a truetype font. No support in TrueType
> 
> Which method you want use depends on the printer (support for 42?)
> on how many sized you use, and on further processing (distill to pdf).
> 
> We can write a Type42 converter (more likely hack an existing one
> to subset fonts), but a lot of the TTF parsing machinery would
> be the same as in FreeType (finding table and glyph locations and
> sizes, for example).  Same goes for a Type1 ascii encoder and subsetter.
> 
> Do you think that it would be better to write something that
> uses FreeType where possible but is separate, or to integrate this
> feature more tightly with FreeType?
> 

There are basically two ways to support Type42 fonts with FreeType2:

- one is to write a font driver that would be able to manage the postscript
  "wrapper", and use the TrueType driver to manage data within it.

- the other one is to support manage the wrapper yourself (this is important
  if you are a Postscript interpreter like Ghostscript) and provide a custom
  stream object in order to use the TrueType driver directly..

The first solution would need some work. It's do-able, but I'm really
doubtful that it had any real interest, given that the only programs
that need to support these fonts are Postscript interpreters (well, I
may be wrong, so please let me know if this isn't true).

I'll know talk about the second method:

There are already hooks in the FreeType 2 TrueType driver to support
Type42 fonts, but it's true that I haven't completed this yet. Could
you tell me if the following scheme would allow you to support these
fonts in your application (it'd need a few changes that I'm ready
to commit if you agree with this):

  - you would need to provide your custom implementation of
    the "stream" object (see <freetype/ftsystem.h>) to access
    the data inside the encoded font file

  - you will need to provide an alternative to the function
    TT_Goto_Table, defined in "src/sfnt/ttload.c" (line 102).
    

  basically, all tables are accessed through a line like:

    error = face->goto_table( face, table_tag, stream, &length );

  "goto_table" is a field of TT_FaceRec which is set by default (in 
TT_Init_Face)
  to TT_Goto_Table. However, you could provide your own implementation to
  seek to the data you need within your Type42 font. Its purpose is
  simple to "seek" the stream to the start of the table, and return its
  size in bytes in the "length" variable..

  You would thus need something like the following to open a new font file:

    ... create your own stream object, named "my_stream"
    {
      FT_Open_Args   open;
      FT_Parameter   parameter;

      /* this extra parameter is used to pass the address of a substitue for */
      /* TT_Goto_Table                                                       */
      parameter.tag  = FT_MAKE_TAG('g','o','t','o');
      parameter.data = your_implementation_of_tt_goto_table;

      /* this indicates that we will open a new face with a custom stream, */
      /* and that we'll pass one parameter to the font driver..            */
      open.flags  = ft_open_stream | ft_open_params;
      open.stream = my_stream;
      open.num_params = 1;
      open.params     = &parameter;

      error = FT_Open_Face( library, &open, 0, &face );
    }

  Note that the stream will be normally seeked to load the table directory
  though. We could also add an additional parameter to the font driver to
  specify the function to use to load the latter..


So, would this fit your needs ?? It so, I only need to change TT_Init_Face
in order to recognize the extra parameter..

Best regards,

- David

> Sivan Toledo