[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hidden composites

   Reply-To: Hilmar Schlegel <hshlgaii@mailszrz.zrz.tu-berlin.de>

   >    I wrote (thinking about extracting information from PFA/PFB files):
   >    probably go for the composite character entries).  I'd be really interested
   >    if someone who knows could enlighten me, just for curiosity's sake.

   > PFM's are rather anaemic.  They do not contain character bounding boxes.
   > They contain no information on unencoded characters.  They do not have

   Which means kerns for unencoded characters are definitively lost...
   (Examples are fi, fl on a PC)

Yes.  Which is one of the reasons having the actual AFM file is better.
Not that any AFM files I have sen have any kern pairs with fi and fl...

   >    (Similarly, I've never really understood why Adobe introduced PFMs and
   >    MMM files when they had AFMs and AMFMs, it just seems to add needless
   >    complexity and incompatibility to font issues.)

   > For the same reason TeX uses TFM's rather than say PL's: speed and
   > compactness.  For many fonts the AFM file is almost as large as the

   and for some half-hearted interface to make life easier for M$-Win:
   store win face names and little confused attribute bits ;-)
   The essential message would be here that PFM's do not contain the height of the
   individual characters in a font, which means that M$-win *cannot* access
   character heights and consequently uses the *font* bounding box as an ersatz.
   Given that is true *no* software getting metric information only from the M$-win 
   "fontsystem" and not directly from the fonts (AFM or PFB) will be able to
   produce reasonable typography. (Most people will know the line-spacing 
   problems in M$-word - when a font which has only a single "large" character 
   comes into play). Simply a design fault ;-)

Yes, if you only use the information in the font metric file you will not
have enough for TeX.  Which is why you either need the AFM, or PFAtoAFM
or DVIWindo to extract this information for you.  The information *IS*
available to a Windows program - even for unencoded characters.

   > I always make AFM or TFM files for my Multiple
   > Master instances directly from the installed font.

   Berthold, there is a little problem with that, however! This method
   doesn't work for the composites in multiple master fonts (in contrast to
   PFAtoAFM) - or do I miss here something?

Not sure why you say that?

Regards, Berthold.