[vlc-devel] [PATCH] freetype: render Arabic diacritics properly

[Salah Shaaban]

You're right. This is a bit of a hack.
The problem is that freetype2 does not support OpenType Layout extension
tables

http://freetype.org/opentype/index.html

Anyway, the main issue here was readability. Misplaced base glyphs did have
an adverse effect on readability. Misplaced diacritics on the other hand do
not. They're actually barely even noticeable.

Still, if you think it's worth the trouble, I'd be more than willing to dig
deeper into it. I mean to see if it can be done any better using freetype,
and if not, to consider starting a new text rendering module using Pango or
HarfBuzz.


On Tue, Jan 6, 2015 at 9:29 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:

> Le mardi 06 janvier 2015, 13:42:08 Salah-Eddin Shaban a écrit :
> > ---
> >  modules/text_renderer/freetype.c | 27 +++++++++++++++++++++++++--
> >  1 file changed, 25 insertions(+), 2 deletions(-)
> >
> > diff --git a/modules/text_renderer/freetype.c
> > b/modules/text_renderer/freetype.c index 1670aa7..050ace6 100644
> > --- a/modules/text_renderer/freetype.c
> > +++ b/modules/text_renderer/freetype.c
> > @@ -1361,6 +1361,10 @@ static int ProcessLines( filter_t *p_filter,
> >              /* Render the part */
> >              bool b_break_line = false;
> >              int i_glyph_last = 0;
> > +            FT_Vector advance = {
> > +                .x = 0,
> > +                .y = 0,
> > +            };
> >              while( i_part_length > 0 )
> >              {
> >                  const text_style_t *p_glyph_style = pp_styles[i_index];
> > @@ -1373,6 +1377,16 @@ static int ProcessLines( filter_t *p_filter,
> >                  if( i_glyph_index == 0 && character == 0xFEFF )
> >                      goto next;
> >
> > +/* These are the most common Arabic diacritics */
> > +#define DIACRITIC( a ) ( a >= 0x064B && a <= 0x0653 )
> > +
> > +                /* Diacritics should be rendered over the preceding base
> > glyph */
> > +                if( DIACRITIC( character ) )
> > +                {
> > +                    pen.x -= advance.x;
> > +                    pen.y -= advance.y;
> > +                }
> > +
>
> As far as I know, the font is supposed to specify the relative position of
> a
> character to the previous one. That is not supposed to be hard-coded by the
> Unicode code point: combining characters do not look the same in all fonts.
>
> So this seems too simplistic to be correct.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20150107/2c3cd1a5/attachment.html>