El Dimarts, 18 de novembre de 2014, a les 12:52:34, Volker Grabsch va escriure: > Dear Poppler developers, > > I have the task to render PDF documents and to trace back each output > pixel to the object(s) that were rendered at this place. To achieve > this, Poppler is a great help, so I'd like to contribute something > back. Attached is the second smallest patch (see below) I came up > with. > > Do you think it makes sense to include this feature in Poppler?
Thanks for the patch :) I am not totally sure it makes sense, seems a bit of a corner case feature and the more code we include the more maintainance overhead we have (and we are really low on manpower). What do other think? Cheers, Albert > > Usage: > > A. Use the private poppler API to render a PDF onto a custom OutputDev. > > B. Derive that custom OutputDev from SplashOutputDev. > > C. Set your tracePixel() callback, which is called for each rendered > pixel. It may be part of the same custom OutputDev class. > > D. Keep track of which object is rendered right now (overwriting > drawImage(), etc.), and use that information within tracePixel(). > > To get the discussion started, these are the things I think I could > have done differently: > > 1. Currently, tracePixel() is called in addition to the "pipe run". > However, it could also be called instead of the "pipe run". This > would result in an even smaller patch, but it would suppress the > PDF output while the tracer is run, which could possibly cause side > effects on anti aliasing and other things. Also, since I need the > rendered image as well, I would have to run the renderer twice - > with and without pixel tracer. > > 2. The tracePixel() callback only gets the pixel coordinates (x, y), > which is sufficient for my task. However, one could also think > of providing the actual pixel value to that callback. The drawback > is the additional complexity of handling different types of pixels. > (RGB, Mono, etc.) > > 3. I could have used a more C++-like interface, using templates, > std::function and other nice stuff. However, that would not fit > well in the current coding style of Poppler, thus requiring a lot > more changes. On the positive side, this would allow for a > completely transparent tracing mechanism, where e.g. the compiler > is able to optimize an empty tracer function completely away. > Also, that could restructure the current "pipe" mechanism in a way > that is as flexible as now, but would enable the compiler to inline > the complete "pipe run" code without any function call. > > 4. I could have added the whole code for the object tracing to > Poppler, rather than just the ability to add custom callbacks. > However, this would be less flexible, and it is probably not a good > idea to overload the Poppler project with too much specialized code > that is useful for just one or two applications. > > > Regards, > Volker _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
