[Top][All Lists]
[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