Bug 18614 - Mono Sans: accent with Russian letters causes letters collapsing
Mono Sans: accent with Russian letters causes letters collapsing
Status: NEW
Product: DejaVu
Classification: Unclassified
Component: Mono Sans
unspecified
Other All
: medium critical
Assigned To: Deja Vu bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-18 16:57 UTC by derbeth.fora
Modified: 2013-12-04 10:50 UTC (History)
0 users

See Also:


Attachments
screenshot from Windows XP (32.30 KB, image/png)
2008-11-19 07:51 UTC, derbeth.fora
Details
change after upgrading usp10.dll (5.10 KB, image/png)
2008-11-19 08:17 UTC, derbeth.fora
Details
View of snapshot from 11/20 with new usp10.dll (4.89 KB, image/png)
2008-11-20 17:46 UTC, derbeth.fora
Details
Capital letter are screwed (while small are okay) (83.21 KB, image/png)
2013-03-14 03:04 UTC, soshial
Details

Note You need to log in before you can comment on or make changes to this bug.
Description derbeth.fora 2008-11-18 16:57:57 UTC
If you use accent sign in Mono Sans, surrounding letters collapse into one place, making them unable to be selected or most imporant - seen.

Examples:
инжене́р
программи́ст

Compare with words without accent:
инженер
программист

Tested on Windows XP, Opera web browser and Microsoft Word, but I remember such behaviour also on Ubuntu Linux.
Comment 1 Ben Laenen 2008-11-19 04:02:21 UTC
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.
Comment 2 Ben Laenen 2008-11-19 05:11:15 UTC
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.
Comment 3 derbeth.fora 2008-11-19 07:51:53 UTC
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
Comment 4 derbeth.fora 2008-11-19 07:55:34 UTC
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.
Comment 5 derbeth.fora 2008-11-19 08:15:06 UTC
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).
Comment 6 derbeth.fora 2008-11-19 08:17:06 UTC
Created attachment 20450 [details]
change after upgrading usp10.dll

Firefox 3.0.4 on Windows XP after supplying new version of usp10.dll
Comment 7 Ben Laenen 2008-11-19 08:19:21 UTC
(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...
Comment 8 Ben Laenen 2008-11-19 08:23:57 UTC
(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).
Comment 9 derbeth.fora 2008-11-20 17:46:52 UTC
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
Comment 10 derbeth.fora 2008-11-20 17:48:07 UTC
(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?

Comment 11 Ben Laenen 2008-11-21 03:56:35 UTC
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...).
Comment 12 Grundik 2011-12-22 04:32:17 UTC
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)
Comment 13 soshial 2013-03-14 02:58:18 UTC
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.
Comment 14 soshial 2013-03-14 03:04:50 UTC
Created attachment 76506 [details]
Capital letter are screwed (while small are okay)

added promised screenshot
Comment 15 Tae-Wong Seo 2013-12-04 10:50:17 UTC
The link that you gave in the third comment appears to be working. Older account (386sky) is also available.