[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Devel] Re: OTLBuffer
From: |
786 |
Subject: |
RE: [Devel] Re: OTLBuffer |
Date: |
Mon, 19 Jul 2004 12:45:59 +0500 |
Hello,
I installed pango-1.4.0, but when I executed gedit it gave me the following
errors. Don't know much about what to do with it. Please help.
Aamir
(gedit:23040): GLib-GObject-WARNING **: specified class size for type
`PangoXftFontMap' is smaller than the parent type's `PangoFontMap' class
size
(gedit:23040): GLib-GObject-CRITICAL **: file gobject.c: line 819
(g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed
(gnome_segv:23041): GLib-GObject-WARNING **: specified class size for type
`PangoXftFontMap' is smaller than the parent type's `PangoFontMap' class
size
(gnome_segv:23041): GLib-GObject-CRITICAL **: file gobject.c: line 819
(g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed
-----Original Message-----
From: Owen Taylor [mailto:address@hidden
Sent: Saturday, July 17, 2004 8:23 PM
To: Lars Knoll
Cc: address@hidden
Subject: [Devel] Re: OTLBuffer
On Fri, 2004-07-16 at 18:26, Lars Knoll wrote:
> Hi Owen,
>
> On Friday 16 July 2004 22:34, Owen Taylor wrote:
> [....]
> > Then I modified the TT_GSUB_Apply_String() and TT_GPOS_Apply_String
> > to take a PangoOTBuffer and got rid of the separate TTO_GSUB_String
OTLBuffer, of course.
> > and TTO_GPOS_Data structures.
>
> Sounds good. I guess the OTBuffer contains positioning information as
well?
Yes. Basically, it contains two buffers of glyph data that are swapped
between when applying GSUB lookups and a single buffer where position
data is written during GPOS.
OTL_GlyphItem in_string;
OTL_GlyphItem out_string;
OTL_Position positions;
> > My hope was that doing it this way is going to be efficient and flexible
> > enough to use for Pango, for Qt, and for other consumers. What do
> > people think? Should I look at what would be required to merge this
> > into the otlayout module?
>
> Please do. I'd love to see a merge of our efforts into one codebase (ie.
> otlayout). Judging from the few minutes I looked at the code it seems as
if
> some work is still required to finish the otlayout module and make it
really
> usable. If there is need, I'd be willing to help with implementing and
> testing.
As far as I know, the otlayout module is basically in the state
described in:
http://www.freetype.org/pipermail/devel/2003-August/009608.html
That is, it's the FreeType-1.x code adapted to be standalone but not
really tested and without any of the patches from
http://people.redhat.com/otaylor/opentype-patches/
I guess the question is whether David is OK with the otlayout module
being picked up and adapted to fit the needs of Pango and Qt.
If so, I think I can find a couple of days to merge it with the current
Pango version (*), and then perhaps you can take a look at it from the
Qt perspective.
Regards,
Owen
P.S. - turns out my subscription to address@hidden was set to nomail
and the archives are not working, so if anyone else replied to
my mail just to the list I'd appreciate if they could forward
me a copy.
(*) The way I'd probably do this is start from the ftxgsub.c, etc, files
from Pango and redo the changes that David made, since the
ft1 => Pango change is huge while the ft1 => otlayout change is
small.
- RE: [Devel] Re: OTLBuffer,
786 <=