xmlroff-list — xmlroff XSL formatter discussion list

Re: [xmlroff] XSL-FO question

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

Steve Cheng <g3c...@cd...> wrote at Tue, 31 Aug 2004 21:23:57 -0400:
> This is really a general question about the XSL-FO spec,
> but since Tony Graham is listed as a contributor there
> maybe I can coax him into answering here :)

I'm listed as a contributor for my work on the XSL 1.0 test suite when
the XSL spec was a Candidate Recommendation.  I am no longer on the
W3C XSL FO subgroup.

Questions like this should go to the xsl...@w3... list.

> How are property value specifications supposed to be
> parsed in XSL-FO?  One place it says that they
> can be "expressions" (e.g. "from-parent()" etc.),
> but in list of properties you often have something
> like this (for font-family):
> 
> [[ <family-name> | <generic-family> ],]* [<family-name> | <generic-family>] | inherit
> 
> which seems to be incompatible with the expression
> grammar.  Is the whole thing taken as a string,
> and therefore one is forced to write:
> 
> font-family="'Verdana, Arial, ...'"
> 
> (note the double-quoting) which seems very awkward
> and certainly not how CSS is written.
> If not, how would one use expressions in the font-family
> specification?

But the text after the box for font-family says:

<string>

   The names are syntatically expressed as strings.

I would say that since the property is taken from CSS, it should be
parsed like CSS2, but I don't speak for the XSL FO subgroup.

There is, of course, the counter-example of <uri-specification> which
in XSL requires more quoting than most people expect.

Regards,


Tony.

[xmlroff] XSL-FO question

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

This is really a general question about the XSL-FO spec,
but since Tony Graham is listed as a contributor there
maybe I can coax him into answering here :)

How are property value specifications supposed to be
parsed in XSL-FO?  One place it says that they
can be "expressions" (e.g. "from-parent()" etc.),
but in list of properties you often have something
like this (for font-family):

[[ <family-name> | <generic-family> ],]* [<family-name> | <generic-family>] | inherit

which seems to be incompatible with the expression
grammar.  Is the whole thing taken as a string,
and therefore one is forced to write:

font-family="'Verdana, Arial, ...'"

(note the double-quoting) which seems very awkward
and certainly not how CSS is written.
If not, how would one use expressions in the font-family
specification?

-- 
Steve Cheng
&#x912D;&#x541B;&#x535A;

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

Re: [xmlroff] Re: xmlroff website help wanted

[Stefan S. <se...@sy...>]

Stefan Seefeld wrote:

> uh, I thought that was part of the patch I sent (just two dummy
> pages that need to be filled with some general info). Here they
> are again.

Er, *here* they are. Sorry...

Stefan

Re: [xmlroff] Re: xmlroff website help wanted

[Stefan S. <se...@sy...>]

Tony Graham wrote:

 > I started to apply your patch but ran into problems because I don't
 > have a copy of the XSL stylesheets on this machine.
 >
 > This reinforces the idea that the website stuff needs to be set up so
 > that anybody can sucessfully produce HTML from the CVS files.

