Re: PangoPDF 1.2.3.0 released



Owen Taylor wrote at 25 Jun 2003 11:22:05 -0400:
...
 > 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.

I don't want to fork Pango, and, as Matthis Clasen posted, the goal of
PangoPDF is to make itself obsolete.

 > 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.

I know that.  I still don't have a good solution to the fact that
PangoPDF's GNOME Print backend depends on GNOME Print which depends on
Pango.  The effect of that will be unpredictable and probably bad too.
As such, I don't think that part's ready to come into the fold.

 > 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.

That's not why I'm maintaining a fork.  I talked about
pango_attr_type_register() when explaining what I would do if I were
to add extra attributes to the FT2 and Xft backends.

I am interested in seeing the fruits of what you wrote about in the
"Merging code between Xft and FT2 shapers" thread on April 14 since
that would make it easier to add FreeType-using backends to Pango.

I will submit some enhancement requests.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]