If you convert the attached file, the barcode gets written as a type3 font, which messed up most of the characters. The barcode uses setcharwidth, and the customer thinks that it shouldn't be converted into a PDF font (Distiller doesn't convert it). A proposed fix from the customer is: *** OLD/gdevpdtt.c Wed Mar 17 18:32:38 2004 --- gdevpdtt.c Thu Apr 29 02:21:13 2004 *************** *** 135,141 **** * a notdef glyph, but we don't know how to do with Type 3 fonts. */ } ! if (glyph != GS_NO_GLYPH && ch != GS_NO_CHAR) { gs_show_enum *penum_s; extern_st(st_gs_show_enum); gs_fixed_rect clip_box; --- 135,141 ---- * a notdef glyph, but we don't know how to do with Type 3 fonts. */ } ! if (glyph != GS_NO_GLYPH && ch != GS_NO_CHAR && control != +TEXT_SET_CHAR_WIDTH) { gs_show_enum *penum_s; extern_st(st_gs_show_enum); gs_fixed_rect clip_box;
Created attachment 677 [details] barcode.ps
The customer may use the suggested patch as a temporary workaround, but the assumption isn't good. I'll work on the problem.
PLRM3 reads : page 339 : In particular, BuildGlyph should not depend on any nonconstant information in VM, and it should not leave any side effects in VM or on stacks. Page 340 : The semantics of BuildChar are essentially the same as for BuildGlyph. In the supplied document a Type 3 font defines a BuildChar that generates images depending on a contex in the text. Thus the document doesn't comply to PLRM. If we don't convert any type 3 font with charwidth, other documents will convert to a longer PDF, what would be a regression. A smarter method is to recongize glyph variation dynamically.
Created attachment 683 [details] The unencoded barcode.ps
The next step should be to check whether the proposed patch writes the glyphs as bitmaps or outlines. If the former, we shouldn't apply it as-is, but perhaps a more sophisticated verison that detects whether there really is variability. If outlines (with this file and the others in our test base which use setcharwidth), then I think we should accept the patch. The PS spec is a little ambiguous whether the source file is valid (it's certainly dodgy), but the description in setcharwidth argues in favor.
The suggested change causes differences with out restbase, some of which are strong regressions with -r72 : 1. "238-01.ps" The font converts to outlines, rather there is no strong necessity. The searchability is lost. The generated PDF imbeds a Type 3 font, which is empty and isn't used. 2. "Bug687044.ps" The generated PDF, gets a wrong Widths, which causes a wrong glyph placement. (A strong regression). 3. "InstandardBuildChar.ps" Same as (1). 4. "muur.eps" Same as (1). The generated PDF becomes so long as 26K instead 3K - about 8 times longer. 5. "type3xshow.eps" Same as (1). The generated PDF becomes so long as 37K instead 24K. The resolution -r300 was not tested and may discover other problems. Due to that I do not recommend to use the patch as it is. At least it requires more work for (2).
I meant "with our restbase".
Patches http://www.ghostscript.com/pipermail/gs-cvs/2004-May/004506.html http://www.ghostscript.com/pipermail/gs-cvs/2004-May/004507.html implement a dynamic recognition of Type 3 glyph variations. Please note that rather these patches fix the problem, they open another bug 687487 "(pdfwrite) redundant ExtGState objects". That bug isn't critical, and we delay it for a while.
See also bug 688168 and a patch in there.