highlighting large regions (comments) with font-lock keywords

highlighting large regions (comments) with font-lock keywords

[Eric Schulte]

Hi,

I'm working on a major mode for a new language [1] which comments
regions between \* ... *\.  I've properly (I believe) instantiated
font-lock keywords, and I have added a function to the
`font-lock-extend-region-functions' list to ensure that both ends of a
comment are always considered at the same time but unfortunately comment
highlighting often does not work.

Specifically, when I first enter a buffer and right after calling
`shen-mode' all comments are properly highlighted, however as I edit and
navigate in the buffer larger comments often lose fontification.

Any thoughts as to the cause of or solution to this problem would be
greatly appreciated.

Thanks -- Eric

Footnotes: 
[1]  https://github.com/eschulte/shen-mode/blob/master/shen-mode.el

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: highlighting large regions (comments) with font-lock keywords

[Stefan Monnier]

> I'm working on a major mode for a new language [1] which comments
> regions between \* ... *\.  I've properly (I believe) instantiated
> font-lock keywords, and I have added a function to the
> `font-lock-extend-region-functions' list to ensure that both ends of a
> comment are always considered at the same time but unfortunately comment
> highlighting often does not work.

> Specifically, when I first enter a buffer and right after calling
> `shen-mode' all comments are properly highlighted, however as I edit and
> navigate in the buffer larger comments often lose fontification.

Let's see:

   (defun shen-font-lock-extend-region-comment ()
     "Move fontification boundaries to contain whole comments."
     (let ((changed nil))
       (goto-char font-lock-beg)
       (when (and (re-search-forward "\\\\\\*" font-lock-end t)
                  (< (match-beginning 0) font-lock-beg))
         (setq font-lock-beg (match-beginning 0)
               changed t)
         (when (and (re-search-forward "\\*\\\\" nil t)
                    (> (match-end 0) font-lock-end))
           (setq font-lock-end (match-end 0)
                 changed t)))
       changed))

We have an obvious problem here: after (goto-char font-lock-beg) we're
at font-lock-beg, and after (re-search-forward "\\\\\\*" font-lock-end
t), we can only be further, so (match-beginning 0) will never be
< font-lock-beg.

BTW, why not simply do:

   (defvar shen-mode-syntax-table
     (let ((table (make-syntax-table)))
       (modify-syntax-entry ?- "w" table)
       (modify-syntax-entry ?\\ ". 14" table)
       (modify-syntax-entry ?* ". 23" table)
       (modify-syntax-entry ?? "w" table)
       (modify-syntax-entry ?< "w" table)
       (modify-syntax-entry ?> "w" table)
       table)
     "Syntax table to use in shen-mode.")

Oh, and I haven't looked any other part of the code, but just happened
to see:

  (add-to-list 'font-lock-extend-region-functions
               'shen-font-lock-extend-region-comment t))

Where the `local' arg is nil whereas it should be t (maybe the t was
meant for `local' rather than for `append'?).


        Stefan

Re: highlighting large regions (comments) with font-lock keywords

[Eric Schulte]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm working on a major mode for a new language [1] which comments
>> regions between \* ... *\.  I've properly (I believe) instantiated
>> font-lock keywords, and I have added a function to the
>> `font-lock-extend-region-functions' list to ensure that both ends of a
>> comment are always considered at the same time but unfortunately comment
>> highlighting often does not work.
>
>> Specifically, when I first enter a buffer and right after calling
>> `shen-mode' all comments are properly highlighted, however as I edit and
>> navigate in the buffer larger comments often lose fontification.
>
> Let's see:
>
>    (defun shen-font-lock-extend-region-comment ()
>      "Move fontification boundaries to contain whole comments."
>      (let ((changed nil))
>        (goto-char font-lock-beg)
>        (when (and (re-search-forward "\\\\\\*" font-lock-end t)
>                   (< (match-beginning 0) font-lock-beg))
>          (setq font-lock-beg (match-beginning 0)
>                changed t)
>          (when (and (re-search-forward "\\*\\\\" nil t)
>                     (> (match-end 0) font-lock-end))
>            (setq font-lock-end (match-end 0)
>                  changed t)))
>        changed))
>
> We have an obvious problem here: after (goto-char font-lock-beg) we're
> at font-lock-beg, and after (re-search-forward "\\\\\\*" font-lock-end
> t), we can only be further, so (match-beginning 0) will never be
> < font-lock-beg.
>
> BTW, why not simply do:
>
>    (defvar shen-mode-syntax-table
>      (let ((table (make-syntax-table)))
>        (modify-syntax-entry ?- "w" table)
>        (modify-syntax-entry ?\\ ". 14" table)
>        (modify-syntax-entry ?* ". 23" table)
>        (modify-syntax-entry ?? "w" table)
>        (modify-syntax-entry ?< "w" table)
>        (modify-syntax-entry ?> "w" table)
>        table)
>      "Syntax table to use in shen-mode.")
>

