Are you sure you're looking at DejaVu Mono? All those glyphs are correct here... Can you post a screenshot of the glyphs in kcharselect or gucharmap?

Oh, this looks like the bug that happens when you didn't restart your programs. Just restart your desktop then and the problem should go away.

(In reply to comment #0)
> After I have installed DejaVu version 2.21 I have discovered some characters
> that have erroneous glyphs in "DejaVu Sans Mono".  They are the following:
> 
> 1. "U+00AC NOT SIGN", correct in DejaVu Serif and DejaVu Sans
> 2. "U+21D2 RIGHTWARDS DOUBLE ARROW", correct in DejaVu Serif and DejaVu Sans
> 3. "U+00B6 PILCROW SIGN", correct in DejaVu Serif and DejaVu Sans
> 
> 
> There might be still other errors, but I have noticed these three immediately,
> because I use very often these characters.
> 

I am using the DejaVu fonts in OpenOffice 2.3.1 and I use only Unicode encodings in all my documents.  I have never seen any problems in other fonts, so I am pretty sure that a bug in OpenOffice  or other system components is highly unlikely. The computer has been rebooted several times after the installation of the DejaVu 2.21, so a desktop restart problem is excluded.  Now I have noticed a fourth character with a wrong glyph:

4. "U+00A7 SECTION SIGN", this has the correct glyph only in DejaVu Sans.  In both Serif and Mono, it shows a German "scharfes es" instead of the section sign.  The double arrow mentioned above is double only in Serif and Sans and it is simple in Mono

However, this bug might be much more subtle than a simple code point misassignment, because I have discovered that if I use the "insert special character" dialog box and I cycle through various fonts and character blocks, when I return to one of the DejaVu fonts, the result is not consistent, i.e. sometimes I obtain a different map from code points to glyphs than the previous time when I have selected the same DejaVu font.  This does not happen with any other font, neither with the standard OpenOffice fonts nor with Microsoft fonts, regardless how many times I change the font or the character block, no desynchronization between code points and glyphs is displayed.

Using KWrite instead of OpenOffice, I have also obtained inconsistent results, i.e. even if some characters are also displayed with wrong glyphs, they are not exactly the same that are wrong in OpenOffice, so I am totally confused now.

Unfortunately, I do not have at this moment enough time to do exhaustive experiments to understand what is really happening.

(In reply to comment #3)
> I am using the DejaVu fonts in OpenOffice 2.3.1 and I use only Unicode
> encodings in all my documents.  I have never seen any problems in other fonts,
> so I am pretty sure that a bug in OpenOffice  or other system components is
> highly unlikely. The computer has been rebooted several times after the
> installation of the DejaVu 2.21, so a desktop restart problem is excluded.  

Well, you are the only person who is seeing this and it affects some basic glyphs, so the problem is likely at your end.

Please run "fc-cache -fv" once in a console window. That should rule out all caching problems.

> Now I have noticed a fourth character with a wrong glyph:
> 
> 4. "U+00A7 SECTION SIGN", this has the correct glyph only in DejaVu Sans.  In
> both Serif and Mono, it shows a German "scharfes es" instead of the section
> sign.

Again, that glyph is correct in Mono and Serif and like the other glyphs they haven't changed ever since the start of the project (except the double arrow).

> However, this bug might be much more subtle than a simple code point
> misassignment, because I have discovered that if I use the "insert special
> character" dialog box and I cycle through various fonts and character blocks,
> when I return to one of the DejaVu fonts, the result is not consistent, i.e.
> sometimes I obtain a different map from code points to glyphs than the previous
> time when I have selected the same DejaVu font.  This does not happen with any
> other font, neither with the standard OpenOffice fonts nor with Microsoft
> fonts, regardless how many times I change the font or the character block, no
> desynchronization between code points and glyphs is displayed.

Probably some caching problem then, fc-cache above should fix it...
 
> Using KWrite instead of OpenOffice, I have also obtained inconsistent results,
> i.e. even if some characters are also displayed with wrong glyphs, they are not
> exactly the same that are wrong in OpenOffice, so I am totally confused now.

> Unfortunately, I do not have at this moment enough time to do exhaustive
> experiments to understand what is really happening.

Well, I hope you have some time, since so far you're the only person who's experiencing this, so all we can do is give suggestions and ask questions to you.

The final thing you can do is to manually install the 2.21 version of DejaVu Mono from http://prdownloads.sourceforge.net/dejavu/dejavu-ttf-2.21.zip?download with KControl or whatever program Gnome uses (I think just browsing to "fonts://" in the file manager and moving the fonts in place should work), make sure to run "fc-cache -fv" after that and make sure to restart your programs as well.

If that fixes it, you've probably acquired some corrupt version from somewhere, in which case it'd be nice to know where you've got it from.

Eventually, I have seen that the bug does not exist, or, more precisely, it is not a bug of the DejaVu fonts, so I am sorry for the wrong report.  Nevertheless, I will explain what happened, because others might be confused by the same weird behaviour.  When I have installed the DejaVu fonts, this action has also updated the global font cache in /var/cache/fontconfig.  However, I had previously installed some fonts privately for my user and I was not aware of the fact that if you use the konqueror menu to install a private font, this has the side-effect of creating a local font cache hidden in ~/.fontconfig and then the local cache overrides the global cache.  When I installed DejaVu as administrator, the users' caches became invalid, so probably this lead to the strange behaviour that I have witnessed, i.e. all seemed to work OK, except that a few glyphs in Sans Mono were wrong.  Removing .fontconfig or running fc-cache as the user made the fonts behave as they should.