As mentioned in the commit message for r11914 several of the PDF FTS files exhibit regressions when processed with pdfwrite. I've listed the ones that showed up in the nightly regressions here: tests_private__pdf__PDF_1.7_FTS__fts_06_0608.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_06_0608.pdf.pdf.ppmraw.300.0.page_3.raw tests_private__pdf__PDF_1.7_FTS__fts_09_0919.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_12_1202.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_12_1205.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_14_1416.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1508.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1510.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1512.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1514.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1516.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1518.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_15_1520.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_25_2501.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_26_2601.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_26_2602.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_28_2803.pdf.pdf.ppmraw.300.0.page_1.raw tests_private__pdf__PDF_1.7_FTS__fts_28_2803.pdf.pdf.ppmraw.300.0.page_2.raw tests_private__pdf__PDF_1.7_FTS__fts_31_3107.pdf.pdf.ppmraw.300.0.page_2.raw
OK Thanks. I will dig into these this week.
I have verified that it is this extra isolated knockout transparency group that is getting pushed so that we can handle the blend in gs correctly. An easy fix (but one that I dislike a bit -- but there is precedence for this) is to NOT to do the push if we are going to a high level device. Alternatively, I will need to detect in the pdfwrite device, through a flag or something the presence of the unneeded transparency group push and pop and make sure to filter them out.
I believe at this point it's traditional for me to suggest gxdso_is_high_level_device or gxdso_device_does_own_blending or something similar :)
(In reply to comment #3) > I believe at this point it's traditional for me to suggest > gxdso_is_high_level_device or gxdso_device_does_own_blending or something > similar :) If I understand it correctly, I think you want to interrogate the device parameters, just like we do for pdfwrite and other devices. See the HighLevelDevice parameter (amongst others). These can be tested in C and in PostScript, which makes them flexible and gets away from overloading pattern_manage or adding more device methods.
Ken has identified this as a pdfwrite issue and is taking over.
(In reply to comment #5) > Ken has identified this as a pdfwrite issue and is taking over. This is to do with using the CTM of the enclosing stream, rather than the current CTM (a crazy part of the spec). I can fix this file easily, and it produces a number of progressions in the test suite. Sdly it also introduces a number of regressions as well. I suspect this is something to do with the nesting level (in forms). I think I will need to do something more sophisticated about maintaining a stack of CTMs when processing forms. This will need significant amounts of investigation and testing.
I believe this to be fixed in commit: ebc42b7b7b27977bac17a9f5a9f0626bcfdf8a16 Patch is here: http://ghostscript.com/pipermail/gs-cvs/2011-August/013318.html