Andreas Vox wrote: > Hi Craig, > > as I read the PDF reference, that sequence is legal. The restriction > on BMF/EMF is just not to break up any *graphic objects*, but paired > graphic state operators don't matter. This makes sense, since BMF/EMF > is supposed to be a very general markup facility which should also > allow to mark eg. "setup page" or "page trailer" sequences. The > restrictions on BT/ET are neccessarily much stronger. Also specific > variants of BMF/EMF pairs might need further restrictions, but that's > application dependent. > >
I expect you're right, as I couldn't find anything to the contrary and Adobe's own usage fits with that. I guess that means there's no neat way to provide a generalised tree representation of the content stream. I might just ditch the idea and leave it to users to implement what they need based directly on Dom's PdfContentsTokeniser. I was hoping to provide something higher level and suitable for use with generalised algorithms (for example, scanning a contents stream and converting all colours to RGB) so that users didn't have to write the guts of the process themselves for each operation... but I'm not sure I can come up with something more useful than a flat list unless there's a strong guarantee of nesting rules for large sets of operators. Thanks for looking into this Andreas. -- Craig Ringer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