yes. And, even though I do have the website xsl stuff on my machine,
compiling your website took a *lot* of time. It appears processing
the files requires some ULR lookup anyways (I locally added --novalid
to the xsltproc to avoid the dtd download, but that didn't change anything).

 >>By the way, the wiki seems a bit broken, at least I get a warning about
 >>'Use of undefined constant RECENT_CHANGES' for all wiki pages (the status
 >>page, in particular).
 >
 >
 > It's always been broken that way.  I don't know enough PHP to fix it.

neither do I (and the few times I looked into php code convinced me that
this isn't something I ever want to get more exposure ;-)

Anyways, with proper rss support may be we don't need that php any more.
Speaking of which, it appears the website xsl from Norm supports rss 1.0
right now, while sf.net generates rss 2.0 feeds. That means I'll have
to rewrite the appropriate templates, which isn't a big deal.

 > RSS is automatically available for projects.  See
 > https://sourceforge.net/export/rss2_project.php?group_id=73148 for the
 > xmlroff RSS feeds.

Right. It wasn't available when I first checked (I got an error message),
but now it's working fine. I'll work on a patch to integrate these data
into the website.

 > P.S. Am I missing 'documentation.xml' and 'development.xml'?

uh, I thought that was part of the patch I sent (just two dummy
pages that need to be filled with some general info). Here they
are again. They need to be filled with some text, which I can't
really provide as of now as I don't know enough about the project.

Regards,
		Stefan

Re: [xmlroff] Re: xmlroff website help wanted

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

Stefan Seefeld <se...@sy...> wrote at Thu, 26 Aug 2004 13:48:08 -0400:
> >>Well, the first thing to do would be to simply rearrange the toc
> >>(i.e. the menu). The first day I looked at the site I wondered how
> >>to access the mailing list...
> 
> Attached is a little patch that provides a reorganized menu. It's actually
> more a direction than a final result. I notably regrouped some items into
> a 'documentation' item, and others into 'development' (documentation containing
> everything from user manual to API reference, development everything from
> status to task tracker). Thus there are much less items on the main page,
> but those that are there are of general use.

I started to apply your patch but ran into problems because I don't
have a copy of the XSL stylesheets on this machine.

This reinforces the idea that the website stuff needs to be set up so
that anybody can sucessfully produce HTML from the CVS files.

> By the way, the wiki seems a bit broken, at least I get a warning about
> 'Use of undefined constant RECENT_CHANGES' for all wiki pages (the status
> page, in particular).

It's always been broken that way.  I don't know enough PHP to fix it.

I expect that there's a newer version (a much newer version) of the
Wiki software available by now.

> >>The second step would be to integrate said rss feeds and thus get
> >>rid of the redundant data.
> 
> ...and to do that the rss feeds need to be activated first. As soon
> as they are, I can work on some xslt templates to put some 'news headers'
> etc. at appropriate places.

RSS is automatically available for projects.  See
https://sourceforge.net/export/rss2_project.php?group_id=73148 for the
xmlroff RSS feeds.

Regards,


Tony.

P.S. Am I missing 'documentation.xml' and 'development.xml'?

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

[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)

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

[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] Re: xmlroff website help wanted

[Stefan S. <se...@sy...>]

Tony Graham wrote:

> Stefan Seefeld <se...@sy...> wrote at Sat, 21 Aug 2004 19:00:24 -0400:

>>>What suggestions do you have?
>>
>>Well, the first thing to do would be to simply rearrange the toc
>>(i.e. the menu). The first day I looked at the site I wondered how
>>to access the mailing list...

Attached is a little patch that provides a reorganized menu. It's actually
more a direction than a final result. I notably regrouped some items into
a 'documentation' item, and others into 'development' (documentation containing
everything from user manual to API reference, development everything from
status to task tracker). Thus there are much less items on the main page,
but those that are there are of general use.

By the way, the wiki seems a bit broken, at least I get a warning about
'Use of undefined constant RECENT_CHANGES' for all wiki pages (the status
page, in particular).

>>The second step would be to integrate said rss feeds and thus get
>>rid of the redundant data.

...and to do that the rss feeds need to be activated first. As soon
as they are, I can work on some xslt templates to put some 'news headers'
etc. at appropriate places.

Regards,
		Stefan

[xmlroff] [ANN] Fabio Arciniegas is xmlroff developer

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

I'm pleased to announce that Fabio Arciniegas is now a developer on
the xmlroff project.  Fabio has been a developer for PangoPDF for a
while now, so this is an expansion of his interests rather than
something new.

Fabio announced his interest in using xmlroff with the Universal
Business Language when he introduced himself to this list in June.  He
contributed the new 'INSTALL' instructions for xmlroff 0.2.8, and I
look forward to more contributions in the future.

Regards,


Tony.

[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] PANGOPDF: Changing library link file name.

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

N O S P A M <ti...@ya...> wrote at Tue, 24 Aug 2004 23:00:57 -0700 (PDT):
> Hello

Welcome to the xmlroff-list.  If you wish to continue to discuss
xmlroff, please subscribe to the list.

> I want to ask about conflict of link filename between
> Pango and PangoPDF.
> 
> I had installed Pango 1.5 and the latest PangoPDF.
> When I try to compile XMLRoff, I found "Undefined
> reference" error.

xmlroff does not yet work with Pango 1.5.  Several people are working
on it.

For now, you can no more replace Pango 1.5 with PangoPDF than you
could replace Pango 1.5 with Pango 1.2.3 (which is what the current
PangoPDF is based on).

PangoPDF installs everything in 'pangopdf' directories just so there's
no conflict with the core Pango.  I hate to have to say it, but I can
build xmlroff without problems.  Do you look in the new 'INSTALL'
instructions in the xmlroff distribution?

When I'm building xmlroff and PangoPDF, I install PangoPDF in
/usr/local and set LD_LIBRARY_PATH to "/usr/local:/usr" so the files
in /usr/local are used in preference to any in /usr.

I also set PKG_CONFIG_PATH to
"/usr/local/lib/pkgconfig:/usr/lib/pkgconfig" so pkg-config also looks
in /usr/local first.

If you still can't get xmlroff to compile, then you should post an
excerpt of your error messages.  You should also pay careful attention
to the output when you run 'configure' in case it shows a problem.

Also, you don't indicate what xmlroff and PangoPDF versions you are
using.

Regards,


Tony.

[xmlroff] PANGOPDF: Changing library link file name.

[N O S P A M <ti...@ya...>]

Hello
I want to ask about conflict of link filename between
Pango and PangoPDF.

I had installed Pango 1.5 and the latest PangoPDF.
When I try to compile XMLRoff, I found "Undefined
reference" error.

According to FABIO post about compiling XMLRoff:
----------------
The most common problem I've seen with this process is
"undefined references" when making xmlroff. 

IF you have successfully configured and build pangopdf
and
successfully configured xmlroff, the problem behind
the undefined references is that you are using the
incorrect version of libpango-1.0.so

The quickest solution to this problem is replacing the
libpango-1.0.so you have in /usr/lib with
/usr/lib/pangopdf/libpango-1.0.so 
=========================
The program compiled succesfully after I replace:

/usr/lib/libpango-1.0.so  with
/usr/lib/pangopdf/libpango-1.0.so

Unfortunately other programs that depend on the
original Pango 1.5 crashed / cannot be compiled. I
have to re-compile and re-install Pango 1.5. 

Is it possible to change link file name from
libpango-1.0.so with other name to avoid conflict with
the original Pango 1.5?

Perhaps you can also contact XMLRoff team.
Thank you.
Best regards.




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [xmlroff] Difference between PangoPDF and Pango

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

On Sun, 22 Aug 2004, Tony Graham wrote:

> > So before going any further down this path I was wondering if what I'm
> > proposing is sane, and I'm hoping Tony Graham has a ready-made patch
> > like this on his hard-drive somewhere :-)
>
> Not yet.
>
> We should collaborate.

Well, count me in at least as a tester :)

