Re: PangoPDF 1.2.3.0 released

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-06-25 at 06:38, Tony Graham wrote:
> Owen Taylor wrote at 23 Jun 2003 06:19:36 -0400:
>  > On Wed, 2003-06-18 at 11:25, Tony Graham wrote:
> ...
>  > > Download PangoPDF from http://sourceforge.net/projects/pangopdf/.
>  > 
>  > I'm being incredibly lazy here, and really should go look at the
>  > code, but why does PangoPDF have FT2/X/Xft backends? (Or, perhaps
>  > the real question is, what do you mean by "backend" here?)
> 
> PangoPDF includes all of the backends so PangoPDF can be used as a
> drop-in replacement for Pango.
> 
> To use PangoPDF instead of Pango in an application, just edit the
> application's configure.in (or configure.ac) to prefix Pango's
> pkg-config package names with 'pangopdf-', then rerun autoconf and
> configure.
> 
> That's all I did to get libgnomeprint-2.2.1.2 to use PangoPDF.
> 
> The FT2/X/Xft backends in PangoPDF are really just vanilla Pango.  I
> expect that PangoPDF will add support for the 'XSL' attributes (which
> are also CSS3 attributes) to the FT2 and Xft backends (as one person
> has done for FT2 in his version of PangoPDF), but I expect to first
> implement the 'XSL' attributes as (conditionally) part of the
> PangAttrType enumeration instead of registering them with
> pango_attr_type_register() because it's so much easier to work with
> attribute types as constants rather than variables.

While it's fine to experiment with a fork of Pango, I'd really
strongly encourage you to try to get API additions into the
main Pango. Pango really isn't a big enough of a project
to need two competing versions, and there are some definately
potential problems with what you are doing.

For example, if you modify libgnomeprint-2.2.1.2 as you
describe then you'll link against *both* Pango and PangoPDF
when you have an app that uses GTK+ and uses libgnomeprint.
And the effects of that will be unpredicatable and probably
bad.

But why is pango_attr_type_register() so hard to use? I don't
really understand the problem. Sure, it's a few more lines of
code, but that doesn't quite seem worth maintaining a fork.

Regards,
					Owen