Re: Djvu mode

[Camm Maguire]

Greetings!

"Roland Winkler" <address@hidden> writes:

> On Sun Oct 2 2011 Camm Maguire wrote:
>> Currently the code ignores but preserves non-djvm-mode produced
>> annotations, but this should be easy to add.  
>
> I am sorry, I am confused! What kind of annotations are then added
> to the file? Are they incompatible with the standard djvu format?
> Why that?
>

The code reads all annotations, creates some, edits some that it has
created, and writes the whole lot back to the file.  It does not
display or edit "foreign" annotations yet.

The newly constructed annotations should be completely compatible.
There is a comment field in the maparea list.  I use this to label the
areas created by the djvm code primarily just as an initial rough
implementation to separate my stuff from whatever else may be in a
file.  But secondarily, the comment is used to group highlighted
regions into one block in the case they consist of contiguous
rectangles, such as highlights anchored on word boundaries, or text
comment boxes in the margin of, and logically "attached" to,
highlighted text.  The maparea construct has no other field for such
grouping AFAICT.

There is no permanent reason that this code cannot edit and display
foreign annotations.  Each maparea would have to be logically
distinct, but that is OK.  And there are several other maparea
features which are as yet unimplemented.

>> Me too.  This is the main point.  I am currently using it for this
>> with success.  I'm not really sure though whether text notes are best
>> placed in the file, as you have to click on the box to see them (in
>> emacs djvm mode or djview), 
>
> Depending on how you set up the annotations. djview displays them
> immediately - at least for me (with DjVuLibre DjView 4.5 under GNU linux).
>

OK.  Still much harder to read then what I'm really used to, which is
my own handwriting in the margin.  Alas, those days appear gone and we
must adapt as best we can.

Another weakness/feature of the current implementation is that no
margin text is written on the image over a comment box.  In emacs, one
does have to click on the box to get at the text in another buffer.
Don't know how severe this is.

>> > nicely displays these annotations including any text layers they
>> > might have.
>> 
>> Emacs with this mode does too, but just for the annotations it writes
>> itself at the moment.  It labels these with a "djvm" comment.
>
> Why "djvm"? Why being incompatible?
>

Is a comment incompatible?  The mapareas written by the djvm code show
up correctly under djview in my experience.  They display the comment
tag in djview when the mouse moves over the highlight, but this does
not appear incompatible to me.  Am I missing something?  Full
compatibility with all standards is the goal, to say the least.

>> This is a somewhat common indication of a poorly constructed text
>> layer by an early ocr engine.  I've always cleared this by a fresh
>> ocrodjvu --in-place foo.djvu.  Boxes then line up perfectly.  I think
>> the ocr code has only very recently matured.
>
> Again I am confused. Take the djvu file I attached earlier in this
> thread (produced with pdf2djvu-0.7.7). If I search a word via
> djview, it highlights the matches such that the boxes are perfectly
> aligned with the text. So I assume that the djvu file is OK. Yet
> with your mode the highlighting is shifted relative to what it is
> supposed to match. Something is misaligned here. 
> (My emacs is GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+
> Version 2.20.1) of 2011-09-19.)
>
> What am I missing here?

Thanks for this pointer, you are missing nothing.  The current code is
assuming a page box beginning at 0 0 as this is what I've been
accustomed to working with ocrodjvu.  Told you it was rough!  I see
now this is really a special case, and will post a patch soon.

If you want to see correct alignment for further testing/commenting
purposes, take a look at p2.djvu below, which I've ocr'ed as described
earlier.  You can also see the different layout in the text layer.

BTW, there are a few other needed improvements of which I'm currently
aware.  For example, I've written the routines mostly recursively from
my experience with GCL, but this is blowing out emacs limits on some
really big files.

Take care,

>
> Roland
>
>
>
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

p2.djvu
Description: p2