>> 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.

We may be imagining slightly different commentaries.

Many printed bibles (or literature textbooks) are full of
tiny little explanations that are sort of like footnotes.

        The best laid plans o' mice and men
        gang oft agley.

The whole thing could be marked as "quotation from
from Robert Burn's 'Ode to a Field Mouse'", but you
might still want to mark up the "agley" for vocabulary.

Similarly, a Marlowe's Faustus text might want to indicate 
which sections were missing from/changed depending on the
folio, and still give commentary on smaller subsections
within the insertions.

>From plucker's perspective, it just has to check
(1)  whether any current annotations are completed
(2)  whether the next annotation has begun.

(This may be slow to catch some long-running annotations
when moving backwards.)

>> 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.

This only works if we assume that plucker will not be 
customized or forked for these extra fields.  If I add a 
custom annotation for supplier, and you add one for author, 
and someone else adds one for color ... they will not be 
compatible.

>> 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 again assumes that there will only be one type of extension --
and that they will always be cumulative.  I can easily imagine wanting
the 12th new header field, but not wanting the first 11, and wasting
all that space.

> Yes, I am planning to have a filter dialog that lets you choose
> things.  I am not sure what "edit" means.

Like the <ins>, <del>, and <chg> tags in html -- that this was
different in an earlier version (or should be in a later one).

> Even if it worked with tables, it wouldn't work with images.  
> So the yOffset provides more precise positioning information.

images I had not considered.  But then do you want to specify
a region, rather than just a height?

-jJ
_______________________________________________
plucker-dev mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev

Reply via email to