[bug #50989] Incorrect generation of typesetting.pdf

[Deri James]

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


or


CheckType1.pl `locate \.pfa`|less


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


/usr/share/ghostscript/9.20/Resource/Font/C059-BdIta
Segment 1 (ascii) =     898
Segment 2 (ascii) =     151141
Segment 3 (ascii) =     532
File=152571, Font=152571

/usr/share/ghostscript/9.20/Resource/Font/C059-Bold
Segment 1 (ascii) =     887
Segment 2 (ascii) =     144662
Segment 3 (ascii) =     532
File=146081, Font=146081

/usr/share/ghostscript/9.20/Resource/Font/C059-Italic
Segment 1 (ascii) =     896
Segment 2 (ascii) =     147446
Segment 3 (ascii) =     532
File=148874, Font=148874

/usr/share/ghostscript/9.20/Resource/Font/C059-Roman
Segment 1 (binary) =    3591
Segment 2 (binary) =    135386
Segment 3 (binary) =    533
File=139530, Font=139528

/usr/share/ghostscript/9.20/Resource/Font/D050000L
Segment 1 (ascii) =     4391
Segment 2 (ascii) =     38420
Segment 3 (ascii) =     532
File=43343, Font=43343

/usr/share/ghostscript/9.20/Resource/Font/NimbusMonoPS-Bold
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
dropped.

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
remove.

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:

  <http://savannah.gnu.org/bugs/?50989>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/