> For example, if I were reading something by Plato, I might want
> to see translation notes, commentaries from Augustus, class
> notes from a professor, notes from a modern scholar relevant
> to my own paper, and my own comments.
This looks more like a task for lots of hyperlinks, and it looks like it
would be beyond Plucker's capabilities.
> > Well, maybe some work would need to be done about overlapping
> > annotations--that's something that isn't permissible yet.
>
> I understand if that is a pain for version 1, but I think it
> should change eventually, and the header format should not
> make it harder.
>
> Perhaps order annotations by start-point,
That's how it's done now.
> > There will be room in the header for future data.
>
> How?
>
> The structure I see lets you add *bytes*, but I don't see
> any reliable way to add *fields*. If I find a longer
> header length, I know that more space has been reserved,
> but I don't know what it is for; at best I can treat
> header length as a version field and hope that no one
> else extends the header differently.
Well, a longer header field will be recognized by a newer viewer that
supports the extra fields. Older viewers will ignore the new fields.
> > 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.
>
> So you are assuming that an annotation-db record will contain
> several different annotations?
No. Each record is a single annotation. But they are numbered for
convenience.
> Or are you saying that there can be several annotations of a
> single text-record, and you order them by index instead of
> by start-position? If so, why?
The indexes and start-positions are in the same order. But the nice thing
about the indexes is that as soon as you find any annotation for a page, you
then know where the first annotation for the page is, just by going back by
the index.
> > I am hoping we don't need a version yet.
>
> I think a self-defining variable header would be better, but
> I think we need at least one of the two. If we add a version
> number later, then future code will always have to say
>
> if header.length == x
> version=0
> else
> version=header.version
Probably it will just say:
MemSet( header, sizeof( header ), 0 );
MemMove( header, loadedHeader, loadedHeader.headerLength );
That way all the new fields are automatically initialized to zero, and we
can ensure that zero is always a default value.
> > 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.
>
> I was thinking of record type as indicating the layout, in case some
> annotations needed different data.
>
> edit vs commentary vs bookmark are different reasons for the
> annotation; it is possible that users will want to turn off some
> but not all annotation categories sometimes.
Yes, I am planning to have a filter dialog that lets you choose things. I
am not sure what "edit" means.
> >> What does the yoffset provide? ... Is it the absolute y-offset,
> >> making assumptions about the font and screen-width?
>
> > 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).
>
> Then doesn't trigger-start provide (a superset of) this same
> information, except that it won't be invalidated (and *might*
> be slower to render)?
>
> Instead of saying
> "30 pixels down, which I hope will be row three
> of the table",
>
> you can say
> "419 characters in, which I know is in the second
> column of the third row of the table".
Currently, the table positioning doesn't work with character offsets, I
think. Even if it worked with tables, it wouldn't work with images. So the
yOffset provides more precise positioning information.
Alex
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
