[reportlab-users] ttfonts in renderPM

Robin Becker reportlab-users@reportlab.com
Wed, 12 Nov 2003 11:16:33 +0000


I have had some success in adding TTF support to renderPM. The current
state of play is that if freetype2 is available and made known to
setup.py we can compile _renderPM to support truetype.

It works as follows.

1) register the font in the normal way using
        pdfmetrics.registerFont(ttfonts.TTFont(fontName, ttf_filename))

2) use it.
        String(x, y, text, fontName=fontName, fontSize = fontSize)

Internals
=========
We are currently still using the original mechanism and also freetype to
get the curves for drawing fonts. So when setFont is called on a
_renderPM.gstate the search is as follows

  check to see if any gt1 parsed font is known if yes then use it

  if pdfmetrics fonts dictionary has a font[name]:
    if font[name]._ft_face exists: use that for freetype
    elif font[name]._ttf_data exists:
      font[name]._ft_face = FT_New_Memory_Face(.....)
    else:
      fail

    return use the _ft_face as the current font.

If the above fails we are currently allowing an attempt at using
  pdfmetrics.getFont(fontName) to locate a suitable font.
this currently will only search for T1 fonts. If a font is found in this
last gasp we then assume it's T1 and use _renderPM.makeT1Font(fontName,f
.face.findT1File(),f.encoding.vector) to get it known. getFont could be
extended to dynamically load other fonts, but we would then need to
avoid the makeT1Font if the discovered font wasn't of the required kind.

If the above succeeds we set the gstate's font to be either a gt1 font
or a freetype face. We have to keep extra state to allow the curve
generation mechanism to distinguish between the different font kinds.

Problems
========
One problem with the above is that we have two mechanisms for font
curves, we could use a modified scheme to use FT for type 1 as well.

Another problem is that even registered T1 fonts require us to check

Future
======
There's no particular preference for TTF in the above. If we start using
OTF then it can be adapted easily to do that as well.

The current scheme is not caching glyphs/curves so it is probably not
very time efficient. It does cache the face (using the _ft_face
attribute).
-- 
Robin Becker