In our case storeLogic=1, so one annotation per file. Same as in PDF XFDF annotations, same as in all products of your competitors (Brava, OpenAnnotate, ARender etc). That’s the only approach that everybody uses nowadays.
Some of those tools uses Aspose libraries as well and your tool is unfortunately far way behind them.
The main issue we have right now is the way annotations are stored and referenced. Especially that user name as INTEGER.
This is how the other tools reference the annotations:
1. ID - depends on system, LONG or STRING
2. User name - STRING
3. Creation Date - TIME
4. Modify Date - TIME
5. Content as XML which is basically the annotation definition
Then there is an external relation that binds the document and the annotation by ID, relation depends on the backend. That way documents and annotations can be easily migrated and only the references in the relations need to be updated when the ID changes, but it’s handled by default in every system migration utility.
So if the GD Annotation can meet that requirement, we’d be more than happy with upcoming the new version. If it’s just a Viewer change that doesn’t modify the Annotation design you currently have and it required manual update of all the annotations, then unfortunately we need to reconsider using it.