GS 8.14 and HEAD will fail with the attached file src/gxccman.c:557: gx_add_cached_char: Assertion `cc->pair == pair' failed. I got this on Windows with 8.14 and Linux with HEAD. This is the same assert as bug 687209/687241. Found by Roderic A. Girle.
Created attachment 594 [details] Example file to trigger assert in gxccman.c
gswin32c -sDEVICE=bmp16m -sOutputFile=out.bmp -dTextAlphaBits=4 assert3.ps
Created attachment 595 [details] Lilypond example of the gxccman.c:557 assert Attaching lilypond file from Werner Lemberg which also triggers the assert, as reported to gs-devel.
Assigning to Igor as per discussion this morning with Raph and Ray.
Created attachment 596 [details] assert3-.ps Attaching a reduced test. The bottom of the problem is that the current color is unset while executing setchachedevice from a Type 3 charproc. Due to that gx_compute_text_oversampling ln 364 asumes a non-pure color, and choose an oversampling different than an advance assumption. We realize that the logics of penum->log2_scale is a kind of unsmooth and to be improved. But this would not fix this problem, which is caused by the color unsetting when entered the charproc.
In the sample document, BuildChar executes "0 setgray" and some later executes "setcachedevice", but there is no painting between these events. Therefore the current color is "none" from gs_setcolor, due to the lazy remapping to device color did not happen. IMO it's a conflict of our lazy color remapping with our implementation of text antialiasing with an oversampling. I'm not clear how to fix it, Dan's help wanted. Besides that, I'm unclear why gs_setcolor returns "undefined" when executing after setcachedevice : likely the order of 'setcolor' and 'setcachedevice' is arbitrary, and PLRM doesn't restrict it. Note it stays so since the repository was created.
Igor, In general, teh graphics library sets the color belore doing any drawing operation. Whye is this not happening in this case?
Because there is no drawing operations after setcolor before setcachedevice, and setcachedevice checks whether the current color is pure. Meanwhile now I think that I can fix it, because setcachedevice must not depend on BuildChar colors. Therefore it must check the color before entering BuildChar, and store the 'pure color' fact somewhere in gs_show_enum. Actually there may be more problems specific to Type 3 fonts, and I work on them now. Another question is still open : why gs_setcolor returns "undefined" when executing after setcachedevice ?
Patch http://www.ghostscript.com/pipermail/gs-cvs/2004-April/004378.html