[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21846: 25.0.50; emacs hebrew script bidi nikud rendering bug
From: |
Benjamin Riefenstahl |
Subject: |
bug#21846: 25.0.50; emacs hebrew script bidi nikud rendering bug |
Date: |
Fri, 11 Dec 2015 00:15:55 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
Benjamin Riefenstahl writes:
> With m17n-edit, the text is run through COMBINING.flt (according to
> MDEBUG_FLT=3), with Emacs, no FLT is triggered at all. Which makes me
> suspect that Emacs does not use m17n for this font at all (?).
So I armed myself with a debugger and tried to trace what happens. My
command line is
gdb --args ./emacs -Q --eval '(set-default-font "Aharoni CLM 20")' test.txt
The first wrong turn is in hebrew-shape-gstring
(lisp/language/hebrew.el). This only calls the font-based shaping
function, if the font indicates that it supports OpenType (OTF) features
for Hebrew. As a fallback, limited shaping is done in ELisp by looking
up precomposed characters.
When I stub this out for further testing, we get until ftfont_shape
(ftfont.c). That function checks if there is any OTF support in the
font and only when it is there, it calls libm17n. The next function in
the chain (ftfont_shape_by_flt) actually uses that OTF object that we
did not get in ftfont_shape to pass some font information.
There seem to be three possibilities:
* Don't fix, PostScript fonts are just not supported here. Maybe instead
"Aharoni CLM" could be converted to OpenType.
* Try to support non-OTF fonts in ftfont_shape_by_flt. See how the example
programs for libm17n do it.
* Reimplement what COMBINING.flt does in hebrew.el.