Created attachment 6709 [details] screenshot.png As the attached screen shot shows there is a reduction in the quality of text for some files starting with r11690. The current head (r11708) shows a slight difference in, but no apparent improvement. The command line I'm using: bin/gs -sDEVICE=tiff24nc -r300 -o test.tif ./Bug689820.pdf Another obvious difference in quality is with Bug691227.pdf, this time at 72 dpi.
Marking as a blocker until we understand it better. Marcos mentioned during the support call that this affects several hundred files, and it looks pretty bad.
I re-examined the nightly regression files and while I was correct that this issue affected hundreds of files it's only a clear regression in the two files I mentioned in Comment #0 and in no_cmap.pdf. In the other files it's either just a change in the glyph shapes or a bolding of text.
(In reply to comment #2) > I re-examined the nightly regression files and while I was correct that this > issue affected hundreds of files it's only a clear regression in the two files > I mentioned in Comment #0 and in no_cmap.pdf. In the other files it's either > just a change in the glyph shapes or a bolding of text. I'm relieved about that - I couldn't understand how I could have missed hundreds of problems of the magnitude illustrated by the attached example! The problem with the glyph shapes is due to a problem (I think it's a bug) in Freetype. If we ask Freetype to only create an outline, but not create a bitmap, it seems to skip some or all of the hinting (both the hinting from the font, and the "auto-hinting" features). I had split the outline and bitmap creation so that we could get the outline, assess the size of the scaled glyph, and decide whether or not to produce a bitmap from the outline - but that results in an unhinted outline, and we get poor results for glyphs where we did produce bitmaps (which is the vast majority). I discussed with Ray using the FontBBox instead of the outline bounding box, but as it turns out this won't work without significant changes, because in the case of glyphs like "-", where the glyph bounding box is small, zchar_set_cache() will use that to decide whether the glyph should be cached or not, whilst FAPI would use the FontBBox. So if the rest of the "show" context is expecting a cached bitmap, and FAPI provides an outline, we end up with an empty glyph in the cache, so repeated use of the same glyph renders blank. I've opted to have Freetype attempt to create the bitmap, and if it fails, or if the resulting bitmap is too large, then dispose of the bitmap and try again with an outline - a "too large" bitmap is 1.5 * the maximum cache bitmap (that ensures we avoid edge cases where rounding differences could result in FAPI wanting to produce an outline, and the "show" context still expecting a bitmap to cache). In the long term we'll need a "proper" retry route where we can dismantle all the cache device preparations, and attempt to render the glyph again without the cache device getting in the way. Unfortunately naively using the existing retry capability for Type 1 fonts results in nocurrentpoint errors, so that would need more investigation to get working. Excessive boldness for outline glyphs Ray suggested might be down to fill adjustment, which should be zero for glyphs - indeed FAPI wasn't setting it, so it was inheriting the value from the original graphics state, which is inappropriate for glyphs. Setting it to zero produces outline glyphs much closer in weight to the original GS font code.
Created attachment 6713 [details] output produced with revision 11713
I hope(!!) this is resolved with revision 11713.