Bug 26940

Created attachment 33836 [details]
PDF showing a+macron+acute accent

Awkward, because those glyphs all have the proper mark anchors so they do stack instead of overlap, and over here in Linux with Gnome and KDE it works properly. I have no idea what could be the problem here, other than all those programs somehow discarding the opentype tables. But don't ask me why, I thought XeTeX worked perfectly with those mark anchors...

(In reply to comment #2)
> Awkward, because those glyphs all have the proper mark anchors so they do stack
> instead of overlap, and over here in Linux with Gnome and KDE it works
> properly. I have no idea what could be the problem here, other than all those
> programs somehow discarding the opentype tables. But don't ask me why, I
> thought XeTeX worked perfectly with those mark anchors...

Odd also, because I would have thought this sort of thing would have shown up and been fixed long ago.

Could I have installed them wrong?  I just unzipped and untarred them in one of our font directories, where fc-list sees them.  I see there's a subdir called 'fontconfig' with six .conf files.  Is there something I should do with that directory, to make fontconfig use it?  Or is it enough that it just be there as a sister dir to the ttf dir?

(In reply to comment #3)
> Odd also, because I would have thought this sort of thing would have shown up
> and been fixed long ago.

Because it was fixed a long time ago by adding the mark anchors to get them stacked. And it worked ever since...

> Could I have installed them wrong?  I just unzipped and untarred them in one of
> our font directories, where fc-list sees them.  I see there's a subdir called
> 'fontconfig' with six .conf files.  Is there something I should do with that
> directory, to make fontconfig use it?  Or is it enough that it just be there as
> a sister dir to the ttf dir?

The easiest way in Linux is to just use the font installing methods of KDE or Gnome so you don't have to do it manually. I even don't know how to do that exactly anymore... There was always the problem of updating the caches.

But since you're using the fonts you should have done it correctly.

Can you also upload the pdf's made with XeTeX?

Created attachment 33840 [details]
xetex source for PDF of NonMonoFontTest.pdf

Note that the line loading Sans Mono has been commented out, so this produces the non-monospace font.

The Arabic characters are OK (I think).

Created attachment 33841 [details]
PDF produced from NonMonoFontTest.xetex

(In reply to comment #4)
> Can you also upload the pdf's made with XeTeX?

Done 

Xelatex here also fails to stack those, but passing that tex file to
pango-view, specifying either DejaVu Serif or DejaVu Sans as the font,
displays the diacritics stacked.  DejaVu Sans Mono still fails, though.

XeTeX uses icu for gsub,gpos, et al; perphaps there is a bug in icu?

(In reply to comment #8)
> Xelatex here also fails to stack those, but passing that tex file to
> pango-view, specifying either DejaVu Serif or DejaVu Sans as the font,
> displays the diacritics stacked.  DejaVu Sans Mono still fails, though.


Mono doesn't have the mark to mark anchors that are needed for properly stacking, so it's not really surprising that it fails on pango-view (even though one could always say that pango should have some default behaviour to stack them anyway if the font doesn't tell how).

But it does show that the mark to mark anchors from Sans and Serif do work for pango at least.


> XeTeX uses icu for gsub,gpos, et al; perphaps there is a bug in icu?

OpenOffice.org also uses ICU and it also fails. But I don't think that MS Word uses ICU :-)

I'm currently thinking more about some problem with the language/script tags attached to the opentype features (about the only thing I can think of which may give different behaviour in pango and icu), even though I don't really see anything wrong with it in the font.

I'm coming back to this problem six years later.  It still doesn't work, although the nature of the problem has changed.  Before, the two stacked diacritics came out in the PDF superimposed on each other (as shown in the PDF I uploaded in 2010).  Now, the first diacritic appears over the correct base character, but the second diacritic in the stack appears over the next base character to its right, as shown in the PDF I'm about to upload.  (The new PDF was produced from the original .xetex file that I uploaded back in 2010.)

The proper result would be that the two stacked diacritics would appear over the same base character, with the second of the two appearing a little above the first one.

I've verified that stacked diacritics stack correctly with another font (CharisSIL), so this is not a problem with XeLaTeX.

BTW, I'm now using v2.36 of the DejaVu fonts; before I was using v2.30.

Created attachment 125259 [details]
PDF produced using v2.36; see my comment 22 July 2016

This is the PDF I promised in my earlier post this day (I guess I should have attached it to that post, apologies...).  This PDF is produced from the original NonMonoFontTest.xetex file using the version of XeLaTeX in TeXLive 2016, and v2.36 of the DejaVu fonts.  The source has a base char, a combining macron, and a combining acute accent, in that order.  The correct appearance in the PDF would be these three characters in a vertical stack, with the base char at the bottom of the stack, the macron in the middle, and the acute at the top, with a tiny bit of vertical space between each.  The actual appearance is with the base char and the macron in the stack, and the acute over the next base character to the right.