Re: [evince] Ink Annotations Toy Implementation

[Germán Poo-Caamaño <gpoo gnome org>]

On Wed, 2014-12-10 at 10:22 +0100, Daniel Sim wrote:
> Hi all,
>
> I have been working recently on a toy project to get ink annotations
> working in Evince.
>
> My end goal is actually to develop a Cairo-based alternative to
> Xournal (which is currently based on the obsoleted libgnomecanvas and
> doesn't do cool stuff like highlights properly).
>
> To this end, I have done the following
>
> - Implemented a loose quadtree
> (https://www.cs.umd.edu/users/hjs/pubs/sigmod13-header.pdf) for ink
> annotation segments
> - Added Ink Annotation support to Poppler-glib
>
> The code can be found at:
>
> https://github.com/xkjyeah/evince_ink
> https://github.com/xkjyeah/poppler_ink

It would good be great if you can add it also in poppler-glib-demo
(glib/demo). That helps to test it without relaying on evince, and it
can help other developers to know how to use the API.

> At its current state, you can click on ink annotations and modify
> their contents. You cannot select annotations or draw new annotations
> yet.

For drawing new annotations, I would recommend you to implement it in
poppler-glib-demo first.  The scope is narrowed and it easier to debug.
Once you get it done, you can replicate it in evince, which might
require some extra adjustments.

> At this point, I would like to ask the more experienced developers how
> to progress from here.
>
> - To meet my goal, I need extensions to PDF -- variable line width,
> different compositing operators (multiply for highlights). Is this a
> viable alternative? Could it be saved as a different file format, e.g.
> "PDF with Evince annotations"?
>
> - It boggles my mind that Evince uses the poppler_glib backend, which
> is itself an intermediate layer written in C to the C++ poppler
> backend. The poppler_glib backend is not complete. The reason I
> mention this is that it would be nice to be able to write the
> abstraction layers once and not twice -- once for poppler_glib and
> once for evince. In any case, the files in backend/pdf are written in
> C++, so I why wasn't the Poppler C++ backend used here? This is just
> an annoying detail.

For developers familiar with glib, poppler-glib is more glib-ish or
predictable, if you like.  And the use of poppler-glib is not limited
only to Evince.

> - I foresee having to rewrite the hit-detection to use a quadtree
>
> Ink annotations (as well as circles, polygons etc. if they are
> implemented in the future) are quite a different beast from nice
> rectangles, because selecting them requires clicking on their *filled*
> sections and not simply on their bounding boxes.

Anything that fits in the Rect defined for each annotation type.  I
would not worry about this at this stage.  At least not before adding
new annotations :-)

-- 
Germán Poo-Caamaño
http://calcifer.org/