Bug 695253

Summary: Question about managing patterns and spot colors
Product: Ghostscript Reporter: Marcos H. Woehrmann <marcos.woehrmann>
Component: GeneralAssignee: Ken Sharp <ken.sharp>
Status: NOTIFIED FIXED    
Severity: enhancement    
Priority: P2    
Version: master   
Hardware: PC   
OS: All   
Customer: 885 Word Size: ---

Description Marcos H. Woehrmann 2014-05-21 21:23:06 UTC 
The customer asks:

I’d need a kind of notification – best using a driver procedure – when a type 1 pattern accumulation begins and ends respectively. As I understand the pattern_manage_xxx device procedure is now deprecated.
I’ve thought about using the device specific operations’ implementation for this purpose by returning 1 for gxdso_pattern_can_accum and setting/resetting a flag when calling back gxdso_pattern_start_accum and gxdso_pattern_finish_accum respectively. But – at least as I can see – there is no way to “defaulting” these tasks back to GS if my driver cannot do the accumulation itself (as it would for an “ordinary” device procedure). And – at least for now – I don’t intend to implement this laborious task so I have to rely on the existing (clist accumulation) implementation.
 
My question is whether there is a solution to know inside the driver when a pattern accumulation begins and ends.
 
Let me show why do I need this.
 
As I wrote in a previous mail my driver is able to handle up to 28 spot colors (32 colors per total) but for performance reasons I my device’s color_info.num_components filed is initialized by 4 and it’s incremented just in time, when a new spot color is “arrived”. This approach works excellent for all the cases but when a new spot color is registered inside a pattern accumulation. So I keep thinking about a hack: I increase the color_info.num_components field to the fake value of 32 color components before the pattern accumulation and set it back to the saved value after finishing.
Comment 1 Ken Sharp 2015-06-16 09:36:42 UTC 
Although this bug thread has been idle some time, we have actually made some progress. The problem is actually very tricky to solve, we could supply a solution which only modifies the graphics libraries and interpreters slightly, but there is a new feature in Ghostscript nearing completion which I would like to use instead.

I've put together some example code using it, and presuming that the new code gets approval from the development team I'll supply that to the customer when I integrate it. If the new code gets the thumbs-down then I'll work out a different approach and supply that as example code.
Comment 2 Ken Sharp 2015-07-11 02:40:23 UTC 
Commit http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=f98b0b84a7f7c1833550ee3938f60aef356840c3

Adds device_subclassing, commit http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=aa48df9c6d4af5e611e8b641d8c544885f59b2ac

adds some interpreter changes required to make the example code work.

Example code supplied to customer by email.