groff
[Top][All Lists]
Advanced

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

Re: [Groff] URW fonts


From: Deri James
Subject: Re: [Groff] URW fonts
Date: Fri, 4 Feb 2011 12:25:38 +0000
User-agent: KMail/1.13.6 (Linux/2.6.33.7-desktop-2mnb; KDE/4.5.5; x86_64; ; )

On Friday 04 Feb 2011 08:34:57 Werner LEMBERG wrote:
> Folks,
> 
> 
> while discussing integration of gropdf into groff with Deri, he told
> me that gropdf essentially depends on downloadable PFA fonts to be
> included in the created PDF files.  This boils down to a dependency on
> the URW fonts of GhostScript.
> 
> From time to time people have asked whether URW fonts get added to the
> groff bundle, and I've always declined.  I still do so :-) However,
> the current idea is that at configure time it is checked whether the
> URW fonts are available, and only then gropdf is built, together with
> proper troff metric files (by calling afmtodit).
> 
> The question is how to get decent font names for the URW clones of the
> Adobe standard fonts which are backwards compatible at the same
> time...
> 
> What about adding a new request `.foundry' to troff so that the final
> font name consists of
> 
>   foundry + family + fontseries
> 
> for example
> 
>   URW + Times Roman + Italic ->  U + T + I  -> UTI
> 
> gropdf would then have
> 
>   .foundry U
> 
> in its init file by default.
> 
> If URW fonts are available, afmtodit could be simply called for devps
> also (at `make' time).  For -Tps, users could then say `.foundry U' to
> easily switch from Adobe metrics to URW metrics.
> 
> 
>     Werner

Hi Werner,

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, it would have an 
impact on the size of the PDF produced by gropdf (particularly since I have 
not implemented font subsetting yet). This would lead to queries as to why 
gropdf produced PDF's are larger than the grops => ghostscript route, and 
given one of my main criteria for doing gropdf was to speed up the PDF 
production route embedding all used fonts without any subsetting is not going 
to help!

I am not really a typical groff user because my usual groff runs last for 
hours and produce millions of pages! So speed is one of my main requirements.

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. 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. But I don't know if this is a feasible strategy 
until I've tried it, if anyone has experience/knowledge in this area any 
advice would be much appreciated.

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.

Cheers 

Deri



reply via email to

[Prev in Thread] Current Thread [Next in Thread]