http://bugs.ghostscript.com/show_bug.cgi?id=691471
Ken Sharp <ken.sharp at artifex.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ken.sharp at artifex.com |michael.vrhel at artifex.com
--- Comment #6 from Ken Sharp <ken.sharp at artifex.com> 2010-07-19 16:18:55 UTC ---
Last comments from me, then re-assigning to Michael. I cut the file down to a
single glyph in the Pattern space and followed it through. I'll attach the
modified file here in a moment.
The first call to zshow sets the pattern space, which returns the e_Remap_Color
error in order to run the PaintProc. The interesting thing here is that in
gxpcmap.c, gx_pattern_load(), line 1113 is a comment :
if (pinst->template.uses_transparency) {
/* This should not occur from PS or PDF, but is provided for other
clients (XPS) */
if_debug0('v', "gx_pattern_load: pushing the pdf14 compositor device into
this graphics state\n");
if ((code = gs_push_pdf14trans_device(saved)) < 0)
return code;
The code path actually goes through that branch before returning e_Remap_color,
so either the comment is wrong or something else is. This apparently pushes
another copy of the pdf14 device, which may be related to the problem.
After running the PaintProc (and I hope rendering the tile via pdf14) the code
returns to zshow once more to draw the text. The glyph is correctly transformed
to a bitmap and stored in the cache, and then 'painted' which uses the pattern
ctile. This seems to always transfer 'white' bits, but its possible that its
actually being clipped out entirely.
I'm rather lost at this point, I would go back and see what's happening with
the PaintProc, but I suspect it'll be a lot quicker for Michael to look at this
since he understands the code.
--
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.