Hi Stefan,

Yes, the syntax-table method is definitely preferable.  Simpler and
(more importantly) works reliably.

>
> Oh, and I haven't looked any other part of the code, but just happened
> to see:
>
>   (add-to-list 'font-lock-extend-region-functions
>                'shen-font-lock-extend-region-comment t))
>
> Where the `local' arg is nil whereas it should be t (maybe the t was
> meant for `local' rather than for `append'?).
>

You're right again, I should have made font-lock-extend-region-functions
local before appending to it.  Luckily this font-lock-fanciness can be
discarded now thanks to the simple syntax table fix.

Thanks for the help, much appreciated -- Eric

>
>
>         Stefan

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Djvu mode

[Camm Maguire]

Greetings!  I've developed a .djvu editing mode for my personal use,
and wonder if there is wider interest in pushing it out as a package,
Debian or otherwise.  

Some features:

* toggling between page image views and synthesized full text layer
  for rapid navigation, automatically executed during isearch
* extract text and image under highligted region or point
* highlight by word box boundaries on image
* highlight word occurrences on image
* edit text "pushpin" margin notes
* save and edit annotations
* orgmode/bibtex capture support
* edit text tree as lisp sexp in a buffer, useful to correct the
  occasional ocr error.

Anyway, its all pretty rough just for my own purposes, but if others
have interest it could be polished.  I felt compelled to spend a few
days putting this together as I could not locate a good robust tool
for annotating and indexing large volumes of scientific papers in free
software.  

Take care,
-- 
Camm Maguire			     		    camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: Djvu mode

[Sivaram Neelakantan]

On Wed, Sep 28 2011,Camm Maguire wrote:

> Greetings!  I've developed a .djvu editing mode for my personal use,
> and wonder if there is wider interest in pushing it out as a package,
> Debian or otherwise.  
>

[snipped 13 lines]

> Anyway, its all pretty rough just for my own purposes, but if others
> have interest it could be polished.  I felt compelled to spend a few
> days putting this together as I could not locate a good robust tool
> for annotating and indexing large volumes of scientific papers in free
> software.  
>
> Take care,

Well, you could post it to gnu.emacs.sources if you're willing to GPL
it. 


 sivaram
 -- 

Re: Djvu mode

[Stefan Monnier]

> Greetings!  I've developed a .djvu editing mode for my personal use,
> and wonder if there is wider interest in pushing it out as a package,

I think we'd welcome it into GNU ELPA (assuming it's an Emacs package).


        Stefan

Re: Djvu mode

[Roland Winkler]

On Wed, Sep 28 2011, Camm Maguire wrote:
> Greetings!  I've developed a .djvu editing mode for my personal use,

Same here  :-)

> Some features:

...reads familiar. My code is essentially a front end to djvused from
djvulibre.

> Anyway, its all pretty rough just for my own purposes,

Same with my code  :-)

I believe that right now there is not too much to discuss about this on
emacs-devel. While I haven't seen your code yet I'd be happy to merge
mine with yours. To avoid further duplication of code development I've
posted my code on emacs-sources. (Who else is developing a djvu mode
these days? Please, let us know!)

We can discuss details.

Roland

Re: Djvu mode

[joakim]

Roland Winkler <winkler@gnu.org> writes:

> On Wed, Sep 28 2011, Camm Maguire wrote:
>> Greetings!  I've developed a .djvu editing mode for my personal use,
>
> Same here  :-)
>
>> Some features:
>
> ...reads familiar. My code is essentially a front end to djvused from
> djvulibre.
>
>> Anyway, its all pretty rough just for my own purposes,
>
> Same with my code  :-)
>
> I believe that right now there is not too much to discuss about this on
> emacs-devel. While I haven't seen your code yet I'd be happy to merge
> mine with yours. To avoid further duplication of code development I've
> posted my code on emacs-sources. (Who else is developing a djvu mode
> these days? Please, let us know!)

