[poppler] Pixel tracer

[Albert Astals Cid]

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