There is a difference in character rendering with the font cache enable and disabled: bin/gs -sDEVICE=ppmraw -o '|md5sum' -r300 ./test.ps bin/gs -sDEVICE=ppmraw -o '|md5sum' -r300-dNOCACHE ./test.ps This is with gshead (r9466).
Created attachment 4783 [details] test.ps
Interesting. I can reproduce (actually, I used a similar file with Times-Roman instead of Helvetica) on my MacBook Pro (x86_32, 1 GB ram, MacOS 10.4.11) but not on my desktop (x86_64, 3.2 GB ram, Ubuntu Linux 8.04.2).
For me it fails on my MacBook Pro and my Ubuntu 7.10 x86_64 box (btw, has this become the de-facto standard Artifex developer configuration? a MacBook Pro and an x86_64 desktop machine running Ubuntu?).
-ZP shows the outlines are rendered in different coordinate systems, so I don't know this is worth messing with.
Marcos: somewhat common, at least. But I hope my next macbook is also x86_64. :)
A related issue: Bug 690232 was resolved by making the font cache deterministic, but this shouldn't have affected the output. A glyph that was removed because the cache was full should just have been re-rendered with the same bitmap, having a minor effect on performance but not the output bitmap. This difference can be demonstrated with gshead (r9466 or later) and 13-03_mhw.PS (attached) with the following command line: bin/gs -r600 -sDEVICE=tiff24nc -o test.tif ./13-03_mhw.PS Changing the initial pdir->hash value in gsfont.c from 42 to 19 will result in bitmap differences on pages 2, 3, and 4. Note that not all values results in a bitmap change; only about 20% of the possible values of pdir->hash do (for example, 95, 44, 18, 96, 70, 31, 90, and 55 all produce bitmaps identical to 42).
Created attachment 4787 [details] 13-03_mhw.PS
Further data: if you change -r300 in the command line in comment #0 to -r400 or -r100 there is no difference with and without -dNOCACHE
Close based on comment #6.
reopening for further study.
see 690841 for possible solution.
I did check this with the odd clipping behaviour in gxchar.c, which only affects type 3 fonts. 13-03_mhw.ps does trigger this check (test.ps doesn't, its a type 1 font). However, I don't see any evidence of the glyphs being improperly clipped by this. All the differences I see are similar instances to the 'problem' in test.ps, it appears that we are rendering curves slightly differently in the cached and uncached cases. The differences are small, I think its likely that this is just due to the way that the cached bitmap interacts with the device grid, as opposed to the way a curve drawn at the device resolution does, given the exact placement of the curve. Marcos' comment #6 leads me even more to believe this is the case. This isn't a reason not to remove the clipping in set_cache_device(), but its not a reason to remove it either. Closing this one again.
You'd think I'd know better by now not to guess... We do want it open until we have detailed analysis of the rendering differences. I'll put it back on my list now I'm more curious.