I wrote the ImageMagick support for Emacs 24 specifically so I could
view djvu images. Other than that I haven't made anything, so I'm very
interested in your different djvu modes. I hope you can work together
and include the code in Gnu ELPA.

> We can discuss details.
>
> Roland
>

-- 
Joakim Verona

gnu-emacs-sources down? [was: Djvu mode]

[Roland Winkler]

On Wed, Sep 28 2011, Sivaram Neelakantan wrote:
> On Wed, Sep 28 2011,Camm Maguire wrote:
>> Anyway, its all pretty rough just for my own purposes, but if others
>> have interest it could be polished.
>
> Well, you could post it to gnu.emacs.sources if you're willing to GPL
> it.

Well, I can only speak for my own GPL'ed version of djvu-mode.
This morning I sent it to gnu-emacs-sources@gnu.org.
I haven't seen it up to now neither at
http://lists.gnu.org/archive/html/gnu-emacs-sources/
nor on gmane. Is this thing somehow down?

Roland

Re: gnu-emacs-sources down?

[Glenn Morris]

Roland Winkler wrote:

> nor on gmane. Is this thing somehow down?

No, it is moderated (like all GNU lists?). Please be patient.

Re: gnu-emacs-sources down? [was: Djvu mode]

[Sivaram Neelakantan]

On Thu, Sep 29 2011,Roland Winkler wrote:

> On Wed, Sep 28 2011, Sivaram Neelakantan wrote:

[snipped 7 lines]

> Well, I can only speak for my own GPL'ed version of djvu-mode.
> This morning I sent it to gnu-emacs-sources@gnu.org.
> I haven't seen it up to now neither at
> http://lists.gnu.org/archive/html/gnu-emacs-sources/
> nor on gmane. Is this thing somehow down?
>
> Roland
>
>
>

from the gmane news server.... happy? :-)

--8<---------------cut here---------------start------------->8---
O  [27-Sep: Kevin Ryde          ] elisp-docstring-preview.el v.1 [18k]
O      [27-Sep: Uwe Brauer          ]  [4.6k]
O          [29-Sep: Kevin Ryde          ]  [4.4k]
 .             [29-Sep: Uwe Brauer          ]  [5.5k]
 . [29-Sep: Roland Winkler      ] Re: Djvu mode [77k]
--8<---------------cut here---------------end--------------->8---


BTW, thanks for the upload.

 sivaram
 -- 

Re: Djvu mode

[Roland Winkler]

On Thu Sep 29 2011 joakim@verona.se wrote:
> I wrote the ImageMagick support for Emacs 24 specifically so I could
> view djvu images.

...What is this supposed to do?  I do not know much about image
support in emacs. How can this possibly handle djvu files?

> Other than that I haven't made anything, so I'm very interested in
> your different djvu modes. I hope you can work together and
> include the code in Gnu ELPA.

Right now I have no idea what kind of functionality one can possibly
get for viewing djvu files from ImageMagick in Emacs. I've never
dealt with that.

Currently, my djvu mode is completely built around the djvu text
layer (via djvused). For simplicity it uses djview as an external
viewer, though this could be changed. How does ImageMagick handle
highlighting in djvu pages?

Roland

Re: Djvu mode

[Camm Maguire]

Greetings!

"Roland Winkler" <winkler@gnu.org> writes:

> On Thu Sep 29 2011 joakim@verona.se wrote:
>> I wrote the ImageMagick support for Emacs 24 specifically so I could
>> view djvu images.
>
> ...What is this supposed to do?  I do not know much about image
> support in emacs. How can this possibly handle djvu files?
>
>> Other than that I haven't made anything, so I'm very interested in
>> your different djvu modes. I hope you can work together and
>> include the code in Gnu ELPA.
>
> Right now I have no idea what kind of functionality one can possibly
> get for viewing djvu files from ImageMagick in Emacs. I've never
> dealt with that.
>
> Currently, my djvu mode is completely built around the djvu text
> layer (via djvused). For simplicity it uses djview as an external
> viewer, though this could be changed. How does ImageMagick handle
> highlighting in djvu pages?
>

