[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6618: Bug was probably introduced by revision 100788
From: |
Kenichi Handa |
Subject: |
bug#6618: Bug was probably introduced by revision 100788 |
Date: |
Wed, 14 Jul 2010 13:01:51 +0900 |
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