(I'm currently blocked on the gnome-print backend unless I downgrade
my libraries, but even if I downgrade I have to fix the FreeType header
include problems. I do happen to have time, but I'm devoting myself to
some other projects now (yes, it's XSL-related).)

-- 
Steve Cheng
鄭君博

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

Re: [xmlroff] Difference between PangoPDF and Pango

[Tony G. <xm...@me...>]

At 23 Aug 2004 00:18 -0400, Tony Graham wrote:
...
 > One question that needs answering is whether the differences are small
 > enough that the XSL attributes and the rendering functions can be
 > tacked on to the xmlroff tree such that there's really no need to
 > modify Pango at all.

The answer to that question is that the different licenses of Pango
and xmlroff mean that something based on Pango code shouldn't go under
the xmlroff license, but IANAL.

Regards,


Tony.

Re: [xmlroff] Difference between PangoPDF and Pango

[Tony G. <xm...@me...>]

At 21 Aug 2004 19:58 +0100, da...@da... wrote:
 > So I've hacked the xmlroff configure.in so that it doesn't look for
 > PangoPDF, and I plan to apply the various minimal necessary changes
 > directly into the environment's version of Pango (basically just add the
 > xsl attribute stuff, as far as I can make out).

There will also be functions for rendering layouts, lines, and runs
since the core Pango rendering functions won't do anything with any
extra attributes.

One question that needs answering is whether the differences are small
enough that the XSL attributes and the rendering functions can be
tacked on to the xmlroff tree such that there's really no need to
modify Pango at all.

The first thing to do is to stub out all the xmlroff functions for the
extra XSL attributes and just make an xmlroff that works with the
stock Pango attributes.

If that can be done, then we need to decide how to go about adding
support for the extra XSL attributes.

Regards,


Tony.

[xmlroff] Re: xmlroff website help wanted

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

Another reprise of an answer that disappeared into the wrong bit
bucket.  Unfortunately, my answered tend to get shorter when I have to
write them out for a second time.

Stefan has offered to help update the xmlroff website.

Stefan Seefeld <se...@sy...> wrote at Sat, 21 Aug 2004 19:00:24 -0400:
> Tony Graham wrote:
> > Stefan,
> > 
> > Your offer of help is gratefully accepted.
> > 
> > It's a pity that you're not on the xmlroff mailing list (which is
> > *very* low volume usually) since just yesterday I announced a push to
> > get more people signed up as xmlroff developers.  Contributing to the
> > xmlroff website would certainly count.
> 
> ok, ok, I'm on the list now :-)

Great.  There is a digest option, too.

> > No, I don't really have a TODO list.  Here's what I can think of off
> > the top of my head:
> > 
> >  - The project needs its own copy of the Docbook website DTD and
> >    stylesheets.
> > 
> >    Right now I have an old, private, slightly hacked copy of the
> >    Docbook stylesheets.  There should be a copy in the CVS repository
> >    so anyone can rebuild the website and get consistent results.
> 
> hmm, what I usually do when using docbook xsl is write my own wrapper
> scripts that include the original ones with the 'canonical' URL at
> sf.net. If you happen to have the stylesheets installed on your machine
> your xml catalog usually has an entry for it, so xsltproc doesn't
> need to download anything. If you don't it still works, though it
> takes some more time.

One of my hacks is to map a "role" attribute on <entry> to a "class"
attribute on <td>, and I had to modify the table stylesheet to get it
to work.  A simple override in my custom-website.xsl just made all but
the first entry in each row disappear.

> >  - There are too many entries in the top-level sidebar menu.
> 
> Indeed, though with some regrouping this could get much better
> ('visitor', 'user', 'developer' seems to me to be a fairly good
>   toplevel grouping).
> 
> >  - The 'News' should be the RSS news feed from the SourceForge site so
> >    I/we don't have to update two places whenever there's a new version
> >    of xmlroff.
> 
> exactly. sf.net provides rss feeds for a number of tools such as news
> and releases. Luckily for us, docbook website now supports rss (I was
> told the other day that it's not yet part of any release, so we'd have
> to use a docbook version from cvs).
> 
> >  - There was a suggestion at one point to replace the website with
> >    just the Wiki, but I see maintaining the conformance and
> >    implementation sequence pages as Wiki pages being more pain and
> >    suffering than it's worth.
> 
> yeah. A wiki is fine if you have lots of unstructured activity (i.e.
> users wanting to comment, etc.).

There is a Wiki that doesn't get much use.

> > What suggestions do you have?
> 
> Well, the first thing to do would be to simply rearrange the toc
> (i.e. the menu). The first day I looked at the site I wondered how
> to access the mailing list...
> 
> The second step would be to integrate said rss feeds and thus get
> rid of the redundant data.
> 
> Finally, someone with graphics/design experience and good taste
> could have a close look at some styling (css...) for the site.

Gee, thanks for the compliment.

> A totally different issue is what tools to use for the project
> management. If you are happy with the tools sf.net provides we
> should try to integrate them as well as possible into the site.
> 
> I used to manage my projects (fresco, synopsis) at sf.net, until
> I was sufficiently annoyed by the buggy tools that I moved elsewhere.
> Now I'm using subversion instead of cvs, and the roundup issue tracker
> instead of sf.net's own bug/task tracker.
> 
> Regards,
> 		Stefan
> 
> PS: feel free to drag this back to the ML as I'm subscribed now.

Done.

Regards,


Tony.

Re: [xmlroff] Difference between PangoPDF and Pango

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

I answered this yesterday, but my reply seems to have been redirected
to /dev/null.  I didn't even get a copy of it.

da...@da... wrote at Sat, 21 Aug 2004 19:58:37 +0100:
> I'm trying to set up a build environment for xmlroff using jhbuild.  I
> want to eliminate PangoPDF (and eventually do everything use Cairo and
> gnome-print).
> 
> So I've hacked the xmlroff configure.in so that it doesn't look for
> PangoPDF, and I plan to apply the various minimal necessary changes
> directly into the environment's version of Pango (basically just add the
> xsl attribute stuff, as far as I can make out).

