Re: [evince] PDF annotation support (tentative design)

["jose aliste gmail com" <jose aliste gmail com>]

Hey, I don't have time to do a inline reply, forgive me for that.  I have two comments: Thomas, you are right when you say that quadrilaterals, for TextMarkup annotations should be used instead of the bounding rectangle. Of course as you already pointed out, we got support for quadrilaterals only very recently in poppler-glib. But,   I think solution 1 is a no-no... it looks like a hack to me (so just my opinion).  What I would do is along the lines of solution 2 but I'll try not to modify ev-document as far as possible.  I would use the bounding rectangle to get a "plausible" annotation given a coordinate (x,y). Then, you would need a new method like ev_annot_point_inside_area (annot, x,y) that checks the quadrilaterals, or whatever depending of the annotation type, and answers TRUE or FALSE. That would have the advantage of isolating the "implementation detail" which quadrilaterals are to the backend code. So, in ev_view_get_annot_at_point we just need to add a call to this function and that should solve the issues you are mentioning. 

Of course, for design of the code, handling of forms annotations and other interactive things has some issues, and probably an interface or a kind of EvViewMiniWidget object would be desirable. 

On Tue, Mar 4, 2014 at 6:50 AM, Thomas Liebetraut <thomas tommie-lie de> wrote:

Hello Germán,

I think we perfectly managed to talk past each other... ;-)

On 04.03.2014 01:20, Germán Póo-Caamaño wrote:
>> The current code structure uses EvMapping to map from interactive area
>> to dynamic elements (like annotations) and this EvMapping is created
>> from PopplerAnnotMapping which defines a bounding rectangle that
>> completely contains the annotation.
>
> A rectangle defines the location of an annotation, no matter its type
> (text markup, link, etc.)
>
> See page 606 of PDF specification 1.7.
> http://www.adobe.com/devnet/pdf/pdf_reference.html

I'm aware of that specification and I agree that this kind of mapping is
okay for any displaying purposes or determining where the annotation is
located in the document (on a page, rather).

>> poppler recently added some missing pieces for properly supporting this
>> kind of annotation that use a list of quadrilaterals to define their
>> interactive area (<https://bugs.freedesktop.org/show_bug.cgi?id=51487>).
>
> Quadrilaterals are like rectangles, but instead of having 2 coordinates,
> they have 4 (so, you can represent a rectangle in any angle).
>
> Think in a text inclined 75 degrees.  The rectangle will define the
> whole area that covers the annotation, and the quadrilaterals will have
> only the "inclined rectangles" of the text to be highlighted.
>
> In the example you gave previously, you will 1 rectangle that covers 2
> lines, but 2 quadrilaterals, one per line.

Exactly. An this "inclined rectangle" is what I think should be the
interactive part of an annotation, e.g. opening the popup associated
with the markup. I think in your example of the rotated text, the user
would not expect the popup to be opened if he clicks somewhere inside
the bounding rectangle (the mapping rectangle) but *not* inside the
"inclined rectangle".
In a more extreme example, consider a diagonal line annotation (with a
popup) that spans the whole page from the bottom left corner to the top
right corner. The quadrilateral would follow the shape of the line (e.g.
be diagonal, too), but the mapping rectangle would cover the whole page.
Clicking somewhere in the upper left quadrant of the page should not
open the line's popup.
Similarly, in my example with a two-line highlight, you state correctly
that the rectangle covers the whole to lines. I would not expect
clicking somehwere in the beginning of the first line to open the popup
of the highlight which only starts at the very last word of this line.
This is problematic in both examples (line and highlight), especially
when there are additional annotations on the page that are inside the
bounding rectangle of any other annotation (think of some second
highlight in the beginning of the first line).

>> Long story short, I want to work on annotation support in evince and see
>> two possible solutions:
>>
>> Instead of using PopplerAnnotMapping to define the annotation's area I
>> create one EvMapping for each quadrilateral I find for the annotation
>> and reference the exact same EvAnnotation object in each of these
>> annotations.
>
> I am not sure I am follow. Quadrilaterals only exists for Text Markup
> annotations, but there are many more annotation types that do are not
> represented by quadrilaterals at all.

I am aware of that (the currently supported "postit" style annotation is
a good example) but I seeing that evince recreated large parts of
poppler's classes to abstract away from the underlying renderer (and to
support many more formats than PDF), I don't think that the Ev* stuff
should be bound by the restrictions of *some* annotations in PDF (and
not allowing (IMHO) correct handling of *other* annotations in PDF as
described above).

libview uses the bounding rectangle to determine whether the popup
should be opened and whether the mouse pointer should be changed to the
"link" pointy finger. I think this is wrong and it should use
quadrilaterals instead to determine whether the mouse pointer is
currently over an annotation. For circles or polygonal annotations, even
quadrilaterals may not be suitable, this is why I think a "is pointer at
annotation" method should be introduced in a separate interface and can
be overriden if a specific annotation type needs it.


By the way, quadrilaterals are also what okular uses to determine if the
mouse cursor is over an annotation (where applicable, of course, I still
know that not all annotations have quadrilaterals).

> I don't think it is necessary to touch the cairo context.

I did not want to touch the cairo context. I just mentioned it because
some changes in the annotation's properties (e.g. color, the hidden
flag) would require redrawing and the bounding rectangle seems suitable
for determining what to redraw (even if evince does not need that).


Regards,
  Thomas


_______________________________________________
evince-list mailing list
evince-list gnome org
https://mail.gnome.org/mailman/listinfo/evince-list