Re: [Groff] OT [= Old Thread ..!]: PDF problems - see attached f

[Alejandro López-Valencia]

Ted Harding wrote:
> On 28-Sep-03 Ted Harding wrote:
>> On 28-Sep-03 Bernhard Fisseni wrote:
>>>
>>> For me, the problem was solved when I used epstopdf (a gs wrapper
>>> script by Sebastian Rahtz distributed e.g. with teTeX) with gs 7;
>>
>> Thanks! I had not thought of going down this line, and it does seem
>> to solve the problem (at any rate for what I tried it with).
>
> Very interesting ... I have converted a PS file to PDF using standard
> ps2pdf and your suggestion of epstopdf.
>
> The ps2pdf conversion gave bad output; the epstopdf conversion on
> exactly the same file (produced by groff) had no faults. The
> following comparison between the PDF fonts (as shown by Document
> Properties) may be of interest, and certainly puzzles me as to how an
> apparenly simple change in the -call to gs with output-device =
> pdfwrite in both cases can make such a difference:
>

Ted,

I think I can throw a little light to your puzzled astonishment. :-)

First:

> 1. Using ps2pdf (bad output)
> ============================
> OriginalFont    Type    Encoding  UsedFont                  Type
> ------------------------------------------------------------------
> Times-Bold      Type 1  Standard  TimesNewRomanPS-BoldMT    Type 1

The metrics used by groff are Adobe's, as closer to the Type 0 fonts
included in most printer ROMs and the type 1s in Adobe's library as you can
get, but the metrics used by gs to create the PDF are those of the URW++
clones, and Acrobat 4 and later use a set of fonts that are *not* part of
Adobe's library but rather Agfa-Monotype's and closer in metrics to the
truetype fonts included in most MS Windows versions. Now you can imagine the
quality degradation after three passes of inaccurate guesswork. And I'll get
to the matter of font quality in Redhat 9's gs distro (which I use as well)
in a moment.

Second,

> 2. Using epstopdf (good output)
> ===============================
> OriginalFont    Type    Encoding  UsedFont                  Type
> ------------------------------------------------------------------
> Times-Bold      Type 1  Standard  Embedded Subset           Type 1
> address@hidden   Type 1  Built-in  Embedded Subset           Type 1
> address@hidden  Type 1  Built-in  Embedded Subset           Type 1
> address@hidden    Type 1  Built-in

Here, gs includes the outlines and the reader is forced into fitting the
outlines into the charboxes, things get better both on screen as in print,
though the metrics and the fonts are not quite the same... On the name
weirdness, this is something that showed up in gs 8.10 for me, with groff
1.18.1 and later (never did with 1.17.1 nor 1.18.0) and shows up as well
with JawsPDF 2.11.

>
> It would seem that it's indeed a font question. I'm just puzzled as
> to how this comes about. But anyway, epstopdf does the trick!

I hope the above dispells your puzzlement :-) Now there is the matter of the
fonts...

The fonts used by GS in RedHat 9 are horrid. Just look at the dismal
on-screen spacing of Nimbus Mono. The fonts supplied are not the original
URW++ fonts but rather fonts modified to add the glyphs to cover
Cyrillic/Russian and Greek character sets, using an earlier, very buggy
version of PfaEdit. The work is, well ..., amateurish. BTW, a later version
of these fonts, which metrics are not much better--- my opinion after being
forced to fix them to have them work under windows ---, are the new official
font distribution used by GS 8.20.

A solution... if you have some old ATM for Windows somewhere, the old
version that came with the LaserWriter 35 fonts, intall those into GS and
get rid of the hacked URW clones unless you need Greek or Cyrillic.