Just to add to the mix, the code I posted uses ddjvu to output ppm
images, and uses native emacs image-mode to view them.  Mouse
coordinates are translated from the ppm pixel map into djvused text
and annotation coordinates and vice versa as needed.

Take care,

> Roland
>
>
>
>

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

Re: Djvu mode

[joakim]

"Roland Winkler" <winkler@gnu.org> writes:

> On Thu Sep 29 2011 joakim@verona.se wrote:
>> I wrote the ImageMagick support for Emacs 24 specifically so I could
>> view djvu images.
>
> ...What is this supposed to do?  I do not know much about image
> support in emacs. How can this possibly handle djvu files?
>
>> Other than that I haven't made anything, so I'm very interested in
>> your different djvu modes. I hope you can work together and
>> include the code in Gnu ELPA.
>
> Right now I have no idea what kind of functionality one can possibly
> get for viewing djvu files from ImageMagick in Emacs. I've never
> dealt with that.
>
> Currently, my djvu mode is completely built around the djvu text
> layer (via djvused). For simplicity it uses djview as an external
> viewer, though this could be changed. How does ImageMagick handle
> highlighting in djvu pages?

I don't know so much about these advanced features of djvu.

The ImageMagick support works like any other image support in Emacs. If
you've configured it to be used you can for example open an image in a
buffer from dired. Emacs image functions also support opening a
particular image in a djvm container but because of limitations in
imagemagick it doesn't work too well.

My usecase is scanning a lot of pages and converting each page to djvu,
and then to the djvm container. I have an emacs package called "emsane"
on github for this. I've been meaning to implement ocr with ocropus and
somehow create the djvu text layer that way but I haven't gotten around
to it.

Can you explain what you mean with highlighting? There are lots of
things you can do in Emacs. For instance I have a trivial example called
dragbox.el on github which makes it possible to interactively create a
rectangular overlay on an image. The region can then be extracted and ocr:ed.

>
> Roland

-- 
Joakim Verona

Re: Djvu mode

[Roland Winkler]

On Thu Sep 29 2011 joakim@verona.se wrote:
> Can you explain what you mean with highlighting? There are lots of
> things you can do in Emacs. 

I have in mind the annotation syntax of djvu documents which allow
you to add annotations (highlighting and text) to a djvu document.
Under GNU Linux, see the man page of djvused.
These annotations are nicely displayed by, e.g., djview. (I just
noticed that the Gnome viewer evince ignores them - too bad!).

I guess in principle it should be possible for a djvu viewer inside
emacs to display these things, too, though I do not know yet how
this could be implemented.

Roland

Re: Djvu mode

[joakim]

"Roland Winkler" <winkler@gnu.org> writes:

> On Thu Sep 29 2011 joakim@verona.se wrote:
>> Can you explain what you mean with highlighting? There are lots of
>> things you can do in Emacs. 
>
> I have in mind the annotation syntax of djvu documents which allow
> you to add annotations (highlighting and text) to a djvu document.
> Under GNU Linux, see the man page of djvused.
> These annotations are nicely displayed by, e.g., djview. (I just
> noticed that the Gnome viewer evince ignores them - too bad!).
>
> I guess in principle it should be possible for a djvu viewer inside
> emacs to display these things, too, though I do not know yet how
> this could be implemented.

Do you have a recipe to create and verify such a highlight? I could then
have a look if ImageMagick also supports this.

>
> Roland

-- 
Joakim Verona

Re: Djvu mode

[Roland Winkler]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1006 bytes --]

On Sat Oct 1 2011 joakim@verona.se wrote:
> Do you have a recipe to create and verify such a highlight? I could then
> have a look if ImageMagick also supports this.

See attached for an example djvu file.

If you have djview installed, you should see that the sentence

   Do you have a recipe to create and verify such a highlight?

is not only highlighted, but it also has a text annotation.

I added these annotations with my djvu.el. But as I said, this is
just a front end for the djvused command line tool that is doing the
real work. For example

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

