Bug 26941

Summary:	stacked diacritics cause bizarre overstrikes in Sans Mono
Product:	DejaVu	Reporter:	Mike Maxwell <maxwell>
Component:	Mono Sans	Assignee:	Deja Vu bugs <dejavu-bugs>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	medium	CC:	jcrippen
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	PDF showing bizarre re-ordering with stacked diacritics xetex source for PDF of MonoFontTest.pdf PDF produced from MonoFontTest.xetex

Description Mike Maxwell 2010-03-07 11:17:08 UTC

Attempting to add two (stacked) diacritics to a single letter results in nearby characters overstriking each other.

For example, the sequence
  [-a<combining macron><combining acute>]
results in the two square brackets appearing to the left of the 'a' with a macron, while the combining acute and ASCII dash overstrike the second square bracket.  (This particular sequence of characters arose in a grammar we're writing, but the problem appears to be reproducible with a variety of punctuation characters and combining diacritics; the key appears to be having two diacritics.)

Similarly, the sequence
   o-a<combining macron><combining acute>o
results in a jumbled sequence which looks like 
   ooa
(yes, the second 'o' hops to the left over the 'a'!), with the dash through the middle of the second 'o', and the acute accent over the second 'o' (instead of over the 'a').  (The macron is in the correct place, over the 'a', although of course the 'a' is in the wrong place.)

I have reproduced this in the following ways:
(1) in MsWord 2003 in Vista, on-screen
(2) in a PDF produced from (1) using PDFCreator (result is slightly different: both the macron and the acute accent correctly appear over the 'a', although the 'a' is still in the wrong place)
(3) in XeTeX under Linux (here the output is if possible even more jumbled, with the acute accent appearing over the *first* 'o')

I attach a PDF of (2).

This may be related to another bug which I just submitted, on stacked diacritics using the Sans (but not Mono) font.  It may also be related to bug 18614, although the latter refers only to Cyrillic characters.

Comment 1 Mike Maxwell 2010-03-07 11:18:00 UTC

Created attachment 33837 [details]
PDF showing bizarre re-ordering with stacked diacritics

Comment 2 Mike Maxwell 2010-03-07 11:52:45 UTC

Created attachment 33838 [details]
xetex source for PDF of MonoFontTest.pdf

Note that the xetex line loading the non-monospaced version of Sans is commented out, so that this is using the monospaced version.

Comment 3 Mike Maxwell 2010-03-07 11:53:20 UTC

Created attachment 33839 [details]
PDF produced from MonoFontTest.xetex

Comment 4 Lorna 2010-05-24 08:46:27 UTC

In case this is helpful information to figuring out this problem, a user reported this about DejaVu Sans Mono:

We figured out that the collapsing effect does not happen when a precomposed version of the character is in the font.

(The following text should be rendered using DejaVu Sans Mono to be viewed correctly)


For example the sequence: x006f x0302 x0069 (o^i) renders correctly as ôi but x0254 x0302 x0069  (ɔ^i) does not: ɔ̂i


likewise x006f x030E x0069 (o"i) does not work properly: o̎I.

We found that putting any type of space after the combining character was a workaround. So for instance x006f x030E x0020 x0069  (o" i)does work: o̎ i

Of course, being required to put a space after a combining mark is totally unacceptable!

Comment 5 Ben Laenen 2010-05-24 10:18:28 UTC

(In reply to comment #4)
> (The following text should be rendered using DejaVu Sans Mono to be viewed
> correctly)

small note first: what I see on my screen is different from what you see, so it's best to attach a screenshot or describe what you see.

Renderers can have problems with combining diacritics in a monospaced font. Sometimes they're not smart enough, and sometimes they think they are smart.

In a monospaced font the glyphs of the combining diacritics need to have the same width as normal glyphs, or it wouldn't be recognized as a monospaced font. To handle them correctly, there are two things happening: anchor placement is used to put the diacritic at the correct location above the letter. Then, the space that was added by the diacritic is removed again with another opentype feature.

Renderers may fail to do one or both of these, resulting in extra spaces or the diacritic above the wrong letter. Or, what also happens is that the renderer automatically renders combining diacritics as zero-width, but doesn't disable the space removal that's done by the font. So actually two spaces are removed, resulting in the letter typed before and after the diacritic overlapping.


> For example the sequence: x006f x0302 x0069 (o^i) renders correctly as ôi but
> x0254 x0302 x0069  (ɔ^i) does not: ɔ̂i

This can be the renderer automatically substituting composed glyphs with precomposed ones (the two are equivalent so it may do that), so if that happens, it's just two letters for the renderer and it can't go wrong.

> likewise x006f x030E x0069 (o"i) does not work properly: o̎I.
> 
> We found that putting any type of space after the combining character was a
> workaround. So for instance x006f x030E x0020 x0069  (o" i)does work: o̎ i

So I assume that without the space the two letters are overlapping on your screen? Then it's your renderer doing things it shouldn't (making the diacritic with zero width together with applying the space remove defined in the font). For many fonts this would work, because they lack anchors and/or the space removal rule.

If the renderer you are using would just apply the OpenType features and nothing more, it would work.

Comment 6 nocturnaldreamer 2010-07-21 05:26:15 UTC

*** Bug 28475 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.