bug#6618: Bug was probably introduced by revision 100788

[Kenichi Handa <handa@m17n.org>]

In article <201007131239.08209.bernhard.herzog@intevation.de>, Bernhard Herzog <bernhard.herzog@intevation.de> writes:

> I'm running into the same problem and I've debugged it a little. AFAICT the 
> problem was introduced with revision 100788.  The revision immediately before 
> that works fine, but I can observer the problem with revision 100788.  The 
> ChangeLog entry for this is

> 2010-07-12  Kenichi Handa  <handa@m17n.org>

>        * font.h (enum font_property_index): New member FONT_ENTITY_INDEX.

>        * font.c (font_open_entity): Record ENTITY in FONT_OBJECT's slot
>        of FONT_ENTITY_INDEX.
>        (Ffont_get): If KEY is :otf and the font-object doesn't have the
>        property, get the property value dynamically.
>        (Ffont_put): Accept font-entity and font-object too.
>        (Ffont_get_glyhphs): Renamed from Fget_font_glyphs.  Arguments and
>        return value changed.
>        (syms_of_font): Adjusted for the above change.

> It's most likely the first change in font.c: "Record ENTITY in FONT_OBJECT's 
> slot of FONT_ENTITY_INDEX.":

Thank you for finding that problem.  The reason of recording
ENTITY in FONT-OBJECT is that we can get :otf property only
from FONT-OBJECT, but the property should be common to all
font-ojbects realized from the same ENTITY.  So, I wanted a
way to get ENTITY from FONT-OBJECT.  I've just committed a
change to cancel that recording.

As a result, we should re-caliculate :otf property of a font
whose sibling (i.e. a font-object realized from the same
entity but with different size) already know it.  But,
perhaps, that doesn't influence the redisplay speed that
match.

---
Kenichi Handa
handa@m17n.org