Re: [patch] Rework of Pango integration

[Jody Goldberg <jody gnome org>]

On Wed, Jun 09, 2004 at 10:50:38AM -0400, Owen Taylor wrote:
> > 
> > In the longer term do you see any value in maintaining GnomeFont vs
> > PangoFont ? or would you rather just see us move to a cairo backend ?
> 
> I was thinking of this in terms of a stop-gap measure for the next
> year or so until we move to Cairo. With this patch, if you are using the
> new APIs, GnomeFont is just an implementation detail.  Getting rid of
> GnomeFont as an implementation detail would take more work; you'd
> have to extend gnome-glyphlist and the metafile format. And since  you
> need GnomeFont for backwards compatibility anyways, it doesn't really
> seem worthwhile to me. 

Sounds like we're on the same page.

> > It will depend on the pango release schedule.  If you still plan to
> > release a new stable version before gnome-2.8 then it seems
> > unnecessary.  This code isn't going to be backported to gp-2.6.
> 
> Yeah, I'm still planning on doing a new Pango for gnome-2.8.
> (Less necessary than when I thought I'd need a bunch of Pango changes
> to get this working, but easier to reduce the number of different
> combinations.)

Then I don't see a need to provide backwards compat shims.

> > > + * (other than pure translations) you should call this function.
> > > + * You also need to call pango_layout_context_changed() for any
> > > + * #PangoLayout objects that exit for the #PangoContext.
> > 
> > 'Change the transformation matrix' ?
> > I'll assume that is not necessary for translation.
> 
> That was what I meant by "(other than pure translations)": I'm not
> really how to word it better.

Sigh, time to get glasses.  That's fine.

> > > +		switch (attr->klass->type) {
> > > +		case PANGO_ATTR_UNDERLINE:
> > > +		case PANGO_ATTR_STRIKETHROUGH:
> > > +		case PANGO_ATTR_FOREGROUND:
> > > +		case PANGO_ATTR_BACKGROUND:
> > > +		case PANGO_ATTR_SHAPE:
> > > +		case PANGO_ATTR_RISE:
> > > +		default:
> > Where is ATTR_SCALE handled ?
> 
> There are a lot of things that aren't handled here; the attributes that
> are handled here are the attributes that affect rendering *beyond*
> the choice of PangoFont and glyphs. ATTR_SCALE will get bundled into
> the PangoFont.

I figured as much but after mis-interpreting PangoAttr _twice_ it
seemed prudent to double check.
 
> > > +	PangoLayoutIter *iter;
> > > +	
> > > +	g_return_if_fail (GNOME_IS_PRINT_CONTEXT (gpc));
> > > +	g_return_if_fail (PANGO_IS_LAYOUT (layout));
> > 
> > A sanity check to ensure that the layout is associated with a 
> > context that has a PangoFT2FontMap seems like a good idea.  Can we
> > get more specific to ensure that it's really one of the gnome-print
> > created fontmaps with hinting disabled ?
> 
> Hmm, unfortunately, there is no pango_context_get_fontmap(). If
> there was such
>
>  PANGO_IS_FC_FONTMAP (pango_context_get_fontmap
> (pango_layout_get_context (layout));
> 
> would be sufficient to check whether things would "basically work".
> 
> Though there certainly is an argument that "basically working" is 
> pretty evil. I spent quite a bit of time trying to figure out why
> layout was slightly wrong for my GtkHTML patch before realizing that
> GtkHTML was using the wrong PangoContext.
> 
> So, there might be an advantage of doing something like setting
> a magic GObject data key on the PangoContexts we create and requiring
> it to be there.

That is exactly the sort of problem that worries me.  It's entirely
too simple a mistake to make.  Even the PANGO_IS_FC_FONTMAP (...)
'basicly working' approach doesn't seem safe enough.   Let's go with
the magic qdata.
 
> But the question that then comes up is gnome_print_pango_layout_print();

> Or by having public wrappers for private functions we could make that
> function still work with random contexts, and require our contexts
> for the new API. Does that sound reasonable?

That is the cleanest solution.  Although I will deprecate it.
A somewhat hollow gesture but it should help avoid confusion as to
which api is prefered.