| Summary: | Mis-rendering 'adiaeresis' (German umlaut 'ä') with font 'Franklin Gothic Medium Cond' | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | pipitas |
| Component: | Font API | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 8.71 | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: | 2-page PDF demonstrating the problem -- 1st page: original content with adiaeresis; 2nd page: TIFF by Ghostscript attached to original file | ||
Created attachment 6142 [details]
2-page PDF demonstrating the problem -- 1st page: original content with adiaeresis; 2nd page: TIFF by Ghostscript attached to original file
2-page PDF demonstrating the problem:
-- 1st page: original content with adiaeresis;
-- 2nd page: TIFF by Ghostscript attached to original file
Fixed in revision 11043. The font is invalid, it attempts to use a DeltaP instruction greater than the number of points in the glyph. The FreeType interpreter says this:
/* XXX: Because some popular fonts contain some invalid DeltaP */
/* instructions, we simply ignore them when the stacked */
/* point reference is off limit, rather than returning an */
/* error. As a delta instruction doesn't change a glyph */
/* in great ways, this shouldn't be a problem. */
So we essentially mimic the same behaviour here.
(In reply to comment #2) > Fixed in revision 11043. The font is invalid, it attempts to use a DeltaP > instruction greater than the number of points in the glyph. The FreeType > interpreter says this: > > /* XXX: Because some popular fonts contain some invalid DeltaP */ > /* instructions, we simply ignore them when the stacked */ > /* point reference is off limit, rather than returning an */ > /* error. As a delta instruction doesn't change a glyph */ > /* in great ways, this shouldn't be a problem. */ > > So we essentially mimic the same behaviour here. Thanks, Ken. I can confirm that the current trunk/head version of Ghostscript (r10980) does not show the problem any more. I compiled today on Win32 (with MSVSC++2008EE). For me the only unsolved secret that remains is why I did not succeed to trace any hint of that mysterious "DeltaP instruction" problem with any of the tools that were available to me at the time (which included Acrobat Professional 9 with its "browse document fonts feature" as well as the "callas pdfToolbox4" software). Thanks again, Ken, for fixing this so fast. Cheers, Kurt (In reply to comment #3) > (In reply to comment #2) > > Fixed in revision 11043. The font is invalid, it attempts to use a DeltaP > > instruction greater than the number of points in the glyph. The FreeType > > interpreter says this: > > > > /* XXX: Because some popular fonts contain some invalid DeltaP */ > > /* instructions, we simply ignore them when the stacked */ > > /* point reference is off limit, rather than returning an */ > > /* error. As a delta instruction doesn't change a glyph */ > > /* in great ways, this shouldn't be a problem. */ > > > > So we essentially mimic the same behaviour here. > > > Thanks, Ken. > > I can confirm that the current trunk/head version of Ghostscript (r10980) does > not show the problem any more. I compiled today on Win32 (with MSVSC++2008EE). > > For me the only unsolved secret that remains is why I did not succeed to trace > any hint of that mysterious "DeltaP instruction" problem with any of the tools > that were available to me at the time (which included Acrobat Professional 9 > with its "browse document fonts feature" as well as the "callas pdfToolbox4" > software). > > Thanks again, Ken, for fixing this so fast. > > Cheers, > Kurt Hmmm... I only now notice that you referenced r11043, while today's local checkout gave me r10980 dated "2010-03-29 09:52:49" (with repository root http://ghostscript.googlecode.com/svn). The reason why this may have worked for me is that this one seems to have given me the FreeType font renderer (which as you say, works around that problem). I'll see if I can svn co the r11043 you referred to (or later) from the svn.ghostscript.com repository and test it again. In any case, it's great that it's fixed both ways. (In reply to comment #4) > Hmmm... I only now notice that you referenced r11043, while today's local > checkout gave me r10980 dated "2010-03-29 09:52:49" (with repository root > http://ghostscript.googlecode.com/svn). That's a strange URL, and the revision number is too early to get either fix. You should pick up the source from http://svn.ghostscript.com or from the SourceForge repository. You need to get at least revision 11043. > The reason why this may have worked for me is that this one seems to have given > me the FreeType font renderer (which as you say, works around that problem). I doubt if your revision is using FreeType. We have been supplying FreeType as part of the source for some time, but not building it by default, you need to take action at build-time to do that. Having said that, since revision 11071 Ghostscript now builds and uses FreeType for font rendering as the default, and you need to take action f you *don't* want that. |
Summary: Ghostscript mis-renders glyph 'adiaeresis' (German umlaut 'ä') when using font 'Franklin Gothic Medium Cond'. How to reproduce: 1. The font in question ships f.e. with MS Office 2007; MS applications display its name as 'Franklin Gothic Medium Cond'. 2. More details about the font to use: a) filename: 'FRAMDCN.TTF', b) filesize: 132.516 Bytes, c) filedate: May 05, 1999, d) fileversion: 2.00, e) font foundry: ITC. 2. Create an Office 2007 document using glyph 'adiaeresis' (Unicode U+00e4) with this font. 3. Convert the document (*.xlsx or *.docx) to PDF. Pick any method you like: a) "Save as..." (select "PDF" to use Adobe PDFWriter, if installed) b) "Save as..." (select "PDF or XPS" to use the native PDF export function of Office 2007) c) "Print... (select "Adobe PDF" to use Distiller, if installed) 4. Use Ghostscript to render the PDF to TIFF pages (f.e. "-sDEVICE=tiffg4"). 5. See how your 'adiaeresis' was rendered as 'a'. 6. Notice, that Ghostscript issues a warning to stderr about "Failed to interpret TT instructions for glyph index 108" More details: 1. I tested with two different Ghostscript versions: - 8.62 on Solaris SPARC - 8.71 on Windows i86 and both these show the problem. 2. I ran Microsofts "fontval.exe" tool against the FRAMDCN.TTF file (without understanding too well how to use it, or how to interprete its results... so please bear with me.) fontval.exe did not indicate any problems for glyph index 108. (It DOES however raise an "error 'E1110 Misoriented contour' on glyph index 491". That glyph is for small cyrillic character 'Ya' (Unicode U+044f). But Ghostscript doesn't give any warning about glyph index 491 when 'Ya' is used in a document, and Ghostscript does render the 'Ya' OK, as far as I can see...) 3. The Ghostscript mis-rendering of 'adiaeresis' does NOT appear with any other font from the 'Franklin Gothic' family (here are also available: '*-Heavy', '*-Demi', '*-Book', '*-Demi Cond' and '*-Medium').). 4. It also does not appear for any other (diaeresis-ed) glyph contained in the 'Franklin Gothic Medium Cond' (I tested all German umlauts, as well as all international Diaeresis using characters I could find via "charmap.exe"). 5. I'll attach 2 sample PDF documents showing this problem (and also giving more details about my findings).