Summary: | Error in Lookup of a TTF-Font | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Dirk Maennel <maennel> |
Component: | General | Assignee: | Alex Cherepanov <alex> |
Status: | NOTIFIED FIXED | ||
Severity: | major | ||
Priority: | P1 | ||
Version: | 8.62 | ||
Hardware: | All | ||
OS: | Linux | ||
Customer: | 531 | Word Size: | --- |
Attachments: |
This is the PDF-File which use the font Code-128
This is the TTF-Font test.pdf Packed as zip experimental patch |
Description
Dirk Maennel
2008-03-11 03:55:43 UTC
Please attach the PDF file and the font file for testing. Created attachment 3854 [details]
This is the PDF-File which use the font Code-128
The conversion works fine under Windows XP with Ghostscript 8.61,
but it not works under Linux with ghoestscript 8.62 !
Created attachment 3855 [details]
This is the TTF-Font
When working fine you should see a Barcode on the document in upper right
corner. The file code_128.ttf is the font for displaying the barcode.
Because the wrong conversion under linux i will not see the barcode after
printing the converted ps-file.
I opened the file here with Acrobat 7 and immediately got a warning (disappeared too quick to see what). The bar code does not display, and the font 'Code-128' is listed in the fonts tab as using Adobe Sans MM. On exit Acrobat asks whether to save changes, so it looks like it repaired some damage to the file. Acrobat 5 gives the same results. Ghostscript 8.60 also does not display the bar code (I don't have a copy of 8.61 to hand) and gives a warning about an invalid XREF table. It substitutes a number of fonts, including Code-128 and gives a warning that a stream length is incorrect. The file seems to be damaged, possibly during upload here. If this is not the observed behaviour with the original file, please upload a new copy. You may like to zip the PDF file first, to reduce any problems with system translations. Or at least make it more obvious that there is some translation occurring. If the original file behaves the same way (especially with Acrobat), then I do not believe this is a GS bug. Ghostscript seems to me to be behaving as well as Adobe Acrobat in the face of a damaged file. This is definitely a regression in 8.62. I've attached a customer's PDF file 'cg.ttf' that uses the 'CenturyGothic' font. With 8.61, with the Windows 'GOTHIC.TTF' file in the directory specified by -sFONTPATH I see: %Resolving: [13 0] << /Subtype /TrueType /FontDescriptor 18 0 R /LastChar 255 /Widths [ --- snip --- ] /BaseFont /CenturyGothic /FirstChar 0 /Encoding /WinAnsiEncoding /Type /Font >> endobj %Resolving: [18 0] << /StemV 68 /FontName /CenturyGothic /FontStretch /Normal /FontWeight 400 /Flags 32 /Descent -307 /FontBBox [ -169 -307 1152 1060 ] /Ascent 1060 /FontFamily (Century Gothic) /CapHeight 718 /XHeight 531 /Type /FontDescriptor /ItalicAngle 0 >> endobj Scanning c:/windows/fonts for fonts... 273 files, 105 scanned, 94 new fonts. Loading CenturyGothic font from c:/windows/fonts/GOTHIC.TTF... 3366636 1900985 2998948 1638775 3 done. %Resolving: [18 0] %Resolving: [18 0] -0.12 Tc 0.6375 Tw 0 -1 1 0 1303.5 2380.5 Tm (WICKLIFFE, OHIO) Tj ============================================================================== With 8.62, it _does_ find the CenturyGothic font, but then does a substitution: %Resolving: [13 0] << /Subtype /TrueType /FontDescriptor 18 0 R /LastChar 255 /Widths [ --- snip --- ] /BaseFont /CenturyGothic /FirstChar 0 /Encoding /WinAnsiEncoding /Type /Font >> endobj %Resolving: [18 0] << /StemV 68 /FontName /CenturyGothic /FontStretch /Normal /FontWeight 400 /Flags 32 /Descent -307 /FontBBox [ -169 -307 1152 1060 ] /Ascent 1060 /FontFamily (Century Gothic) /CapHeight 718 /XHeight 531 /Type /FontDescriptor /ItalicAngle 0 >> endobj Scanning c:/windows/fonts for fonts... 273 files, 105 scanned, 94 new fonts. Loading CenturyGothic font from c:/windows/fonts/GOTHIC.TTF... 3344188 1870317 12140036 10835724 3 done. %Resolving: [18 0] Substituting font NewCenturySchlbk-Roman for CenturyGothic. Loading CenturySchL-Roma font from /fonts/c059013l.pfb... 3404476 1939258 12140036 10836634 3 done. %Resolving: [18 0] %Resolving: [18 0] -0.12 Tc 0.6375 Tw 0 -1 1 0 1303.5 2380.5 Tm (WICKLIFFE, OHIO) Tj ============================================================================== This is clearly incorrect, and a regression from the correct behavior of 8.61 Assigning to Alex, and bumping the priority to reflect that this is a customer bug. Created attachment 3856 [details]
CG.pdf
Customer's file that shows the problem
This regression was introduced in r8509, which fixed bug 689637. The change made by the rev. 8509 accepts only resource fonts. Unfortunately, the fonts found in the search path are not considered to be resource fonts. The semantics of the resource font flag cannot be changed because it is used in other parts of the code. Even if we accept fonts found in the search path, we will still ignore the fonts defined in VM prior to running the PDF file. For now, we need another flag to mark embedded PDF fonts and ignore them during resource look-up. The font dictionary itself seems to be a good place for the new flag. A better solution would avoid registering embedded PDF fonts as resources and access them only by the reference. Created attachment 3857 [details]
test.pdf Packed as zip
I have uploaded the PDF again (packed as zip-File). I know that there is a
error contained in the in the document (but we cannot fix it, because the
document is created by a 3rd party system).
Nevertheless the conversion to postscript format works right (with the barcode
font) using Ghostscript 8.61 both under Linux and Windows.
So it seems to be a special problem of version 8.62 .
Is there any chance to get it to work with version 8.62 or do we have to use the version 8.61 furthermore ? Created attachment 3876 [details] experimental patch This patch implements the proposed approach - mark the embedded fonts. However, the patch breaks Bug689644.pdf from our test file collection. I'm looking into the problem now. This problem is now fixed. The relevant revisions are 8772, 8774, 8775. http://ghostscript.com/pipermail/gs-cvs/2008-May/008350.html http://ghostscript.com/pipermail/gs-cvs/2008-May/008352.html http://ghostscript.com/pipermail/gs-cvs/2008-May/008353.html |