"Victor Mote" <[EMAIL PROTECTED]> wrote on 24.05.2004 18:12:36:

> One of the changes that will probably need to be made to FOP's font 
handling
> is to parse AFM files instead of PFMs. I have assumed that for hardware
> fonts, either the device manufacturer provides font metrics files or 
enough
> information so that they can be built. Adobe, for example, provides 
metrics
> for the base-35 PostScript device fonts here:
> ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/

This is what did in my formatter. I have implemented an AFM reader (though 
I
ignore the kerning infos so far) and use this to read the Adobe base fonts 

- for example.
 
> So my *plan* has been that these fonts get treated pretty much like any
> other font. The only thing about the hardware font is that it can't be
> embedded -- it is already embedded all of the places that it can be.

Depends. Every PDF compliant reader/printer has to support 
Adobe's standard Helvetica, Times Roman, Courier, Symbol and Zapf Dingbats
fonts (metrics-compatible alternatives at least). So it makes sense for a
PDF renderer to supply these fonts metrics to a formatter to say
"hey, I can render these".

> Are you suggesting that FOP / FOray needs to actually query the hardware
> device and extract metrics information directly from it? Or is the plan 
I
> have outlined above sufficient?

Well, it really depends how far you want to go. Device fonts have 
certainly
seen days of higher importance... But still, from time to time you stumble
upon people who need (or want) to use fonts that they have no exact 
software
equivalent for. Whether this means accessing the device directly or 
indirectly
using a printer driver or by means of supplying metric files is a side 
issue,
I think. Let's just say a renderer should be able to supply fonts 
(metric-only
or complete) to the formatter.

To give you an extreme example: In the high-volume output market, the 
format
of choice is still AFP by IBM. This is (but today's standards) a rather
obscure format that has ancient origins in the GKS system and is very
similar to the metafile format in OS/2. Concerning fonts, however, you
mostly use bitmap fonts in the AFP world. Imagine a renderer that
has to support an output format that only allows (and supplies) bitmap 
fonts.

Sure, it's debatable whether one want to support this kind of thing - at 
least
by design. But, in any case, I think it highlights the extremes that can
happen in the font handling world.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Reply via email to