Sargrad, Dave wrote: > I understand that podofo is not a renderer.. I want it specifically > because it does not render! We have some very specific rendering > requirements.
Glad to hear it. I just wanted to make sure you weren't under any misapprehensions. > My first-use intent (relative to podofo) is to build a document viewer > that leverages the ogre renderer, and to use podofo to parse/interpret > the objects contained within the pdf file. That sounds fairly reasonable. Your main issue will be that at present PoDoFo won't help you parse content streams. You will need to parse content streams as part of rendering a PDF. It would be absoltely wonderful if as part of your work you ended up writing even a rudimentary content stream parser that was self contained enough to be included in PoFoFo . This would probably be wise anyway, rather than mixing your basic content stream parsing with rendering code. I'd be happy to lend my limited time and more limited skill to help with that - and I'm one of those freaks who actually *likes* cleaning up and integrating code, fiddling with build systems, etc. Looking at your PDF after uncompressing it, you might be in an ideal situation for a simple content stream parser to be very handy. > I took a quick look at libpoppler and I believe it makes very specific > rendering assumptions, so my approach was to use podofo to interpret the > contents of the pdf file, and I would tackle all the higher level > rendering. Fair enough. > In my case rather than libpoppler, I will be using Ogre as the rendering > engine. I can guarantee that I don't yet fully appreciate the work > involved to get to the point where I can render the objects that PoDoFo > draws from any particular PDF file. I believe there is quite a bit of > work, and yet am hoping that I can prototype something in fairly short > order. I sincerely hope so. Rendering PDF is very complicated, and that's if you assume most PDF is correct (which is far from the truth). The number of verisons and options doesn't help. That said, it's hardly impossible. If you can limit yourself to a certain subset of PDF, at least initially, things might be much easier. Some things are worth getting right from the start IMO (ICCBased & CMYK colour, for example) but I wouldn't be too surprised if you were able to get away without handling things like layer blend modes initially. Then again, for all I know they're easy with your rendering backend. Looking at the attached PDF, I think it's safe to say you can handle a very restricted subset of PDF and still be OK. I begin to see why you're doing it the way you are. A content stream parser for that shouldn't be too hard to write at all by the looks. %PDF-1.4 %»°°« Layton Graphics, Inc. pdf++ library 1 0 obj << /CreationData (D:20070928141754) /Producer (dgn2pdf) I presume dqn is a custom format in use in your industry, and that you don't have access to the original files the PDFs were created from? (Just curious...). Speaking of "nice to have" ... wish our stream interfaces were usable as iostream buffers so they could be processed with C++ stream operations... . Unforutnately implementing new iostreams interfaces is rather far from fun. -- Craig Ringer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
