Bug 18614

Could you post a screenshot?

In Linux I have two behaviours strangely enough: in KDE I get accents on е and и (which looks correct for me with my limited knowledge of Cyrillic) while in Pango it's on the letters behind them (р and с). My first guess is that the latter is caused by having no anchors on the letters to attach the accents to. But that doesn't cause your problem.

Now, there are some things going on behind the scenes for combining diacritics: because it's a monospaced font we have to make the combining diacritics the same width as normal letters (or it wouldn't be recognized as monospaced anymore). But combining diacritics have to be zero-width, and some opentype rule does that: it removes the width from the diacritic (to be precise: it says that the next letter has to be rendered X pixels left of where it would be without the rule, with X the width of a letter in the font).

However, this goes terribly wrong if the font renderer "thinks" it is smarter than the font (after all, that rule can't be found in a lot of fonts, given the sparcity of monospaced fonts that support combining diacritics, even if it has to be there to be correct), so the renderer says "combining diacritic doesn't look zero width, I'll do that for you", but it then forgets to not apply the opentype rule that already corrects the width. Result: the next letter is moved left twice the letter width and therefore coincides with the letter that has the accent on it.

So, I'm quite sure that the problem here lies with the renderer in Microsoft.

I've just added anchors to most basic Cyrillic glyphs so now with Pango based programs the accent appears on the correct letter now.

Of course, it probably doesn't help you on Windows, but you can test it out if there are new snapshots available at http://dejavu.sourceforge.net/snapshots/ tomorrow (with 20081120 date), you never know...

Something different you might try is to update your Uniscribe to see if it's handled better with that, but you'll have to google around to know how to do that and where to find it.

Created attachment 20444 [details]
screenshot from Windows XP

screenshot from Windows XP showing test page (available on http://home.autocom.pl/cubic/temp/font.html) in different browsers and WordPad editor

I need to clarify things a bit: on my Ubuntu Linux everything works well. I've tested on KOffice/OpenOffice.org/AbiWord plus Opera/Firefox/Konqueror (tested in KDE, not in GNOME).

But on Windows XP all browsers render test page incorrectly, even Apple's Safari (I thought it has its own mechanisms for font rendering).

Perhaps I'll try to upgrade Uniscribe.

Ok, I have downloaded new version (1.0473) from http://www.unimm.org/cms/node/13 and in result font is not displayed correctly, but at least in the same way as in Pango (as far as I understand).

Created attachment 20450 [details]
change after upgrading usp10.dll

Firefox 3.0.4 on Windows XP after supplying new version of usp10.dll

(In reply to comment #4)
> But on Windows XP all browsers render test page incorrectly, even Apple's
> Safari (I thought it has its own mechanisms for font rendering).

Hmm, I thought that as well. You can see the other ones are rendered exactly the same since they all use Uniscribe. I'd have thought that Apple would have a better record when it comes to supporting opentype...

If you test the snapshot from tomorrow I think you'll see a slight change btw: the accent will be on the correct glyph. I don't think it'll do anything on the overlap.

Basically the issue here is that renderers think they're smart and adjust like they think it would work, but don't take into account that if they do that they have to discard the method used by the font to let it render correct by renderers that don't play smart... So if we let it render correct with Windows XP, the other ones will render incorrectly...

(In reply to comment #6)
> Created an attachment (id=20450) [details]
> change after upgrading usp10.dll
> 
> Firefox 3.0.4 on Windows XP after supplying new version of usp10.dll

Ok, that looks interesting (although I can't explain the placement of the accent there, but heck). But that may mean that with tomorrow's snapshot it could render correctly (or you can test out now if you have the necessary software installed to build it yourself from SVN).

Created attachment 20483 [details]
View of snapshot from 11/20 with new usp10.dll

DejaVu Sans Mono from 2008-11-20 snapshot viewed on Windows XP in Firefox 3.0.4 with new version of usp10.dll

(In reply to comment #8)

> Ok, that looks interesting (although I can't explain the placement of the
> accent there, but heck). But that may mean that with tomorrow's snapshot it
> could render correctly (or you can test out now if you have the necessary
> software installed to build it yourself from SVN).

A bit better, but still not correct. Does it look correct on GNOME now?

I think the result we see now comes from Windows not making use of the mark anchors for diacritic placement... If that's the case, then we can't do nothing about that, other than making fonts that need it and thus persuading renderer makers to use it :-)

Gnome and KDE (3 and 4) render it correctly, since they use the mark anchors. OpenOffice.org which also has issues when it comes to diacritics also has problems with this string (can't remember if that's going to change, but so far they said they don't want to handle it right since it might increase the time needed to render text...).

Still actual in java applications (e.g. Netbeans) in Debian Linux (sid).

$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Small letters look okay, but for capital letters the bug still persists.

Tested in LibreOffice 3.6 on Windows and in Konsole on openSUSE 12.3.

Attaching a screenshot.

Created attachment 76506 [details]
Capital letter are screwed (while small are okay)

added promised screenshot

The link that you gave in the third comment appears to be working. Older account (386sky) is also available.