$ djvused p1.djvu -e 'output-ant'
select; remove-ant
# -------------------------------------
select 'p1.djvu'
set-ant
(maparea "" "Use my package djvu.el." (rect 56 778 3364 84) (hilite #EEFF00) (opacity 50) (none))
(maparea "" "" (rect 56 3531 1184 146) (hilite #FF0070) (opacity 50) (none))
.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

See the man page of djvused.



[-- Attachment #2: p1.djvu --]
[-- Type: application/djvu, Size: 14788 bytes --]

Re: Djvu mode

[Camm Maguire]

Greetings!

"Roland Winkler" <winkler@gnu.org> writes:

> On Thu Sep 29 2011 Camm Maguire wrote:
>> ... or just remove the -u from the code, your text will have a few
>> control codes, but you should still be able to get the idea.
>
> Thanks, this works.
>
>> There are two highlighting modes, one by just dragging mouse-1 over
>> any rectangle, which allows selection of text or an underlying image
>> such as a graph (see "q" and "i"), and one anchored to the text,
>> whereby if you click on the image of word 1, which appears in the
>> minibuffer, and then on word 2, which does likewise, you can do "h" to
>> highlight that region.  Dragging mouse-3 removes any overlapping
>> highlighted region.
>
> What kind of highlighting are you talking about: highlighting that
> is just visible while the document is displayed? Or highlighting via
> the maparea annotation syntax that is permanently stored in the djvu
> document? -- With your code, when I view a djvu document that

Both, but see below.

> already contains maparea annotations the respective areas are not
> highlighted in emacs.
>

Currently the code ignores but preserves non-djvm-mode produced
annotations, but this should be easy to add.  

For example, drag a box with mouse-1, then type 'k' (for "keep"), then
's' for save.  The highlighted rectangle is now permanent.  Dragging
with mouse-3 over an overlapping box removes the highlight, and then
's' will eliminate it from the file.

Or mouse-1 on a word, which should appear in the minibuffer blow, then
another, then type 'h' for highlight, then 'k' and 's'.  This allows
highlighting anchored on word boundaries.

In either case, 'q' gives the text in the most recent highlighted box
by default, but with a prefix 'q' allows mouse-1 to select a different
region.  'i' works the same for an extracted sub-image.

You can mouse-1 on a word, then hit 'e' and see the text layer in lisp
with the point at the word in question.  You can edit, then save to
the file with C-cC-c.

'c' prompts for mouse-1 to select a highlighted region, and then
another mouse-1 to select a text box note location, then creates a
buffer for you to add any text note at that spot in the document.  The
new box appears as a pushpin note in djview.

'w' highlights words by regexp, adding to a list until cleared by 'w'
with a prefix.

'r' does reverse illumination.  'n' and 'p' advance and turn back
pages, taking an argument for the number to skip.  M-g g advances to a
given page as elsewhere in emacs.

'+'/'-' enlarges or shrinks the image.  C-cC-c toggles to a flat text
representation of the text layer, built from the file rather than
djvused as the latter does not consistently place page feed control
codes.  These are needed to sync the text and image pages.  So
navigating either in text or image, and then C-cC-c gives you the
image or text on the same page.  Thus isearch works on images too.


> On the other hand adding these maparea annotations to a djvu
> document is really one of the things I wanted to achieve with my
> code. I am currently using djview for viewing the final result as it

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), or whether org-mode should be used for
notes on the document.  I can describe the attached org-mode support
if you are interested.  I seem to prefer this at the moment.

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

>
> Also, with your code I am a bit surprised that when I search a text
> string, the highlighting produced by emacs is not properly aligned
> with the underlying picture which is somewhat annoying.
>

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.

Take care,

> Roland
>
>
>
>

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

Re: Djvu mode

[Roland Winkler]

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?

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

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

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

Roland

Re: Djvu mode

[Camm Maguire]

[-- Attachment #1: Type: text/plain, Size: 4524 bytes --]

Greetings!

"Roland Winkler" <winkler@gnu.org> 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			     		    camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

[-- Attachment #2: p2 --]
[-- Type: image/vnd.djvu, Size: 14554 bytes --]

Re: Djvu mode

[Camm Maguire]

Greetings!  OK here is the alignment patch:

--- djvm2.el	2011-09-22 14:19:41.000000000 +0000
+++ djvm3.el	2011-10-03 19:57:18.000000000 +0000
@@ -630,7 +630,10 @@
 (defun djvm-box-to-rect (p c &optional perm)
   (let* ((w (caar p))(w (cdr w))(xn (pop w))(yn (pop w))(xx (pop w))(yx (pop w)) 
 	 (p (caar (last p)))(p (cdr p))(pxn (pop p))(pyn (pop p))(pxx (pop p))(pyx (pop p))
-	 (xn (- xn pxn))(xx (- xx pxn))(yn (- yn pyn))(yx (- yx pyn))(pxx (- pxx pxn))(pyx (- pyx pyn)))
+;	 (xn (- xn pxn))(yn (- yn pyn))
+;	 (xx (- xx pxn))(yx (- yx pyn))
+	 (pxx (+ pxx pxn))(pyx (+ pyx pyn))
+	 )
     `(rect
       ,(/ (float xn) pxx)
       ,(- 1.0 (/ (float yx) pyx))


Thanks again!


"Roland Winkler" <winkler@gnu.org> 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?
>
>> 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).
>
>> > 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?
>
>> 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?
>
> Roland
>
>
>
>

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

Re: Djvu mode

[Camm Maguire]

Greetings!  BTW, just to let you know I haven't forgotten and am
starting to look at your implementation now.  Needless to say, it
shows a lot more experience and professionalism with emacs lisp than
my first-ever attempt :-).

I have some questions, but I wonder if you would mind posting a short
series of keystrokes and their effects as I did to help me get a quick
grasp of the features.  I've looked at the bindings, but commands
which I think should be adding annotations seem to be producing no
effect on the 'A' *djvu* output page for example.

Then perhaps we might discuss a list of desiderata to figure out where
to go with the merged result.

Take care,

"Roland Winkler" <winkler@gnu.org> 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?
>
>> 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).
>
>> > 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?
>
>> 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?
>
> Roland
>
>
>
>

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

Re: Djvu mode

[Roland Winkler]

On Mon Oct 3 2011 Camm Maguire wrote:
> I have some questions, but I wonder if you would mind posting a short
> series of keystrokes and their effects as I did to help me get a quick
> grasp of the features.  I've looked at the bindings, but commands
> which I think should be adding annotations seem to be producing no
> effect on the 'A' *djvu* output page for example.

You get a list of useful commands from the menu bar which contains a
djvu submenu. Most of the commands for editing the djvu file work on
the region. So you specify a region, for example in
transient-mark-mode, and `h' will highlight this region.
C-x C-s saves your changes.

Roland

Re: Djvu mode

[Roland Winkler]

On Mon Oct 3 2011 Camm Maguire wrote:
> I have some questions, but I wonder if you would mind posting a short
> series of keystrokes and their effects as I did to help me get a quick
> grasp of the features.  I've looked at the bindings, but commands
> which I think should be adding annotations seem to be producing no
> effect on the 'A' *djvu* output page for example.

Oops, now I see what you mean.

The buffer *djvu* is only intended for those special cases that can
not (yet) be handled by the existing commands and tools.

A normal work flow is as follows:

To visit a djvu file use fjvu-find-file. This is the only entry
point to this package. You may want to bind this command to a key
you like. I use

  (global-set-key "\C-cd" 'djvu-find-file)

If you use this command to visit file foo.djvu, it puts you into the
(not editable) buffer foo@djvu. Normally, this buffer is all you
need.

The menu bar of this buffer lists most of the commands with their
repsective key bindings. For example, you can:

- Use `g' to go to the page you want. (Yes, this package operates on
  one page at a time. I guess that anything else would be too slow
  for large documents.)

- Use `v' to (re)start djview using the position in foo.djvu
  matching where point is in foo@djvu. (I find djview fast enough
  for this, even for larger documents.)

- To highlight a region in foo.djvu mark the corresponding region in
  foo@djvu (as usual, transient-mark-mode comes handy for this).
  Then type `h' and add a comment in the minibuffer if you like.
  Type C-x C-s to save this editing. Then type `v' to (re)start
  djview to show what you have done.

- The editing of the text, annotation and outline (bookmark) layers
  really happens in the buffers foo@djvu-t.el, foo@djvu-a.el, and
  foo@djvu-o.el. (The djvused syntax used in these buffers is so
  close to elisp that it was natural to give these buffers a
  djvu-edit-mode that is derived from emacs-lisp-mode.)

  You can check what is happening by switching to these buffers. The
  respective switching commands put point in these buffers such that
  it matches where you were in foo@djvu.

  The menu bar lists a few low-level commands available for editing
  these buffers directly. If you know the djvused syntax, sometimes
  it can also be helpful to do such editing "by hand".

- But wait: The syntax in the annotations buffer foo@djvu-a.el is a
  slightly modified djvused syntax. djvused can only highlight
  rectangles. So the highlighting of larger regions of text must use
  multiple rectangles (i.e., multiple djvused "mapareas"). To make
  editing easier, these are combined in the buffer foo@djvu-a.el.
  (Before saving these things, they are converted using the proper
  djvused syntax.)

  When you visit a djvu file, djvu-mode recognizes mapareas
  belonging together by checking that "everything else in these
  mapareas except for the rects" is the same. So if you entered a
  (unique) comment, this allows djvu-mode to combine all the
  mapareas when you visit such a file the second time. Without a
  comment, this fails!

I guess I can put this description into djvu.el.

Roland

Re: Djvu mode

[Camm Maguire]

Greetings!  Where do we stand on this project?

Take care,

"Roland Winkler" <winkler@gnu.org> writes:

> On Mon Oct 3 2011 Camm Maguire wrote:
>> I have some questions, but I wonder if you would mind posting a short
>> series of keystrokes and their effects as I did to help me get a quick
>> grasp of the features.  I've looked at the bindings, but commands
>> which I think should be adding annotations seem to be producing no
>> effect on the 'A' *djvu* output page for example.
>
> You get a list of useful commands from the menu bar which contains a
> djvu submenu. Most of the commands for editing the djvu file work on
> the region. So you specify a region, for example in
> transient-mark-mode, and `h' will highlight this region.
> C-x C-s saves your changes.
>
> Roland
>
>
>
>
>

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

Re: Djvu mode

[Roland Winkler]

On Wed Oct 12 2011 Camm Maguire wrote:
> Greetings!  Where do we stand on this project?

Correct me if I am wrong:

- Joakim's name found its way into this thread because he was
  interested in a direct support for rendering djvu files inside
  emacs. So he was a driving force for adding ImageMagick to Emacs
  24. In principle, ImageMagick can render djvu files. Yet the
  implementation does not yet work perfectly smooth, in particular
  for multipage djvu documents, where apparently ImageMagick
  attempts to put all pages into memory before it displays the first
  page.

- Camm, I am sorry, I have not yet fully understood your code which
  unfortunately doesn't have very many comments, and many variables
  names are just one-letter names which doesn't make it easier for
  me, either.

  Anyway, it appears to me that the internals of your code rely on
  djvu images being converted to ppm format so that this code can do
  a fair amount of bit shifting in order to incorporate any
  highlighting in a djvu page into the image that is displayed by
  emacs.

  In the end, this highlighting is a cool feature, which, to the
  best of my knowledge, could not be implemented by other means
  currently available within emacs.

- Finally, my code has not yet worried much about any internal
  display engine for djvu images. A major reason for this is that
  most of this code's functionality is not tied to any viewer, but
  it is is mostly operating on the text and annotation layers of
  djvu files. Then it uses the djview viewer from djvulibre which I
  find extremely fast for djvu files even if this viewer needs to be
  restarted frequently. (For this, it also helps that upon startup,
  djview can jump to the right place in the document.)

  In the meanwhile, I've also added some basic support to this code
  to display the djvu images inside emacs. So one can mark a region
  in these images that gets highlighted in the djvu file, kind of
  similar to what your code has been doing.

- Another basic difference in the design of the two djvu modes is
  the handling of the text layer. Your code extracts the complete
  text layer of multipage documents so that it becomes searchable
  from within emacs. In principle, this is a great feature. Yet I
  find it too slow if a djvu document has many pages (a major
  bottleneck being the extraction of the complete text layer upon
  startup which makes loading a larger djvu document rather slow).

  So my code works strictly on one page at a time. With this
  approach, loading large documents does not take more time than
  loading small ones. The price to pay is that the document is not
  searchable beyond the current page. Personally, I do not find that
  a big problem because djview can search djvu documents extremely
  fast.

  It might be possible to aim for the best of both worlds by
  defining a limit for the total page number of a document up to
  which the whole text layer is extracted. Beyond this limit, one
  would operate on one page at a time. I have not yet thought about
  how this can possibly be implemented.

So there are some basic differences in the design of the two modes
that make it more difficult to go for something like a simple merge.

I do not know what your thoughts have been to set up the features in
your code the way they are.

Roland