[Top][All Lists]

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

[bug #50989] Incorrect generation of typesetting.pdf

From: Deri James
Subject: [bug #50989] Incorrect generation of typesetting.pdf
Date: Wed, 2 Aug 2017 16:38:32 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #13, bug #50989 (project groff):

I have rewritten the font loading code, it seems to handle both old and new
ghostscript supplied fonts. However, before I commit the change I have
supplied a patch for testing, since it is significantly different from the old
version! I have also written a little script which can be used to test the
algorithm I am using without installing all your fonts into groff!

This won't be added to the groff git, it is just a tool to give some
confidence that the algorithm will work if the font was installed. It is
called CheckType1.pl and is used like this:-

CheckType1.pl /usr/share/ghostscript/9.20/Resource/Font/*|less


CheckType1.pl `locate \.pfa`|less

This will produce a report on each file similar to this:-

Segment 1 (ascii) =     898
Segment 2 (ascii) =     151141
Segment 3 (ascii) =     532
File=152571, Font=152571

Segment 1 (ascii) =     887
Segment 2 (ascii) =     144662
Segment 3 (ascii) =     532
File=146081, Font=146081

Segment 1 (ascii) =     896
Segment 2 (ascii) =     147446
Segment 3 (ascii) =     532
File=148874, Font=148874

Segment 1 (binary) =    3591
Segment 2 (binary) =    135386
Segment 3 (binary) =    533
File=139530, Font=139528

Segment 1 (ascii) =     4391
Segment 2 (ascii) =     38420
Segment 3 (ascii) =     532
File=43343, Font=43343

Segment 1 (ascii) =     898
Segment 2 (ascii) =     154493
Segment 3 (ascii) =     532
File=155923, Font=155923

A type 1 font has three segments which I have to identify as separate length
for the font to work in a pdf. So the report specifies the size and type of
each segment found. The type can be:-

ascii: for segment 2 this is actually raw bytes. The "File" and "Font" totals
should be the same, all the font has been recognised.

ascii hex : this is format where segment 2 rather than being raw bytes ls
coded as ascii text and I have to convert to raw bytes before embedding. In
this case the two sizes will be different since the size of segment 2 is about
half what it was because every two hex characters result in 1 raw byte. It is
not exactly half because there are also linefeeds in the ascii hex which get

binary : this a form where each segment is introduced by a six byte header
which specifies the length of the segment. The old ghostscript fonts were of
these type (normally called .pfb), now they are ascii, .pfa type. The
difference between the two sizes should always be two. The reason is because
these binary versions have a terminating two byte header which must be
dropped. Also the total of the individual segments will not equal the font
total because the font total takes into account the 3 six byte headers which I

Note that you may find some fonts which just have segment 1, these are not
full type 1 fonts, even if they are called ".pfa" they are likely to be
postscript programs which generate a font from another font, an example is the
font ZDR (Dingbats Reversed) which is available with grops. This is not
available for gropdf, but any glyph can be reversed by using X’pdf:xrev’
extension. The left hand dingbats glyph is pre-defined as:-

.char \[lh] \X'pdf: xrev'\[rh]\X'pdf: xrev'

Any testing you can do will be appreciated. I am not able to test on a windows
groff version, but I believe setting the filehandle to binary mode previously
solved a problem there, so this should be Ok.

(file #41395, file #41396)

Additional Item Attachment:

File name: bug-50989.patch                Size:4 KB
File name: CheckType1.pl                  Size:2 KB


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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