@aneuroo Annotorious uses the W3C Web Annotation format. You can find an example for a rectangle and a polygon here:
https://recogito.github.io/annotorious/getting-started/web-annotation/
https://recogito.github.io/annotorious/getting-started/web-annotation/
For those interested, I needed to "hack" annotorious to get the dropdown to open automatically. The change was simple. Inside of Autocomplete.jsx:
const onFocus = evt => {
if (!isOpen) {
this.setState({ inputItems: this.props.vocabulary }); // Show all options on focus
openMenu()
} // if
} // onFocus
and I needed to add onFocus to the Input tag:
<input
{...getInputProps({ onKeyUp, onFocus })}
placeholder={this.props.placeholder} />
I am now trying to save and close the annotation when the user selects one of the pre-defined tags. That way they don't have to click the OK button. The vast majority of our annotations will only ever have one tag. I have tried many things, but the body of the tag is not being saved no matter where I trigger the saveSelection() API. Given the name of the save API, will it ever be able to save the body? If so, any suggestions on how to achieve this functionality? I have even triggered the onOk method from the Editor.jsx. It seems like the events I can subscribe to or have access to are not late enough to include the body.
Internally, this part of the app is written in React. Adding the body is an async operation. If you add the body in your modified autocomplete, and immediately call saveSelected, then the body update would likely not yet have happened.
To test: could you wait for a few ms before calling saveSelected? I.e. a setTimeout with a bit of delay? At least that way you could test my hypothesis :-) (If it's right, the save should store the body then )
@rsimon Yeah that is my guess too. I have tried to listen to various events and trigger the save at the last possible chance in those events. That makes sense. I was thinking of adding a custom event that gets fired when the body is added. That way I can trigger save from that event.
I have actually tried a setTimeout (think I waited for 5 seconds) before triggering save. That didn't work either.
@rsimon Thanks for a great piece of software and additional thoughts here.
Damn... 5 seconds should be enough even fit React ;-) I'll try to dig into this myself when I get the chance.
"fit" -> "for"
@Garet-Jax ok checked now, and indeed - saveSelected() works only in conjunction with headless mode. It not possible to use it with the editor enabled. (Since only the editor is aware of the currently edited annotation state. .saveSelected sits one level "higher up" in the hierarchy, since it was originally designed for usage without editor.)
I think the cleaner way might indeed be to extend the editor/plugin API with a "addBodyAndSave" callback. I'll try to think through this soon-ish, so perhaps can add this to the next release. This way you should be able to create a plugin that closes the editor right after user action, without the need for complicated hacks.
Hi, I was hoping to get some feedback and ideas on positioning the editor. I've stepped through the editor functions and found my way to setPosition where the editor position is set dynamically. Most of the time this works great. I have received feedback though that sometimes this makes resizing the annotation difficult because the editor covers the top handles and blocks using those for resizing. Any thoughts on increasing the margin when this is positioned at the top so that the editor never blocks annotation handles? Happy to work on a PR for this, or implement it higher up if there is something I can do custom for the editor position with styling, but wanted to see what ideas exist for this. I recreated the behavior with the Getting Started page to help visualize the behavior.
@rsimon - any feedback you can provide would be much appreciated. The onAppendBody and onUpdateBody methods from Editor.jsx are triggered very early in the click tag process. I put a listener into the onStateChange method in Autocomplete.jsx and type 17 was the last one triggered during the course of a normal click tag sequence. Even when I tried to execute something after onStateChange type 17 was received, it still wasn't late enough. Will keep looking.
@n0mn0m I've been thinking about this myself and still didn't come to a conclusion. I agree it's a problem that the editor sometimes gets in the way (or covers - as you show in your image) the handles. Personally, what I think I'd like to do as a user is, maybe, simply grab the editor and move it to some other place manually. And it would stay there until the annotation gets saved/deselected. (After which, the auto-position would kick in like normal.)
Really a matter of taste though - I'm interested in hearing differing opinions!
@Garet-Jax the problem is that
.saveSelected() really just works in headless mode. (Sorry for this - I completely forgot about this myself, and only realized when I re-read the code yesterday.) At minimum, the function should be renamed. Ideally, the code needs rewriting so that .saveSelected() would be aware of the current draft annotation state in the editor, if Annotorious is not in headless mode.
It's a bit tricky though, because it breaks the React state hierarchy a bit. (The editor keeps its own state, .saveSelected() is handled one component further up, which doesn't know the state.) This would need changing before I can change the behavior of
.saveSelected().
2 replies
@rsimon we had actually talked about looking into the ability to have the editor float/be moved. I personally think that's a great solution long term, because then most edge cases are handled by being able to just move the box wherever you want it. One piece of feedback that I got was that it would be nice if the editor never opened inside the annotation boundary even if that mean scrolling to see the editor that way it would never obscure the view of the annotated area.
@n0mn0m hm, I'm not sure about always keeping it outside. It's really tricky with all the possible edge case. Right now the editor aims to stay fully inside the viewport. Bascially assuming that obscuring the annotation is better than pushing the editor outside the viewport, where it's not (or only partially) visible - which is a user feedback that I got :-) But in any case, +1 from me for manual moving. It's probably not hugely difficult I guess.
4 replies
@rsimon I got some time to hack on this today actually. And when I say hack, I mean hack. It's not pretty. For some context right now the project has been setup with javascript scripts embedded in SSR templates (no babel, webpack etc). Over time plan to work on that, but for now it's what I'm working with. I can move the editor using this I wrap the annotation area with an element where the id is
annotationContainer and can move the editor when it's available. The catch here is that when you click a handle the editor returns to the previous position based on the event handler and component lifecycle. Any ideas on how to disable that update? May not be possible, but thought I would ask since this solves things short term.
@n0mn0m nice! Yes, that should be most of what's needed. You can't disable the update from the outside. (At least I can't think of a way that wouldn't involve changing code inside setPosition). But
setPosition is exactly the place where your code would need to hook into. I'll try to take a stab at this on the weekend.
2 replies
Here's the commit, for info. I'm keeping it in a separate branch for now. Will check whether anything can be optimized in terms of bundle size. But after that, I think, I'll make it a feature in the next release. recogito/recogito-client-core@48c5919
Do you remember why naturalWidth/Height is used here: https://github.com/recogito/annotorious/blob/main/src/AnnotationLayer.js#L22 ?
(as opposed to using the width/height attributes)
I'm debugging some issues with <img>'s where the source is an SVG.
On firefox, the img tag will have a naturalWidth/Height of 0
@davidrusu yes, it's to support responsive images. The annotations need to use naturalWidth/naturalHeight, in order to stay aligned with the original image size. If the image is resized, the annotation shrink/grow with it. width/height on the other hand will only give you the size of the image element.
I never tried using Annotorious with SVG. Indeed that might not work...
Not sure if there's a good workaround.
I'm attempting to add annotations to some handwritten websites, you can see an example here:
I'll try to hack annotorious into working with SVG's, maybe I can contribute a patch
@davidrusu I think it might be sufficient to monkey-patch the SVG image element and attach
naturalWidth and naturalHeight props manually. E.g. el.naturalWidth = el.naturalWidth || el.width or something like that. This way, the width would serve as a default if the el doesn't have naturalWidth already (or naturalWidth of 0).
Hello @rsimon, I have worked on a feature that add events in OSDAnnotorious when the viewer is in sequence mode and there's a
page change event. The diff is here and local testing seems to work correctly. Example in index.html. Would you be willing to accept a PR for this?
Hi @umesh-timalsina, this is great - many many thanks! I think I'd like to refactor two things just a little bit (actually three):
- I don't think Annotorious needs to fire an event for the page change. The client app should probably listen to the OSD viewer for this event (since it's an OSD concern)
- I think the call to re-init the annotation layer in response to a page change can happen entirely inside
OSDAnnotationLayerclass. Right now, there's an event that goes fromOSDAnnotationLayerup toOpenSeadragonAnnotator, and thenOpenSeadragonAnnotatorcalls back down toOSDAnnotationLayerto re-init. That's probably not necessary? - Minor thing: I think it would be better to have a separate demo page for sequence mode, i.e. not the normal
index.html, but maybe asequence-mode.htmlright next to it?
and my other question is I want to add a point annotation, is it ok to do it like circle annotation creation or according to your new changes i should do something else?
@AlaEmrani The CircleFragmentSelector is not compliant to the W3C annotation model. My guess would be that he didn't want to include it in the official release on npm yet because of this reason (although I can't be sure). He's currently refactoring the codebase to make the circle selection tool standard compliant and to provide a better framework to add other shapes. Please keep in mind that because of this currently ongoing refactoring process, any circle shapes made with the current codebase will break on the next release of Annotorious.
Once he's done with the refactoring, I will also include an ellipse selector. FYI, I also need these to work in OSD because that's what I'm using for my current project.
Hi @AlaEmrani + thanks @Hero-Solutions, yes that's right - I wanted to fix the standards issue first. That's done now 🎉. I still want to refactor into a plugin before the next release, rather than bundle it into the core codebase. But that won't take very long anymore, and the plugin will be compatible with both Annotorious standard and AnnotoriousOSD.
@AlaEmrani, yes a point annotation would be great. I actually created a ticket for this a few days ago, but did't start to work on anything yet. recogito/annotorious#128 Therefore: if you want to help out, that would be awesome. Again, I think we need to figure out how the WebAnno standard would deal with this. I can do some research and add the info to the issue ticket.