Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CUPS filter: binary data before %%EndSetup ?

Regarding:
On Mar 24, 2004, at 11:03 AM, Marc Stibane wrote:

In my PDE I put several key/value pairs in the jobticket, which my CUPS filter then should inject into the PostScript stream.
My first attempt was to read lines from stdin with fgets (and write them to stdout with fputs) until I find a line which starts with "%%EndComments", Here I would inject some PostScript code, write the line itself, then search for "%%EndSetup", inject even more, and afterwards just copy the rest of stdin to stdout.

However, there are Macintosh applications which generate their own PostScript when printing and use 0x0D as newline, not 0x0A which fgets expects. Also fgets cannot deal with binary data since it stops when it reads 0x00. So I changed my code to use fread and fwrite instead.

There is no doubt you need to be prepared to handle binary data in the PostScript stream.

But I am afraid there might be binary data (e.g. some 15MB japanese font) in the PostScript stream before "%%EndSetup", which by chance could contain the bytes 0x2525456E645365747570 (aka %%EndSetup) - in which case I would inject my PostScript code at the wrong place.

If you need to parse for arbitrary DSC comments such as %%EndSetup you should always be parsing for the sequence:

<newline>%%EndSetup<newline>

where <newline> can be <cr>, <lf> or <crlf>

Since DSC comments always appear after a newline (or with the %!PS-Adobe-xx which is the first sequence in the file), this is a better approach.

Is this possible at all (binary data before %%EndSetup)?

Yes it is possible.

If yes, since ANY filter should have this problem, does every developer have to write his own full fledged PostScript parser to find the correct injection points or are there any OS routines / library calls which do this?

The pstops filter available as part of the cups open source distribution has a general DSC parser. There is no API in cups which performs this function.

If you need to make a feature or features available for your printer that require collecting data from the user beyond hard coded features that can be well described by the standard PPD syntax you can have your PPD describe a feature that causes invocation code to be added to the print stream that you can parse for in your filter. For example, add a PPD entry something like:

*OpenUI *AP_FeatureName/My Feature Name: PickOne
*OrderDependency: 20 DocumentSetup *AP_FeatureName
*DefaultAP_FeatureName: SomeName
*AP_FeatureName SomeName/SomeName: "%AP_FeatureName_InvocationCode"
*End
*CloseUI: *AP_FeatureName

Here I've used the prefix 'AP' on the main keyword but you should use a prefix that is relevant for your vendor specific information. I've used the feature main keyword "AP_FeatureName". You should use an appropriate main keyword for your feature (using your vendor prefix). I've used the single option value "SomeName"; you should pick an appropriate name. I picked an orderdependency. You should pick one that will cause the invocation code to appear in the correct place relative to the other feature invocation code in your PPD file.

Your PDE should 'claim' the feature "AP_FeatureName" so that it doesn't appear anywhere else in the UI. You PDE plist needs to have an entry that says what PPD main keyword the PDE provides a UI for. Without this, the Printer Features PDE will show a UI for your feature.

In your PDE you should continue to insert your keys into the job ticket but you also add to PPDDict the entries for the feature with the main keyword
AP_FeatureName with the option value "SomeName" (using the actual main and option keyword values you settle on). (Actually you might not even really need to do this; if you only have one feature the default code probably gets inserted by the pstops filter anyway. You can see if this is really necessary by skipping this step initially.)

By doing this in your PDE, the printer feature code will be generated into the job stream in the document setup portion of the document and it will consist of:

%%BeginFeature: *AP_FeatureName SomeName
%AP_FeatureName_InvocationCode
%%EndFeature

Of course the feature main keyword, option keyword and invocation code you actually use in your PPD will appear instead.

You should have a pretty easy time parsing for this sequence and perform the appropriate replacement in your filter. This should make your filter's job significantly easier and avoid the general parsing difficulties you might otherwise encounter.

Again, this depends on your ability to add such entries to a PPD file: if you are running a filter for a particular printer this shouldn't be a problem since you already have an entry in the PPD file to run such a filter.

Hope this helps,
David
_______________________________________________
printing mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/printing
Do not post admin requests to the list. They will be ignored.

References: 
 >CUPS filter: binary data before %%EndSetup ? (From: Marc Stibane <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.