Re: [xmlroff] xmlroff with Pango 1.5.1 and libgnomeprint 2.7.1

[Tony G. <Ton...@Su...>]

Steve Cheng <g3c...@cd...> wrote at Fri, 27 Aug 2004 00:05:36 -0400:
> On Thu, 26 Aug 2004, Tony Graham wrote:
> > I am considering making a new package for the new PangoPDF because the
> > name no longer really applies and because removing all the old source
> > files will still leave their directories in the CVS tree for no good
> > reason.  PangoPDF could also do with a new description in
> > pangopdf.pc.in.  Any ideas?
> 
> Why not just distribute a patch against mainstream Pango?
> (and also patch against libgnomeprint for the XSL attributes, later)
> It makes it easier to update for new changes in the mainstream version,
> and we're not going to fork this thing forever, right?

You obviously have more faith than I do in my ability to keep up with
new releases of Pango.  Since the previous PangoPDF release is based
on Pango 1.2.3 and the current stable Pango is 1.4.* and development
Pango is 1.5.1, it doesn't look good for my being able to keep up.

Even if other people step forward to share the work (yes, please do),
you're implying that anyone interested in the latest xmlroff is going
to have to be capable of updating and patching their Pango
distribution.

No, we are not going to fork this thing forever.

Instead of hypothesising about either copying or patching, I suggest
that we look at the state of the current XSL attributes and work out
which ones are sufficiently cooked to be worth submitting to Pango as
enhancement requests.

The alignment-adjust, alignment-baseline, reset-size, and
dominant-baseline don't really work anymore, I think.  They used to
work with early versions of Pango before Pango moved to using
fontconfig.  To implement them properly will require hacking FreeType2
to support the relevant OpenType tables and then implementing support
for that support in Pango.

The "callback" attribute doesn't correspond to a single XSL property.
It's a way of getting fo:external-graphic to work.  Actually, it's a
way so simply handle multiple fo:external-graphic in one fo:block with
a minimum of housekeeping.

An fo:external-graphic maps to a "shape" PangoAttribute of the
required shape and a "callback" attribute.  PangoPDF lays out the
necessary space for the fo:external-graphic, and when it's time to
render, PangoPDF calls the callback to do the actual work.

If you look closely, you'll see the called function is still called
fo_external_graphic_callback_test.  On the xmlroff side,
fo:external-graphic really should create some subtype of FoArea, and
the callback should be to the FoArea subtype object.

Implementing graphic support as a callback seemed simpler than
rendering the layout and then later walking the PangoLayout structures
to work out where to render the graphics, which is what the GTK widget
demo program appeared to be doing.

The keep-*.within-line properties, line-height, and
line-stacking-strategy properties should be cooked enough that patches
could be made and submitted as Pango enhancement requests.

> > Please test out xmlroff and let the list know how you get on.
> 
> Let me guess, you are using old versions of the autotools :)
> Or for whatever reason, mine doesn't generate the libtool and ltmain.sh
> scripts --- no matter, I copied them over from the release version
> of pangopdf and it builds.  Tomorrow I will check out how it works.

Did you start by running autogen.sh?

> Thanks for all your work Tony,

That's okay, but I really need to get back to my day job now.

Regards,


Tony.