about libass behavior regarding some aspects of glyph rendering

[GoogleCodeExporter]

to me, it looks like windows' font engine discards some special glyphs when 
rendering fonts and uses its own ones. or even adds them automatically at 
render time if they are missing from the font's glyph table.
Such characters are unicode control characters. In my case (Arabic scripts), 
most of the arabic fonts do not include for example, U+FFEF, which is for 
no-break-space-width-joiner. in vsfilter, the subtitles are rendered alright, 
but in libass they are not. because libass takes characters like this directly 
from the font. if these characters do not exist in the font, an empty square is 
rendered instead. 

so, is it possible for libass to behave like vsfilter in this case?
if there is anything I could help with to overcome this issue, i'm ready to 
help. 
Thanks!

Original issue reported on code.google.com by hsd2...@gmail.com on 8 Jun 2012 at 1:27

Attachments:

• test.ass
• fonts.zip
• test.png

[GoogleCodeExporter]

libass includes a check for such characters, but that list obviously wasn't 
complete. However, HarfBuzz removes them now too, and has a much more complete 
list. The attached image was rendered with up to date HarfBuzz. Can you confirm 
that it is correct now? There are font selection issues, but that's something 
different.

Original comment by g...@chown.ath.cx on 24 Jul 2012 at 10:41

Attachments:

• test.png

[GoogleCodeExporter]

Original comment by g...@chown.ath.cx on 1 Oct 2012 at 2:42

• Changed state: Fixed