Re: [Groff] URW fonts

[Clemens Ladisch]

Deri James wrote:
> One problem I see here is that this means that gropdf will be embedding every
> font that it uses (since it will be always using URW metrics for every font so
> can never use the internal Adobe version). Whilst this is not a bad thing from
> the point of view of fidelity of printing the document,

I've heard that Adobe recommends embedding for all fonts (because there
were different versions of the core fonts shipped with various Adobe
Readers, so it's not guaranteed that all extended characters are
included).

> [...]
> Of course, if I did add font subsetting this objection would be a lot less.
> The problem is that there are very few examples that I have found on the net
> showing how to do type 1 font subsetting correctly. The subsetting you see in
> PDF's produced by grops => ghostscript has been done by ghostscript not grops
> and is written as postscript code so ls a little hard to convert to perl! If
> anyone knows of some code I can look at which does that it would help.

I investigated something similar some time ago; there don't seem to be
any useful examples.

> So far
> I have written the code which can decrypt and encrypt the interesting portion
> of the the font which reveals the glyph definitions and the subrs they use,
> but , in the interests of speed I don't want to spend the processor time doing
> the second decode and parsing the glyph definitions to find which subrs are
> used in which glyph, so my plan is to copy the subrs section in full and just
> subset the glyph definition.

There are fonts that are quite optimized for size by moving as much
common code as possible into subrs.

I don't think the font embedding code would be a bottleneck.  With
today's memory cache behaviour, Type 1 decryption should not hurt.

If you want to save space (and avoid the encryption step), you should
convert the font to CFF/Type 2.  (That specification is very terse.)
In this case, you have to parse the charstrings anyway.

If you want to reduce font parsing time, you could require that fonts
must be converted to CFF or to some gropdf-specific format (or you could
run the converter automatically the first time a font is used).  For the
14 base fonts, you might want to convert them to a C data structure and
compile them into the program.

> So, back to Werner's .foundry, I like the idea but would like a way for gropdf
> to take advantage of the inbuilt Adobe versions of fonts when they are
> available.

The URW fonts are intended to be used as a transparent fallback for the
base fonts, so I think that groff should always use, e.g., the font name
/Times-Italic, and only the program that actually has to access the font
file should automatically map this to /NimbusRomNo9L-ReguItal if the
former cannot be found.

If gropdf assumes that the 14 base fonts are always available in the
reader, it then doesn't need to try to access the font.


Regards,
Clemens