xmlroff-list

[xmlroff] xmlroff with Pango 1.5.1 and libgnomeprint 2.7.1

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

The xmlroff in CVS now works with Pango 1.5.1 and libgnomeprint 2.7.1.

"Works" means that it runs 'xmlroff.fo' with only one warning.  I
haven't tried it with multi-page output yet, but I do expect it to
fail.

You will need a new PangoPDF from it's CVS repository.  The useful
part of PangoPDF is now down to pango-xsl-attributes.[ch].  All the
old PangoPDF files are still in CVS just because I haven't bothered to
remove them.

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?

Using the extra attributes in pango-xsl-attributes won't do anything
to your formatted output because the gnome_print_render_layout()
function doesn't know anything about them.  I haven't looked at what
it will take to get them working again.

Reducing PangoPDF was possible because of recent changes in Pango and
GNOME Print, but getting the extra XSL properties to work again is
likely going to require modified versions of some Pango files again.

Please test out xmlroff and let the list know how you get on.

Regards,


Tony.

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

[Steve C. <g3c...@cd...>]

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?

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

Thanks for all your work Tony,

-- 
Steve Cheng
鄭君博

docbook2X: <URL:http://docbook2x.sourceforge.net/>

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

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

Leonard Rosenthol <leo...@pd...> wrote at Fri, 27 Aug 2004 08:39:16 -0400:
> At 06:21 AM 8/27/2004, Tony Graham wrote:
> >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.
> 
>          There is already work going on between Pango, FreeType and Qt for 
> the creation of a new "underpinning" library to FreeType which is called 
> OTLayout - which will handle the low level aspects of OpenType font 
> management (table parsing, validation, etc.) that Pango (etc.) can then use.
> 
>          Work has already begun, code in is FT's CVS tree, and discussions 
> take place on the FT developer's mailing list.

I read the thread starting at [1], and it looks to me like they're
just beginning to agree to do it and that none of the three otlayout
[2] in FT's CVS tree is joint work (yet).

That thread does show me that Pango forks FreeType [3] as well as
using it.  While it would be nice to speculate about the possibility
of getting baseline table support into the Pango OT code before Pango
OT support is merged into an eventual OTLayout, I can tell you now
that I don't have time to do it myself.

So it looks like xmlroff should drop dominant-baseline, etc., until
Pango uses an OTLayout and OTLayout supports parsing of baseline
tables.

Regards,


Tony.

[1] http://www.freetype.org/pipermail/devel/2004-August/010912.html
[2] http://www.freetype.org/pipermail/devel/2004-August/010925.html
[3] http://www.freetype.org/pipermail/devel/2004-August/010937.html

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.

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

[Leonard R. <leo...@pd...>]

At 06:21 AM 8/27/2004, Tony Graham wrote:
>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.

         There is already work going on between Pango, FreeType and Qt for 
the creation of a new "underpinning" library to FreeType which is called 
OTLayout - which will handle the low level aspects of OpenType font 
management (table parsing, validation, etc.) that Pango (etc.) can then use.

         Work has already begun, code in is FT's CVS tree, and discussions 
take place on the FT developer's mailing list.


Leonard

---------------------------------------------------------------------------
Leonard Rosenthol                            <mailto:leo...@pd...>
Chief Technical Officer                      <http://www.pdfsages.com>
PDF Sages, Inc.                              215-938-7080 (voice)
                                              215-938-0880 (fax)