Bug 687391

Summary: assert src/gxccman.c:557 again
Product: Ghostscript Reporter: Russell Lang <gsview>
Component: Graphics LibraryAssignee: Igor Melichev <igor.melichev>
Status: NOTIFIED FIXED    
Severity: normal CC: dan.coby, ralph.giles, raph.levien
Priority: P2    
Version: master   
Hardware: PC   
OS: Windows XP   
Customer: Word Size: ---
Attachments: Lilypond example of the gxccman.c:557 assert
assert3-.ps

Description Russell Lang 2004-03-25 04:24:39 UTC 
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.
Comment 1 Russell Lang 2004-03-25 04:26:32 UTC 
Created attachment 594 [details]
Example file to trigger assert in gxccman.c
Comment 2 Russell Lang 2004-03-25 04:32:40 UTC 
gswin32c -sDEVICE=bmp16m -sOutputFile=out.bmp -dTextAlphaBits=4 assert3.ps
Comment 3 Ralph Giles 2004-03-25 14:48:46 UTC 
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.
Comment 4 Ralph Giles 2004-03-25 14:49:39 UTC 
Assigning to Igor as per discussion this morning with Raph and Ray.
Comment 5 Igor Melichev 2004-03-26 00:42:54 UTC 
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.
Comment 6 Igor Melichev 2004-03-30 09:01:11 UTC 
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.
Comment 7 Dan Coby 2004-03-31 22:17:14 UTC 
Igor,

In general, teh graphics library sets the color belore doing any drawing 
operation.  Whye is this not happening in this case?
Comment 8 Igor Melichev 2004-03-31 23:27:10 UTC 
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 ?