Several files fail with "/unregistered in --run--", 3 elements on the stack, a small number on top of the op stack, and %op_show_continue on top of execution stack. fts_17_1705_a4.pdf fts_23_2300_a4.pdf fts_23_2301_a4.pdf fts_23_2302_a4.pdf fts_23_2304_a4.pdf
Updated to reflect customer status and ID
(In reply to comment #0) > Several files fail with "/unregistered in --run--", 3 elements on the stack, > a small number on top of the op stack, and %op_show_continue on top of > execution stack. > > fts_17_1705_a4.pdf > fts_23_2300_a4.pdf > fts_23_2301_a4.pdf > fts_23_2302_a4.pdf > fts_23_2304_a4.pdf For me four of these files give an error 'unregistered in --show--', while the fifth, fts_23_2300.pdf runs to completion though there are missing elements in the output. This is on Windows, not Linux though.
The problem with fts_23_2301.pdf and probably the other files is due to using a Pattern colour space to fill the text. All the files contain examples of this, including fts_23_2300 which, even though it complete, is missing the text drawn in a Pattern colour space. I believe all the relevant text uses a Pattern containing an image, possibly the same image In fact, this file uses an image with an SMask, if I remove the SMask from the image, then the file will work. Looks like this is another transparency issue....
fts_17_1705.pdf also has a Pattern containing a large image with a large SMask, removing the SMask again runs to completion. The missing (non-Wingdings) text in fts_23_2300.pdf is again in a Pattern colour space with a large image containing an SMask. Again removing the SMask results in correct output. Same with fts_23_2302, Pattern colour space with large image and SMask, removing the SMask removes the problem. Finally, fts_23_2304 is the same again, removing the SMask removes the error.
All these files work correctly when using the pdfwrite device. So the problem is not in the PDF or PostScript interpreter, nor is it something missing in the compositor pass-through to pdfwrite. So I believe it must be something to do with the transparency compositor itself.
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.
Very strange. With this example file there are three pdev14 device pushes that occur and not a single put image.
OK. I have made a bit of progress on this but I am looking for some suggestions. In the pattern transparency cases that we have had up until now, they have always been fills of paths. We create the pattern trans buffer and then we end up doing a fill path for the pdf14 device which does the following: pdf14_fill_path -> pdf14_tile_pattern_fill This pushes a group to do the tiling It then does tile_rect_trans_blend or tile_rect_trans_simple depending upon if the tiling is simple or overlapping. The group is then popped, and so composed with whatever was already in the trans buffer. What is new is that we are now doing a glyph fill with a pattern that has a transparency. We create the trans buffer object of the pattern just fine. But we are no longer going through pdf14_fill_path. Instead we take the following steps: gs_text_process -> gx_show_text_process -> continue_show_update -> show_update -> gx_image_cached_char -> gs_image_next -> gs_image_next_planes -> gx_image_plane_data_rows -> gx_image1_plane_data -> image_render_simple -> copy_portrait -> gx_dc_default_fill_masked -> gx_dc_pattern_fill_rectangle which has no idea about transparency and ends up trying to use the tbits entry of the tile which is null. Clearly there needs to be some pdf14 device method that is invoked here, so that a new group is pushed and the result is composed with what ever is already drawn and the trans entry of the tile is used during the tiling process. Not being familiar with the font rendering I am looking for a bit of advice here on how the pdf14 device intercepts in the above set of operations or if we could do a path fill for the glyph.
(In reply to comment #9) > OK. I have made a bit of progress on this but I am looking for some > suggestions. Remember, you asked for it :-) > Clearly there needs to be some pdf14 device method > that is invoked here, so that a new group is pushed and the result is composed > with what ever is already drawn and the trans entry of the tile is used during > the tiling process. Shouldn't the compositor image method be executed ? > Not being familiar with the font rendering I am looking > for a bit of advice here on how the pdf14 device intercepts in the above set of > operations or if we could do a path fill for the glyph. Well, there isn't really a device method for pdf14 to intercept, other than the image method, because we are at a lower level than that. We've already created a bitmap of the glyph from the glyph program, and we use that as a mask to draw through. I *think* the way this usually works for patterns is that the pattern tile has already been rendered (tbits) and we just use the glyph bitmap as a mask for the pattern tile, tiling as required if the glyph lies across a tile boundary. In order to make a path fill we would have to realise during the show that we are filling with a pattern. We would also want to recognise somehow that the pattern involves transparency. We do already have a test for that in the pattern loading code. On return from the Pattern PaintProc, passing through show for the second time, we would need to execute a charpath/fill instead of a simple show. I'm sure that's possible but it just feels like the wrong approach, also I'm not sure how this would translate into high level output. I strongly suspect that the text would be converted to a path. This has multiple problems; it would be impossible to edit the text in Acrobat afterwards. If the font is not embedded then the result might be permanently incorrect (we would convert to charpath with the wrong font) and finally, the file would be potentially considerably larger.
Considering the problem a little further. The sequence performed by show is essentially an imagemask painted with a Pattern colour space, does this work under the current scheme ? It needs to work when the Pattern contains transparency, if that works, why doesn't it work when the source of the imagemask is a glyph ?
Created attachment 6515 [details] Sample file to exhibit problem OK, after some effort.... The attached PDF file paints an imagemask (the well known turkey) using a Pattern colour space. The Pattern paints a very simple RGB image, and applies a softmask image in the process. This does not appear to render correctly (the output is all white in GS), but you can view it OK in Acrobat 9. This is a generalisation of the case when we are painting a glyph bitmap using a Pattern space. However in this case there is no reasonable way to convert the imagemask into a path. I think the pdf14 code needs to be much smarter in pdf_begin_typed_image, it can't simply punt it off to the graphics library. (But I could be wrong about that).
I am making progress on this. I have the pdf14 begin type image detecting the pattern with transparency when filling a mask. It pushes a group, sets up a few things with the pattern so that the transparency related filling will occur and it also overrides the renderer with a renderer that basically will wait for the final row of data and pop the group and do a bit more housekeeping. Having a few issues with the group size but I hope to be finished up soon.
Created attachment 6664 [details] bug691471_patch This patch works for the non clist case. Working more to make the clist case work. Note that this patch is also relevant to 691550
Created attachment 6669 [details] New Patch This new patch fixes a few issues with the previous patch. C-list case still does not work however. That will be handled hopefully in the next patch..
I think that the file fts_23_2303.pdf also trips up. A pattern that has transparency is being used in a call to gx_image_fill_masked and in the clist case the 'ptile' in gx_dc_pattern_fill_rectangle has tbits==NULL and tmask==NULL, but ttrans is a valid structure. Since tbits is NULL, we crash in strip_tile_rectangle.
Created attachment 6675 [details] Newer Patch This patch will handle the fts_23_2303 case. I am still working on the case of clist with begin type image where the image is a mask and we are filling with a pattern that has transparency. All other cases seem to be OK with this patch. I hope to have this resolved soon.
Customer issues were resolved. Updating priority on this one and removing customer
This was resolved at some point. Ken's second sample file (the hard one that was an imagemask using a pattern color space where the pattern paints a very simple RGB image, and applies a softmask image in the process) renders just fine through the clist and in immediate mode.