[annotator-dev] Image annotation

Kristof Csillag csillag at hypothes.is
Sun Oct 12 10:53:24 UTC 2014

Hi Rainer,

Yes, keeping items at the ends definitely helps; we actually modified 
Annotorius to do that with some of the added elements; IIRC all of 
them, except the actual wrapping around each image.

Yes, there are change DOM events, and we were using them - but the 
situation proved to be more complex than expected in quite a few corner 
cases. (Imagine the interaction between the site's built-in image 
magnifying feature + Annotorious playing around in the DOM, and 
Annotator trying to keep up with an up-to-date info about he various 

The solution is probably the stop trying to keep and up-to-date mapping 
information database about the DOM, and look for the data when we need 
it instead. Probably that's what we are doing in the next major version 
of the dom-text-mapper library, and then the DOM manipulation won't 
bother us any more.

(And it might even work in IE, too.)


2014. okt. 12., v 10.03-kor-kor, Simon Rainer <Rainer.Simon at ait.ac.at> 
> Hi Kristof,
> there may be a way around some of the nastier DOM manipulations. The 
> Annotorious components could be added as absolutely positioned 
> elements at the end of the body. That's potentially less intrusive.
> I did that initially, but it failed in cases where images are moved 
> around via JS (typical scenario: image carousels). Hence the 
> 'wrapping' that now occors. I think that browsers now issue 'DOM 
> change' events, however, which could be used to reposition annotation 
> overlays. So this may be worth a try. (Probably won't work in IE 
> though ;-)
> Cheers,
> R
> ---
> Sent via mobile
> ________________________________________
> Von: annotator-dev [annotator-dev-bounces at lists.okfn.org]" im 
> Auftrag von "Kristof Csillag [csillag at hypothes.is]
> Gesendet: Samstag, 11. Oktober 2014 14:50
> An: annotator-dev at lists.okfn.org
> Betreff: Re: [annotator-dev] Image annotation
> Dear all,
> Here is a very short summary of what we have done in H's form of 
> Annotator.
>  * First, we have moved from the current annotation data format to 
> one closer to the OA model: instead of ranges, we have targets, and 
> those targets are described by selectors.
>  * We have defined a bunch of selectors for text (again, the same 
> ones used in OA), and defined one (or two) selectors for describing 
> image fragments, as described by Annotorious
>  * Extended the annotation anchoring mechanism, so that the available 
> anchoring algorithms can be shipped in plugins, and registered with 
> the code. When a target needs to be anchored, all the registered 
> anchoring algorithms are asked if they can handle it.
>  * Also, we extended the system to (logically) separate anchors (as 
> the abstract information about where an annotation goes) from the 
> highlight (as the actual "physical" manifestation of an anchor, 
> visible to the user).
>  * We have extended the system to support different types of anchors 
> and different types of highlights. (And we have implemented the 
> corresponding types for image.)
>  * We created an image annotation plugin for Annotator, which bridged 
> Annotorious with the framework in Annotator core.
> Actually, most of this work is independent of Image annotations, but 
> considered in necessary, in order to do it the right way.
> In the end, we never really deployed the image annotation code, 
> because Annotorious has a nasty habit of changing the DOM in various 
> haphazard ways, and one of our other libraries (d-t-m, used for fuzzy 
> text maching) was not quite up to the task of dealing with this, but 
> we have a fix for that in the pipe, too.
> Now, this is all on our Annotator fork, and we plan to port it back 
> to upstream Annotator 2.0.
> The latest plan to do so looks like this:
>  * We will release the framework (for handling multiple types of 
> selectors, algorithms, anchor types, highlights, etc) as a separate 
> library, with glue code for various versions of Annotator (A1.2.x, 
> A2.0, our fork)
>  * We will release separate libraries that contain the various pieces 
> of functionality which we implemented on top of this framework (fuzzy 
> anchoring for text, image anchoring, annotator running over pdf.js, 
> etc.)
> Does this look good to you all?
>    Kristof
> On 2014-10-10 20:24, Jamie M Folsom wrote:
> Hi Folks,
> We have a developer working with us this fall who is interested in 
> helping with image annotation, so I thought we’d reach out and see 
> what work has and has not been done on that in the Annotator 
> ecosystem.
> Gergely mentioned back in May that there was some work done on h. 
> We’d be glad to pitch in and work on a plugin that others could 
> use, but I don’t want to duplicate effort if there’s something 
> else underway.
> Thanks!
> Jamie
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org<mailto:annotator-dev at lists.okfn.org>
> https://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20141012/f4b3aaef/attachment-0004.html>

More information about the annotator-dev mailing list