Hi, sorry for not having replied for two weeks, but other things kinda got in the way. After having read more of the source code of evince, poppler and okular and the PDF specification, I have some refined ideas about the annotation stuff. On 04.03.2014 12:43, jose aliste gmail com wrote:
But, I think solution 1 is a no-no... it looks like a hack to me (so just my opinion).
I completely share that feeling, I just mentioned it because it really is minimally invasive to the rest of the code and could therefore have been preferred by someone else.
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.
What exactly do you mean by "backend" here? EvAnnotation is completely self-contained in libdocument and does not refer to the poppler backend (in a stable and well-defined way). If by backend you mean libdocument and that libview should not know anything about quadrilaterals or similar concepts, I agree and would have implemented it that way anyway. In fact, it is funny that you mention that, because I don't think having individual annotation types in libdocument is feasible. Suppose some other document format backend provides annotations but their features do not match those of poppler/PDF. If EvAnnotation* is tailored towards PDF annotations, additional features of some other format cannot be accessed in Evince. Likewise, if the UI allows to modify certain annotation features, e.g. color, and a document backend does not support colored annotations, the information that the user entered is lost upon saving. Worse still if a complete type of annotation is not supported by a backend. This may not be a problem now as poppler is the only backend that implements EvDocumentAnnotations and I don't see that change anytime soon, but it may be problematic in the future. In the long run, I think it would be better to only have EvAnnotation in libdocument and move all subclasses thereof to the actual document backends. They know best which properties their annotations support. Anyway, I don't want to open this can of worms, so I'll follow my second proposal and add EvAnnotation* classes that correspond to the annotations supported by poppler 0.24 without trying to be smart about them and try to combine them to simpler "abstract" annotation types (like line, polygon and rect/circle annotations are all some sort of geometry annotation). This is what I first had in mind, but the more I think about it, the worse it will make things for non-poppler backends. Thomas
Attachment:
signature.asc
Description: OpenPGP digital signature