An idea whose time has come.

> I've tried downloading Pango and PangoPDF tarballs and diffing between
> them, but there's too much "noise" caused by minor differences between
> the original Pango source the PangoPDF source was created from, and the
> Pango tarball I'm diffing against.
> 
> So is there a patch somewhere containing a minimal set of changes that I
> can apply to a checkout of Pango from CVS that will let me build xmlroff
> against it directly?
> 
> I've tried copying the pango/pango-xsl-attribute* files directly into
> the Pango source tree, but there seems to have been a reorganisation in
> which a bunch of static attribute manipulation functions have been
> semi-exposed in a "private" header.

That was mostly me.

This time around, I'm prepared to copy the structures and functions
for the 'int' and 'float' PangoAttribute types rather than mess with
the internals of the Pango files. [1]

Also, the variants of render_layout that take ranges of lines could be
dispensed with by rendering the full layout but cropping it to the
area of interest.

> So before going any further down this path I was wondering if what I'm
> proposing is sane, and I'm hoping Tony Graham has a ready-made patch
> like this on his hard-drive somewhere :-)

Not yet.

We should collaborate.

Regards,


Tony.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=116115

Re: [xmlroff] Problems building with gnome-print [was Re: Success report, and some comments]

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

Steve Cheng <g3c...@cd...> wrote at Fri, 20 Aug 2004 12:48:17 -0400:
...
> The "Source" URI of gnome-print on the building xmlroff page is misleading;
> it points to the directory for version 2.2 even though version 2.3 (or
> later) is claimed to be required.

