[reportlab-users] fonts.py & RegisterFonts

[Robin Becker]

In article <1520.82.43.152.119.1054278315.squirrel@webmail.pair.com>,
Andy Robinson <andy@reportlab.com> writes
>Ian Sparks said:
>> As Marc Stober identified in a recent post you can't register some fonts
>> with registerFont() because fonts.py identifies a whole set of
>> font-names that are supposedly "registered" which in fact are not part
>> of the standard PDF set.
>>
>> At the end of this message is the guilty dictionary in fonts.py which is
>> the reason Marc can't register his 'verdana' font and I can't register
>> an 'Arial' font. For now I'm working round it by registering my font as
>> 'XArial' (yuk).
>>
>> Still, there must be a reason for this stuff in here...
>Wow, I didn't know that had crept in and am not happy about
>it.  The 'standard 14' postscript fonts are there for
>a reason, but we should never have coded reference to
>truetype fonts.
>
>Will anything break for anyone if it is just removed?
>This stuff should really be part of some per-user
>font mapping file.
>
>
>- Andy
....this didn't creep in, it has been there since the beginning as the
reference to piddle attests. The problem was always to simulate having
font families and making them do something useful when <b> or <i> tags
get used.

The font registering stuff came afterwards and for a while things seemed
to be OK, but I think that was an accident of the way mappings are
ordered. In 2.2 certainly a number of problems have been reported and
the registration code certainly has difficulties using addMapping in
pdfmetrics.registerTypeFace.

Probably registerTypeFace should attempt to remove clashing things
before doing its fake mappings, but it would be better if one were able
to register a family of fonts.
-- 
Robin Becker