When the attached PDF file is converted to TIFF G4 at some resolutions (i.e. 300 dpi) the letter 'I' is missing; at higher resolutions (i.e. 600 dpi) it's rendered correctly. I initially thought this happens because the letter 'I' is a very thin line, but other lines that are the same width (i.e. those in the letter 'E') do not disappear, so it's probably some other issue. I did try various combinations of tiffscaled, DownScaleFactor, MinFeatureSize, and BitsPerComponent but cannot produce reasonable monochrome output. The command line I'm using for testing: bin/gs -sDEVICE=tiffg4 -o test.tif -r600 243-2223-AD-HV-C200_c.pdf Both Adobe Acrobat 11.0.10 and muPDF render the 'I' even at low resolutions.
Created attachment 11403 [details] 243-2223-AD-HV-C200_c.pdf Very cut down version of customer supplied file.
As a matter of fact, mupdf only renders the 'I' because of anti-aliasing, if you disable anti-aliasing, mupdf also drops the 'I' at 300dpi. Similarly, if you configure Ghostscript to render text with anti-aliasing, the 'I' is visible (in both cases, due to the aa, the glyph is rendered grey). My guess is that it is related to Freetype's drop-out detection/compensation, which is not good news....
muPDF renders the I even with the following command line (which disables antialiasing and outputs monochrome): mudraw -c mono -b 0 -o test.pbm ./243-2223-AD-HV-C200_c.pdf
Though you are correct, at 300 dpi the 'I' is missing with mupdf (In reply to Marcos H. Woehrmann from comment #3) > muPDF renders the I even with the following command line (which disables > antialiasing and outputs monochrome): > > mudraw -c mono -b 0 -o test.pbm ./243-2223-AD-HV-C200_c.pdf Actually you are correct, at 300 dpi the 'I' is missing. I had assumed that if it appeared at 72 dpi, it would appear at 300 dpi as well, apparently it's more complicated that than.
(In reply to Marcos H. Woehrmann from comment #4) > Though you are correct, at 300 dpi the 'I' is missing with mupdf (In reply > to Marcos H. Woehrmann from comment #3) > > muPDF renders the I even with the following command line (which disables > > antialiasing and outputs monochrome): > > > > mudraw -c mono -b 0 -o test.pbm ./243-2223-AD-HV-C200_c.pdf > > Actually you are correct, at 300 dpi the 'I' is missing. I had assumed that > if it appeared at 72 dpi, it would appear at 300 dpi as well, apparently > it's more complicated that than. That is, umm, odd. I can see (in GS at least) Freetype rounds the x dimension of the bounding box of the glyph to zero at lower resolutions. I'm not sure how mupdf would avoid that......
The problem is actually because the stem in the 'I' glyph ends up being less than half a pixel wide, thus when Freetype calculates the bounding box of the path, it ends up with a width of zero, thus no raster is allocated, and no rendering takes place. OTOH, the 'E' glyph, for example, has a similarly narrow feature (it's vertical stem), but also has the horizontal features ensuring the bbox has both height and width. The drop-out compensation in the Freetype's scan conversion then ensures that the feature actually gets drawn, despite it being extremely narrow. If we ensure that even glyphs consisting of only sub-half-pixel features get a raster allocated, then the drop-out compensation will get a proper chance to do its work. I've given these findings to the Freetype developers, and I'd like to get feedback from them before proceeding further.
Fixed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2cc3a17 As mentioned in the commit message, the same patch has been applied in the Freetype upstream repo, so will be in the next Freetype release.