[reportlab-users] Using non-standard fonts on Mac OS X

[Marius Gedminas]

--IiVenqGWf+H9Y6IX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 26, 2004 at 03:23:24PM +0100, Tim Jarman wrote:
> I copied the original Arial font file (using the cmd-R thing from FontBoo=
k to=20
> tell me its whereabouts) and ran fondu on my copy which got me a bunch=20
> of .ttf files (Arial, ArialBold, ArialItalic and ArialBoldItalic). When I=
=20
> pointed my test script at the new Arial.ttf it successfully created a TTF=
ont=20
> object -- but alas, it wouldn't register. I got a ValueError in addMappin=
g=20
> (fonts.py) suggesting it already *has* Arial registered. So I commented o=
ut=20
> the registration step and what do you know -- my test PDF file is created!
>=20
> I'm confused now... is font registration a one-off thing, i.e. something =
my=20
> installation procedure should do? I thought I was going to have to do the=
=20
> font magic as part of application startup but apparently not.

I believe this is a know problem.

There are two layers in Reportlab.  The base pdfgen layer considers each
of the variants of Arial (Arial.ttf, ArialBold.ttf and so on) to be a
completely separate font.  The Platypus layer considers all these to be
variants of the same font and knows how to map from a font name
("Arial") and a variant (Bold) to a pdfgen-registered font name.

Originally registerFont only registered fonts at the base layer, and you
had to manually call addMapping to tell Platypus about the mappings:

  from reportlab.pdfbase.pdfmetrics import registerFont
  registerFont(TTFont('XArial', 'Arial.ttf'))
  registerFont(TTFont('XArialI', 'Arial_Italic.ttf'))
  registerFont(TTFont('XArialB', 'Arial_Bold.ttf'))
  registerFont(TTFont('XArialBI', 'Arial_Bold_Italic.ttf'))

  from reportlab.lib.fonts import addMapping
  addMapping('Arial', 0, 0, 'XArial')
  addMapping('Arial', 0, 1, 'XArialI')
  addMapping('Arial', 1, 0, 'XArialB')
  addMapping('Arial', 1, 1, 'XArialBI')

I intentionally called the pdfgen-level font name 'XArial' to avoid
confusion with platypus-level name 'Arial', and to show that the font
name can be arbitrary.

Back to the problem: someone changed registerFont code to call
addMapping and register mappings for all four variants to the same font.
I do not understand the reason for that change.  The comment implies
that this change was targeted to PostScript CID fonts, and affects
TrueTypes accidentally, because those are also multibyte fonts.

So you have one problem: you cannot use all four variants of 'Arial' on
the platypus level, as they all map to the same base font.  You can work
around this by using a fake font name like XArial that I did before.

Then you also have another problem which you experienced: the default
Platypus mappings in lib/fonts.py already include a mapping for 'Arial':

  ('arial', 0, 0) :'Arial',
  ('arial', 1, 0) :'Arial-Bold',
  ('arial', 0, 1) :'Arial-Italic',
  ('arial', 1, 1) :'Arial-BoldItalic',

Therefore the first step of registerFont succeeds (pdfbase learns about
the font), but the second step, the addMapping call fails.

You could to work around this second issue by using a fake font
name on the platypus level.

Or you can comment out the addMapping calls in registerFont in
pdfbase/pdfmetrics.py and the default mapping for Arial in lib/fonts.py.

HTH,
Marius Gedminas
--=20
Apologies for taking up the bandwidth with the apology.  Anything else I
can apologise for ...... er no can't think of anything, sorry about that.
                Andy Hunt (Member of British Olympic Apology Squad)

--IiVenqGWf+H9Y6IX
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtNJkkVdEXeem148RAiS1AJ9QabyIqKU7bkw+8K+whUIC1UYbSQCdGrmU
3BE7W13iU2pOQ7zX6gXhsYY=
=FATk
-----END PGP SIGNATURE-----

--IiVenqGWf+H9Y6IX--