I have libgnomeprint 2.2.1.2 on one machine and 2.3.0 on another.

I have only just started trying to get xmlroff working with Pango (or
PangoPDF) 1.5.1 and libgnomeprint 2.7.1.  Pango 1.5.1 compiled okay,
but libgnomeprint has a dependency that I didn't expect for a Perl XML
module, so I have to dig that out of the JDS distribution.

I started my usual routine of updating PangoPDF to match the current
Pango version, but there's so many differences that that now seems the
wrong approach.  I'm now going to start with the current xmlroff and a
copy of the current Pango and make the minimum changes necessary to
make them work with each other.  In the short term, that may mean that
some of the XSL inline properties go away for a while.  We'll see.

Regards,


Tony.

[xmlroff] Difference between PangoPDF and Pango

[<da...@da...>]

I'm trying to set up a build environment for xmlroff using jhbuild.  I
want to eliminate PangoPDF (and eventually do everything use Cairo and
gnome-print).

So I've hacked the xmlroff configure.in so that it doesn't look for
PangoPDF, and I plan to apply the various minimal necessary changes
directly into the environment's version of Pango (basically just add the
xsl attribute stuff, as far as I can make out).

I've tried downloading Pango and PangoPDF tarballs and diffing between
them, but there's too much "noise" caused by minor differences between
the original Pango source the PangoPDF source was created from, and the
Pango tarball I'm diffing against.

So is there a patch somewhere containing a minimal set of changes that I
can apply to a checkout of Pango from CVS that will let me build xmlroff
against it directly?

I've tried copying the pango/pango-xsl-attribute* files directly into
the Pango source tree, but there seems to have been a reorganisation in
which a bunch of static attribute manipulation functions have been
semi-exposed in a "private" header.

So before going any further down this path I was wondering if what I'm
proposing is sane, and I'm hoping Tony Graham has a ready-made patch
like this on his hard-drive somewhere :-)

Dave Malcolm

Re: [xmlroff] Problems building with gnome-print [was Re: Success report, and some comments]

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

