Will there be only one annotation/bookmark db per text db?
Yes. I don't think the renderer should be scanning several.
I know that one of the earlier goals was to distribute commentaries, and there will probably be some texts that
have more than one relevant commentary. Unless there is
a good way to merge them, even after a beam-to-existing-name,
it would make sense to allow multiples.
One solution is to make some "merge" code. It would be quite easy. One would just beam via an "Export to IR" menu option which simply changes the name of the database. Then when Plucker is run on the other end, it merges the databases, which just means that it appends all the records from one to the other and sorts. Well, maybe some work would need to be done about overlapping annotations--that's something that isn't permissible yet.
Also, if you allow multiples (especially if you merge them
into a single db), you might want a way to save attribution and even date (or timestamp), possibly as one of the header fields. I could imagine marking comments from one scholar
in Red and another in Blue when trying to compare their
opinions.
There will be room in the header for future data.
typedef struct { UInt16 uid; UInt16 headerLength; /* sizeof( AnnotationEntry ) */ UInt16 index; UInt16 paragraphNum; UInt16 triggerStart; /* relative to paragraph start */ UInt16 triggerStop; /* relative to paragraph start */ UInt16 dataOffset; /* offset of data from beginning of this record
*/
UInt16 dataLength; } AnnotationEntry;
Just a check -- is uid the record number of the annotation, and
index the record number of the annotated record?
The uid is the record number of the annotated record. The index is the index of annotation within the annotations for this record. Thus, the first annotation for this record is 0, etc.
HeaderVersion? Or is that in the db header, and assumed to be constant within a single annotation database? (And the same question regarding which db this annotates. Is it possible to annotate more than one pdb from the same commentary?)
I am hoping we don't need a version yet. If we want one later, we just increase headerLength.
RecordType (Bookmark vs edit vs commentary)? Or is that assumed to be handled by the palm categories? I suspect we will want both record type and user-defined categories within (at least some) annotation types.
I don't know about "edit". As for bookmark vs. annotation, the difference is not significant really. I consider annotations where triggerStart == triggerStop to be bookmarks.
Is there a way to make annotations that span paragraphs,
Not with the current highlighting code. However, eventually, it could be done by just allowing triggerStop to point beyond the current paragraph.
> For paragraphs, you could just add a stop
paragraph number, but for different indices, you might want a
"refer to annotation X; it still applies" record.
This can be done if we need it later.
headerLength is used so we can extend this later to include other data, such as RGB value of highlight, and anything else
one might fancy.
Attribution, time, category (categories?)
Again this can be done later, since we can extend headerLength.
We might lose one thing. Currently bookmarks specify not just the byte offset, but also a yoffset.
What does the yoffset provide? Is it a hint about drawing if you follow that bookmark? Is it the absolute y-offset, making assumptions about the font and screen-width?
The latter. It lets one position things precisely, so a bookmark can be set on a half-line, or more usefully, half-way through a table. Currently when the assumptions become invalid, the y-offset is invalidated, and the bookmark just goes to the top of the text that is bookmarked (e.g., top of table, start of line).
Do we still keep the add annotation form and the add bookmark forms separate? The visual difference is that the add bookmark form is a small popup,
Unless this changed since 1.7.2, the bookmark form already covers plenty of screen; so long as you continue to prefill it with reasonable
defaults so that a single "OK" works, then covering a bit more shouldn't
matter.
Sounds good.
Alex _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
