[poppler] Pixel tracer

[Volker Grabsch]

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?

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

-- 
Volker Grabsch
---<<(())>>---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: poppler-pixel-tracer.patch
Type: text/x-diff
Size: 4162 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20141118/0a4420fa/attachment.patch>