Steve Cheng <g3c...@cd...> wrote at Fri, 20 Aug 2004 12:48:17 -0400:
> On Fri, 20 Aug 2004, Tony Graham wrote:
> 
> > There used to be.  It's the patching that turned out to be dumb.
> 
> All right, but right now I am having difficulties building the gnome-print
> backend, linking errors with many library functions. May be I need a new
> version of the libraries.  But:

I don't have time to answer today.  Sorry.

I use GNOME Print 2.3, I believe (but that's not this machine).

Regards,


Tony.

[xmlroff] Problems building with gnome-print [was Re: Success report, and some comments]

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

On Fri, 20 Aug 2004, Tony Graham wrote:

> There used to be.  It's the patching that turned out to be dumb.

All right, but right now I am having difficulties building the gnome-print
backend, linking errors with many library functions. May be I need a new
version of the libraries.  But:

The "Source" URI of gnome-print on the building xmlroff page is misleading;
it points to the directory for version 2.2 even though version 2.3 (or
later) is claimed to be required.

Tony, I also think it will be helpful if you also post the exact versions
of the packages you use, because if I try the newest version of gnome-print
(2.7.1) it says it needs Pango 1.5, which even if I had it installed,
I would have serious doubts about it working with PangoPDF / xmlroff.

> The PDFlib backend would never go in because of PDFlib's license.  I
> didn't realise that when I started.
>
> Pango and GNOME Print work together better than they ever used to,
> possibly in part due to my enhancement request [1], which is why I'm
> hopeful about the current Pango obviating much of PangoPDF.
>
> The extra PangoAttributes could be submitted to Pango if they're
> cooked enough.  I quite like the callback attribute, myself, but it's
> only had one limited use, and that is in the wrong backend.

Thanks for the information; I will take a closer look some time.

-- 
Steve Cheng
鄭君博

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

Re: [xmlroff] Success report, and some comments

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

Steve Cheng <g3c...@cd...> wrote at Fri, 20 Aug 2004 11:13:29 -0400:
> On Fri, 20 Aug 2004, Steve Cheng wrote:
> 
> > I don't use RPM, but does that work?  I mean,
> > doesn't the xmlroff building page say that you need to patch GNOME Print
> > to use PangoPDF?
> 
> Some observations:
> 
> 1. The building xmlroff page says there are directions to patch GNOME print
>    in the xmlroff distribution, but I didn't find any.  Maybe I'm dumb.

Patch instructions removed.

...
> 3. The PangoPDF home page have the wrong versions listed as current.

Updated.

Regards,


Tony.

Re: [xmlroff] Success report, and some comments

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

Steve Cheng <g3c...@cd...> wrote at Fri, 20 Aug 2004 11:13:29 -0400:
> On Fri, 20 Aug 2004, Steve Cheng wrote:
> 
> > I don't use RPM, but does that work?  I mean,
> > doesn't the xmlroff building page say that you need to patch GNOME Print
> > to use PangoPDF?
> 
> Some observations:
> 
> 1. The building xmlroff page says there are directions to patch GNOME print
>    in the xmlroff distribution, but I didn't find any.  Maybe I'm dumb.

There used to be.  It's the patching that turned out to be dumb.

> 2. I sincerely hope that I can tell the patched GNOME print to build
>    libraries with a separate name so as to not clobber the system GNOME print.

Don't patch.

The instructions need to be removed.

> 3. The PangoPDF home page have the wrong versions listed as current.

It will be updated (eventually).

> 4. Just what is really different/new in PangoPDF from regular Pango?
>    I'm using Pango myself right now for a project I'm working on,
>    despite the lack of tutorial documentation it was a breeze to use,
>    so I can't imagine it would be that hard to have the new functionality
>    go in the main Pango :)

The PDFlib backend would never go in because of PDFlib's license.  I
didn't realise that when I started.

Pango and GNOME Print work together better than they ever used to,
possibly in part due to my enhancement request [1], which is why I'm
hopeful about the current Pango obviating much of PangoPDF.

The extra PangoAttributes could be submitted to Pango if they're
cooked enough.  I quite like the callback attribute, myself, but it's
only had one limited use, and that is in the wrong backend.

Regards,


Tony.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=125762