Menu
▾
▴
xmlroff-list — xmlroff XSL formatter discussion list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(8) |
Mar
(38) |
Apr
(13) |
May
(17) |
Jun
(9) |
Jul
(31) |
Aug
(5) |
Sep
|
Oct
(9) |
Nov
(8) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(8) |
Feb
(2) |
Mar
(10) |
Apr
(1) |
May
(6) |
Jun
(4) |
Jul
|
Aug
(32) |
Sep
(20) |
Oct
(26) |
Nov
(2) |
Dec
(1) |
| 2005 |
Jan
(6) |
Feb
(9) |
Mar
(69) |
Apr
(13) |
May
(7) |
Jun
(21) |
Jul
(9) |
Aug
(21) |
Sep
(28) |
Oct
|
Nov
(15) |
Dec
(1) |
| 2006 |
Jan
(32) |
Feb
(47) |
Mar
(44) |
Apr
(10) |
May
(5) |
Jun
(7) |
Jul
(21) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
|
Dec
(4) |
| 2007 |
Jan
|
Feb
(12) |
Mar
(7) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tony G. <Ton...@Su...> - 2003-07-29 10:29:30
|
Dave Malcolm wrote at 26 Jul 2003 17:19:37 +0000: > Hope the above makes sense! Is there a simple fix I've missed? Is it > possible to statically link PangoPDF inside xmlroff without exporting > its symbols to fix the problem? (I don't know enough about "so" files to > implement this myself). I was about to suggest statically linking PangoPDF to libfo. Add '--enable-static --disable-shared' to the PangoPDF 'configure' command line. You may also need to add '--with-included-modules=basic-gp'. You may also need to add '--enable-static --disable-shared' to the xmlroff 'configure' command line, but I suggest trying it without first. 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 |
|
From: Dave M. <da...@da...> - 2003-07-26 16:17:55
|
On Fri, 2003-07-25 at 15:56, Tony Graham wrote:
[snip]
> You are now into uncharted territory. Do you get any useful messages
> when your app crashes? What is the ldd output?
To try to isolate the problem, I grabbed gnome-hello from GNOME CVS,
built it normally (it worked), and then hacked the configure script to
link against libfo thus:
Index: configure.ac
===================================================================
RCS file: /cvs/gnome/gnome-hello/configure.ac,v
retrieving revision 1.8
diff -u -r1.8 configure.ac
--- configure.ac 16 Jul 2003 05:42:52 -0000 1.8
+++ configure.ac 26 Jul 2003 15:59:00 -0000
@@ -20,7 +20,7 @@
LIBGNOMEUI_REQUIRED=1.96.0
SCROLLKEEPER_REQUIRED=0.1.4
-PKG_CHECK_MODULES(GNOME_HELLO, libgnome-2.0 >= $LIBGNOME_REQUIRED
libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED)
+PKG_CHECK_MODULES(GNOME_HELLO, libgnome-2.0 >= $LIBGNOME_REQUIRED
libgnomeui-2.0 >= $LIBGNOMEUI_REQUIRED libfo-0.2 >= 0.2.4)
AC_SUBST(GNOME_HELLO_CFLAGS)
AC_SUBST(GNOME_HELLO_LIBS)
I then did re-ran autogen.sh, did a make clean, then a make.
The gnome-hello program now crashes on startup, in a similar way to my
Conglomerate tests; here's a fragment of the backtrace:
(gdb) run
Starting program:
/home/david/coding/gnome-anonymous-cvs/gnome-hello/src/gnome-hello
[New Thread 1094308544 (LWP 25565)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1094308544 (LWP 25565)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x40e0392e in pango_layout_run_get_extents (run=0x80b9b10,
shape_setp=0x0, run_ink=0xbfffb3c0, run_logical=0x80b9cbc) at
pango-layout.c:3751
#2 0x40e037c9 in pango_layout_line_get_extents_real (line=0x80bc0c0,
ink_rect=0x0, logical_rect=0xbfffb3c0) at pango-layout.c:3689
#3 0x40e03947 in pango_layout_line_get_extents (line=0x80b9b10,
ink_rect=0x0, logical_rect=0xbfffb3c0) at pango-layout.c:3774
#4 0x40e00fc9 in get_line_extents_layout_coords (layout=0x80b9960,
line=0x80bc0c0, layout_width=-1, y_offset=0, baseline=0xbfffb44c,
line_ink_layout=0x0,
line_logical_layout=0xbfffb450) at pango-layout.c:1867
#5 0x40e010cd in pango_layout_get_extents_internal (layout=0x80b9960,
ink_rect=0x0, logical_rect=0xbfffb4f0, line_extents=0x0) at
pango-layout.c:1935
#6 0x40e01312 in pango_layout_get_extents (layout=0x80b9b10,
ink_rect=0x0, logical_rect=0xbfffb4f0) at pango-layout.c:2031
#7 0x4025793d in gtk_label_get () from /usr/lib/libgtk-x11-2.0.so.0
#8 0x401d7533 in gtk_accel_label_get_accel_width () from
/usr/lib/libgtk-x11-2.0.so.0
Here's the result of running ldd on the executable:
[david@shirehorse1 src]$ ldd gnome-hello
libgnomeui-2.so.0 => /usr/lib/libgnomeui-2.so.0 (0x40028000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400b3000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400bc000)
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x400d4000)
libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0
(0x40136000)
libgnome-2.so.0 => /usr/lib/libgnome-2.so.0 (0x40163000)
libpangoft2-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangoft2-1.0.so.0 (0x40177000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x40196000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x403ea000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x40459000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0
(0x40472000)
libpangoxft-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangoxft-1.0.so.0 (0x40485000)
libpangox-1.0.so.0 => /usr/local/lib/pangopdf/libpangox-1.0.so.0
(0x404a3000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x404af000)
libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x40506000)
libgnomevfs-2.so.0 => /usr/lib/libgnomevfs-2.so.0 (0x4053d000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4
(0x40576000)
libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x40589000)
liblinc.so.1 => /usr/lib/liblinc.so.1 (0x405cb000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x405d3000)
libfo-0.2.so.0 => /usr/local/lib/libfo-0.2.so.0 (0x405d8000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x40867000)
libpangopdflib-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangopdflib-1.0.so.0 (0x408f5000)
libpangogp-1.0.so.0 =>
/usr/local/lib/pangopdf/libpangogp-1.0.so.0 (0x4091f000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40941000)
libgnomeprint-2-2.so.0 => /usr/lib/libgnomeprint-2-2.so.0
(0x40966000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x40da8000)
libxslt.so.1 => /usr/lib/libxslt.so.1 (0x40dbf000)
libpango-1.0.so.0 => /usr/local/lib/pangopdf/libpango-1.0.so.0
(0x40dec000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40e1d000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x40e52000)
libdl.so.2 => /lib/libdl.so.2 (0x40e56000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40e5a000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x40ec5000)
libz.so.1 => /usr/lib/libz.so.1 (0x40fb0000)
libm.so.6 => /lib/tls/libm.so.6 (0x40fbe000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40fe0000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libpopt.so.0 => /usr/lib/libpopt.so.0 (0x40fee000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40ff7000)
libesd.so.0 => /usr/lib/libesd.so.0 (0x41015000)
libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x4101d000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x41042000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x41094000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x41098000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x410a0000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x410ae000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x410c0000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x410c8000)
libORBitCosNaming-2.so.0 => /usr/lib/libORBitCosNaming-2.so.0
(0x411a8000)
libssl.so.4 => /lib/libssl.so.4 (0x411ad000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x411e2000)
librt.so.1 => /lib/tls/librt.so.1 (0x412d3000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x412e5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libresolv.so.2 => /lib/libresolv.so.2 (0x41306000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2
(0x41318000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x4132b000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3
(0x41389000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3
(0x4139a000)
The problems appears to be this line:
libpango-1.0.so.0 => /usr/local/lib/pangopdf/libpango-1.0.so.0
(0x40dec000)
i.e. that clients of libpango (such as GTK) are being dynamically linked
to PangoPDF, rather than the "real" Pango, and die horribly (due to ABI
inconsistencies, I think)
I'm not an expert at managing dynamic libraries on Unix and similar
systems (I come from a Win32 and games console background); I believe
that PangoPDF needs to have some kind of renaming: probably of the
generated so file, and possibility of the symbols inside it (some kind
of automated shell script?)
Hope the above makes sense! Is there a simple fix I've missed? Is it
possible to statically link PangoPDF inside xmlroff without exporting
its symbols to fix the problem? (I don't know enough about "so" files to
implement this myself).
--
David Malcolm
www.conglomerate.org
|
|
From: Tony G. <Ton...@Su...> - 2003-07-25 15:54:10
|
Dave Malcolm wrote at 25 Jul 2003 12:10:17 +0000: > On Thu, 2003-07-24 at 07:53, Tony Graham wrote: ... > > Please do an update and see if you still have the problem. > > OK - it fixed that problem. Thanks! Great. ... > When I build and run my app (linking against libfo), the Gtk libraries > seem to dynamically link against the local PangoPDF version of the Pango > symbols, rather than the /usr/lib build of the "real" Pango, and crashes > occur (probably there are a few things out of sync here and there). > > Is this the anticipated behaviour i.e. do I need to rebuild my entire > Gtk/Gnome build environment on top of PangoPDF (please no!) or can > anyone suggest a simple solution? Is there something simple I've > missed? No, nothing simple that you've missed. You are now into uncharted territory. Do you get any useful messages when your app crashes? What is the ldd output? 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 |
|
From: Dave M. <da...@da...> - 2003-07-25 11:08:35
|
On Thu, 2003-07-24 at 07:53, Tony Graham wrote: > Dave Malcolm wrote at 22 Jul 2003 19:31:36 +0000: > > I'm attempting to built xmlroff from CVS, but am having problems. > ... > > It looks to me like the macro in configure.in to setup the version info > > hasn't worked properly; it's come out as "::" rather than "0:2:3" (or > > whatever) > > > > Have anyone got any suggestions? Have I forgotten something obvious? > > Should I have set something when I configured the code? > > It was my problem, not your problem. > > I checked in a modified configure.in and Makefile.am on 22nd July > after I found that I had the problem after breaking things on 21st > July. > > Please do an update and see if you still have the problem. OK - it fixed that problem. Thanks! I'm now attempting to link Conglomerate against libfo, and am running into random crashes. I'm using a vanilla Red Hat 9 machine. I've built PangoPDF and xmlroff, installing them to /usr/local, with PKG_CONFIG_PATH set to /usr/local/lib/pkgconfig. When I build and run my app (linking against libfo), the Gtk libraries seem to dynamically link against the local PangoPDF version of the Pango symbols, rather than the /usr/lib build of the "real" Pango, and crashes occur (probably there are a few things out of sync here and there). Is this the anticipated behaviour i.e. do I need to rebuild my entire Gtk/Gnome build environment on top of PangoPDF (please no!) or can anyone suggest a simple solution? Is there something simple I've missed? > > Also, please provide an opinion on the usability of separating out > (and not installing) fo-doc-commands.h. I'm thinking of doing some hacking on the gnome print backend (to implement passing a GnomePrintJob and forcing the code to stick to the paper size in that, as discussed in a previous email); I can't really comment until I've got everything building and running within my app. -- David Malcolm www.conglomerate.org |
|
From: Tony G. <Ton...@Su...> - 2003-07-24 07:51:07
|
Dave Malcolm wrote at 22 Jul 2003 19:31:36 +0000: > I'm attempting to built xmlroff from CVS, but am having problems. ... > It looks to me like the macro in configure.in to setup the version info > hasn't worked properly; it's come out as "::" rather than "0:2:3" (or > whatever) > > Have anyone got any suggestions? Have I forgotten something obvious? > Should I have set something when I configured the code? It was my problem, not your problem. I checked in a modified configure.in and Makefile.am on 22nd July after I found that I had the problem after breaking things on 21st July. Please do an update and see if you still have the problem. Also, please provide an opinion on the usability of separating out (and not installing) fo-doc-commands.h. 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 |
|
From: Dave M. <da...@da...> - 2003-07-22 18:31:28
|
I'm attempting to built xmlroff from CVS, but am having problems. I checked out the source, and ran "./autogen.sh", followed by "./configure --help" then "./configure" to check things were sane. Upon typing "make" it builds until the final stages, where I get the following error: Making all in . make[2]: Entering directory `/home/david/coding/sourceforge-anonymous-xmlroff/xmlroff' /bin/sh ./libtool --mode=link gcc -g -O2 -I/usr/local/include/pangopdf/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/local/include -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -Wall -o libfo-0.2.la -rpath /usr/local/lib -version-info :: fo-object.lo fo-node.lo fo-context.lo fo-context-util.lo expression-parser.lo result-to-fo.lo area-to-pdf.lo area/libfo-area.la expr/libfo-expr.la fo/libfo-fo.la datatype/libfo-datatype.la property/libfo-property.la libfo/libfo-libfo.la libtool: link: CURRENT `' is not a nonnegative integer libtool: link: `::' is not valid version information It looks to me like the macro in configure.in to setup the version info hasn't worked properly; it's come out as "::" rather than "0:2:3" (or whatever) Have anyone got any suggestions? Have I forgotten something obvious? Should I have set something when I configured the code? BTW This is on a Red Hat 9 machine. -- David Malcolm www.conglomerate.org |
|
From: Tony G. <Ton...@Su...> - 2003-07-18 23:56:57
|
Tony Graham wrote at 8 Jul 2003 12:46:33 +0100: > I think that the solution to my hangup about installing area-to-pdf.h > is to make an fo_xsl_formatter_draw() function that doesn't do much > more than call area_tree_to_pdf(). Done in CVS. 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 |
|
From: Tony G. <Ton...@Su...> - 2003-07-10 15:58:36
|
Dave Malcolm wrote at 10 Jul 2003 15:47:46 +0000: > On Tue, 2003-07-08 at 11:46, Tony Graham wrote: ... > BTW, does PDF support changing page sizes? Yes. Every 'Page' object can set its own 'MediaBox' entry. ... > I thought that perhaps what needs to be done is a fix to the GnomePrint > API. But I think it's acceptable for my application to restrict users to I can't see the GnomePrint API being 'fixed' since the PostScript model is the same 'all-for-one-and-one-for-all' page size model. ... > So I think I want a FoDoc subclass that takes either an existing > GnomePrintJob or GnomePrintContext as input, and restricts the input to > having simple-page-masters all the same size (either the entire set, or > those that get used). Currently there's no way for the FoDoc to quiz either the FO tree or the Area tree to see what size pages were either specified or used. In my previous message, I did, however, mention a possible way for the FoAreaTree to 'tell' the FoDoc the limits of the page sizes. > In terms of GUI, I suspect I need to refactor my stylesheets so that the > paper size part of the XSL-FO output is determined by GnomePrint's > print/paper selection dialog (whereas the rest of the XSL-FO comes from > a standard transform). This might make sense to split off and provide > as part of libfo (or maybe a libfognomeprintui thing). I would need more details before I can comment. > What happens if there's a mismatch between the sizes in GnomePrint and > in the <simple-page-master>? Does it crop, or scale? Right now there is no mismatch because the FoAreaPage sets the page size for the GnomePrintContext and, as you know, the FoDocGP makes a new GnomePrintJob whenever the page size changes. There are, of course, numerous options for what to do if there's a mismatch between the externally-specified GnomePrint page size and the FoAreaPage page size. Possibly an FoDocGP child type could have properties specifying what to do when the FoAreaPage is larger or smaller than the GnomePrint page size. Options include: Smaller: 100% Scale up uniformly Scale up X and Y independently to fill GnomePrint page Larger: Crop (i.e. 100% despite being larger than GnomePrint page) Scale down uniformly Scale down X and Y independently to fill GnomePrint page > > Multiple possible and/or partial solutions come to mind: ... > > - Add a child type of FoDocGP that supports only a fixed page size. > > The above sound like what I want. I'll look into it. Please file an enhancement request on SourceForge. ... > > Out of interest, why don't you just use FoXslFormatter (once there's a > > way to pass in your GnomePrintContext or GnomePrintJob)? > > Err... because I didn't see it. I'm still learning to find my way That's fine. It's certainly much better than if you'd said it wouldn't work for you. Part of the reason for the libfo-examples package is to show people what can be done. (The other part is to prove that libfo can be used with programs that aren't built in the xmlroff project's source directory.) > around your source tree. For that matter, I'm also still learning both > the GnomePrint API and XSL-FO, so this is all a bit rough-and-ready at > the moment. My understanding of the GnomePrint API is similarly rough-and-ready. Have you read http://xmlroff.sourceforge.net/phpwiki/index.php/DirectoryStructure and was it useful to you? I am contemplating putting in a SourceForge support request to get the fo, property, area, datatype, and expr subdirectories put under the libfo directory in the CVS repository. > Another question: is there an XML serialisation format for the area > trees? I had a brief look through the "area" subdir; the closest I > could see was the fo_area_area_debug_dump_properties function. No, there isn't an XML serialisation format for the area trees. So far there hasn't been any call for one, but it would be easy enough to start adding one. But do you want the area tree as it exists or do you want sufficient information to be able to render the area tree? For example, things that aren't going to change, such as border colour, are maintained in the FO property values and don't appear in the area tree. Anything that is a length-conditional, a length-range, or otherwise can vary depending on the layout has (or should have) a single value in the area tree. 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 |
|
From: Dave M. <da...@da...> - 2003-07-10 14:47:02
|
On Tue, 2003-07-08 at 11:46, Tony Graham wrote:
> This mismatch between the XSL model -- where every page can be a
> different size -- and the GNOME Print model -- where the page size is
> set once and doesn't change -- is a major pain. (SVG Print may also
> be a similar pain.)
BTW, does PDF support changing page sizes?
>
> FWIW, this approach was first proposed on the xmlroff Wiki on 2nd May
> [1], and the existence of the 'GnomePrint' page was noted on this list
> on 5th May.
I thought that perhaps what needs to be done is a fix to the GnomePrint
API. But I think it's acceptable for my application to restrict users to
having a single paper size for the entire document; I'm targetting home
and office desktop users doing fairly simple word processing tasks
rather than an all-singing all-dancing system like JDF that can collate
print from multiple trays, apply colour correction etc etc. Plus I'm
doing this as a hobby and there's only so much time I'm willing to spend
fixing the GnomePrint API - unless someone's willing to pay me to do
this work :-)
As far as I understand XSL-FO, it's fairly easy to tell if an input
document has a consistent page size, and what the size should be. Just
look at the <fo:simple-page-master> elements - though it could give
false negatives if you have the case where you have e.g. a set of page
masters of which some are A4 and some are A5, but only the latter
actually get used when the <fo:page-sequence-master> tags select them;
so alternatively it should determine page size when it has the actual
pages...
So I think I want a FoDoc subclass that takes either an existing
GnomePrintJob or GnomePrintContext as input, and restricts the input to
having simple-page-masters all the same size (either the entire set, or
those that get used).
In terms of GUI, I suspect I need to refactor my stylesheets so that the
paper size part of the XSL-FO output is determined by GnomePrint's
print/paper selection dialog (whereas the rest of the XSL-FO comes from
a standard transform). This might make sense to split off and provide
as part of libfo (or maybe a libfognomeprintui thing).
What happens if there's a mismatch between the sizes in GnomePrint and
in the <simple-page-master>? Does it crop, or scale?
>
> Multiple possible and/or partial solutions come to mind:
>
> - Add:
>
> FoDoc * fo_doc_gp_new_from_job (GnomePrintJob *job)
>
> to fo-doc-gp-private.h and make fo-doc-gp-private.h be installed.
>
> - Add a fix_page_size property to FoDocGP so it doesn't always chop
> and change GnomePrintContext objects.
>
> - Add a child type of FoDocGP that supports only a fixed page size.
The above sound like what I want.
> - Add a category to fo_area_tree_to_pdf() for FoAreaTree objects
> (i.e., eventually add a draw() method for FoAreaTree) that can call
> a method of FoDoc to do whatever is necessary to set up the rest of
> the drawing. In support of GNOME Print type page models, the
> FoAreaTree could pass the maximum height and maximum width of its
> child FoAreaPage objects so the largest necessary page size is used
> throughout.
>
> - Improve the setting of parameters for FoDoc types, probably by
> adding more parameters to FoLibfoContext and making FoLibfoContext
> able to generate FoDoc objects.
>
> > I've also got an xmlDocPtr, containing the document (i.e. with a fo:root
> > as the root element); it's typically the result of a XSLT transform,
> > which my GUI has hidden from the end-user.
>
> That is how it's supposed to work.
>
> > Here my pseudo-code - will this be a sane way of using libfo?
> >
> > void print_xslfo(GnomePrintContext *gpc,
> > xmlDocPtr xml_doc)
> > {
> > FoDoc *fo_doc;
> > FoFo *fo_tree;
> > FoArea *area_tree;
> > GError *error = NULL;
> >
> > g_return_if_fail(gpc);
> > g_return_if_fail(xml_doc);
> >
> > fo_doc = fo_doc_gp_new ();
>
> fo_doc = fo_doc_new_from_type ("gp");
>
> But that will have to change once there's a way to pass in your
> GnomePrintContext or GnomePrintJob.
>
> > /* FIXME: need some way to pass our gpc or job to the FoDoc
> > constructor; would a config do it? */
> >
> > fo_xml_doc_to_fo_and_area_trees (xml_doc,
> > fo_doc,
> > &fo_tree,
> > &area_tree,
> > 0, /* gint debug_level */,
> > &error);
> > /* FIXME: error handling! */
> > }
>
> You currently also need to call fo_area_tree_to_pdf() to actually get
> any output. It doesn't happen automatically because there's supposed
> to be an 'area-tree adjust' phase after the FO and area trees are
> first made up.
>
> I think that the solution to my hangup about installing area-to-pdf.h
> is to make an fo_xsl_formatter_draw() function that doesn't do much
> more than call area_tree_to_pdf().
>
> Out of interest, why don't you just use FoXslFormatter (once there's a
> way to pass in your GnomePrintContext or GnomePrintJob)?
Err... because I didn't see it. I'm still learning to find my way
around your source tree. For that matter, I'm also still learning both
the GnomePrint API and XSL-FO, so this is all a bit rough-and-ready at
the moment.
Another question: is there an XML serialisation format for the area
trees? I had a brief look through the "area" subdir; the closest I
could see was the fo_area_area_debug_dump_properties function.
Thanks!
--
David Malcolm
www.conglomerate.org
|
|
From: Tony G. <Ton...@Su...> - 2003-07-08 11:44:28
|
Dave Malcolm wrote at 8 Jul 2003 01:29:56 +0000:
...
> For what it's worth, here a fragment of code that should give an idea of
> what I'm trying to do with libfo within Conglomerate... Hopefully we can
> meet somewhere in the middle.
I hope that we can. I don't have a hard and fast opinion on what the
interface should be like. I also accept patches.
> I've got a GnomePrintContext, to print to either a real printer, or to
> generate a print preview. I could pass a GnomePrintJob instead, if need
> be. However the FoDoc constructor for GnomePrint likes to create its
> own GPC, and could be a pain for me - perhaps I need some higher level
> object to pass. I looked through the go_doc_gp code and IIRC it can
> create new print jobs as it goes along, in the case that the paper size
> changes half-way through a job. Not sure how to go about getting that
> into the print preview dialog :-(
This mismatch between the XSL model -- where every page can be a
different size -- and the GNOME Print model -- where the page size is
set once and doesn't change -- is a major pain. (SVG Print may also
be a similar pain.)
FWIW, this approach was first proposed on the xmlroff Wiki on 2nd May
[1], and the existence of the 'GnomePrint' page was noted on this list
on 5th May.
Multiple possible and/or partial solutions come to mind:
- Add:
FoDoc * fo_doc_gp_new_from_job (GnomePrintJob *job)
to fo-doc-gp-private.h and make fo-doc-gp-private.h be installed.
- Add a fix_page_size property to FoDocGP so it doesn't always chop
and change GnomePrintContext objects.
- Add a child type of FoDocGP that supports only a fixed page size.
- Add a category to fo_area_tree_to_pdf() for FoAreaTree objects
(i.e., eventually add a draw() method for FoAreaTree) that can call
a method of FoDoc to do whatever is necessary to set up the rest of
the drawing. In support of GNOME Print type page models, the
FoAreaTree could pass the maximum height and maximum width of its
child FoAreaPage objects so the largest necessary page size is used
throughout.
- Improve the setting of parameters for FoDoc types, probably by
adding more parameters to FoLibfoContext and making FoLibfoContext
able to generate FoDoc objects.
> I've also got an xmlDocPtr, containing the document (i.e. with a fo:root
> as the root element); it's typically the result of a XSLT transform,
> which my GUI has hidden from the end-user.
That is how it's supposed to work.
> Here my pseudo-code - will this be a sane way of using libfo?
>
> void print_xslfo(GnomePrintContext *gpc,
> xmlDocPtr xml_doc)
> {
> FoDoc *fo_doc;
> FoFo *fo_tree;
> FoArea *area_tree;
> GError *error = NULL;
>
> g_return_if_fail(gpc);
> g_return_if_fail(xml_doc);
>
> fo_doc = fo_doc_gp_new ();
fo_doc = fo_doc_new_from_type ("gp");
But that will have to change once there's a way to pass in your
GnomePrintContext or GnomePrintJob.
> /* FIXME: need some way to pass our gpc or job to the FoDoc
> constructor; would a config do it? */
>
> fo_xml_doc_to_fo_and_area_trees (xml_doc,
> fo_doc,
> &fo_tree,
> &area_tree,
> 0, /* gint debug_level */,
> &error);
> /* FIXME: error handling! */
> }
You currently also need to call fo_area_tree_to_pdf() to actually get
any output. It doesn't happen automatically because there's supposed
to be an 'area-tree adjust' phase after the FO and area trees are
first made up.
I think that the solution to my hangup about installing area-to-pdf.h
is to make an fo_xsl_formatter_draw() function that doesn't do much
more than call area_tree_to_pdf().
Out of interest, why don't you just use FoXslFormatter (once there's a
way to pass in your GnomePrintContext or GnomePrintJob)?
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
[1] http://xmlroff.sourceforge.net/phpwiki/index.php/GnomePrint
|
|
From: Tony G. <Ton...@Su...> - 2003-07-08 08:28:38
|
Dave Malcolm wrote at 8 Jul 2003 01:14:52 +0000: > On Mon, 2003-07-07 at 22:47, Tony Graham wrote: ... > > xmlroff-libfo is currently uncompilable since it depends of headers > > that currently are not installed. > > Did xmlroff-libfo.c make it into the tarball? I downloaded it but it > only seems to have two ".c" files, xmlroff-basic.c and xmlroff-init2.c Alas, no. xmlroff-libfo.c is basically xmlroff.c with the commented-out font embedding control code removed. Expect a libfo-examples-0.2.3.1 real soon now. 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 |
|
From: Dave M. <da...@da...> - 2003-07-08 00:28:42
|
On Mon, 2003-07-07 at 22:44, Tony Graham wrote:
[snip]
> That's something that I haven't worked out yet: whether to expose all
> the object types or just let everything be an FoObject or, at best, an
> FoNode and let programs get at an object's properties using
> g_object_get_property() (or whatever it's called).
>
[snip]
> The 'xmlroff-libfo' example doesn't compile because I baulked at
> making area-to-pdf.h an installed file since the stuff in
> area-to-pdf.h is likely to be subsumed into a 'draw' method of each
> object type.
>
For what it's worth, here a fragment of code that should give an idea of
what I'm trying to do with libfo within Conglomerate... Hopefully we can
meet somewhere in the middle.
I've got a GnomePrintContext, to print to either a real printer, or to
generate a print preview. I could pass a GnomePrintJob instead, if need
be. However the FoDoc constructor for GnomePrint likes to create its
own GPC, and could be a pain for me - perhaps I need some higher level
object to pass. I looked through the go_doc_gp code and IIRC it can
create new print jobs as it goes along, in the case that the paper size
changes half-way through a job. Not sure how to go about getting that
into the print preview dialog :-(
I've also got an xmlDocPtr, containing the document (i.e. with a fo:root
as the root element); it's typically the result of a XSLT transform,
which my GUI has hidden from the end-user.
Here my pseudo-code - will this be a sane way of using libfo?
void print_xslfo(GnomePrintContext *gpc,
xmlDocPtr xml_doc)
{
FoDoc *fo_doc;
FoFo *fo_tree;
FoArea *area_tree;
GError *error = NULL;
g_return_if_fail(gpc);
g_return_if_fail(xml_doc);
fo_doc = fo_doc_gp_new ();
/* FIXME: need some way to pass our gpc or job to the FoDoc
constructor; would a config do it? */
fo_xml_doc_to_fo_and_area_trees (xml_doc,
fo_doc,
&fo_tree,
&area_tree,
0, /* gint debug_level */,
&error);
/* FIXME: error handling! */
}
--
David Malcolm
www.conglomerate.org
|
|
From: Dave M. <da...@da...> - 2003-07-08 00:14:43
|
On Mon, 2003-07-07 at 22:47, Tony Graham wrote: > The new 'libfo-examples' package includes examples of using the libfo > library from the 'Sun xmlroff XSL Formatter' project. > > See http://xmlroff.sourceforge.net/. > > xmlroff-basic demonstrates the 'basic' interface to libfo. > > xmlroff-init2 demonstrates using the 'basic' interface with your own > memory allocation functions. > > xmlroff-libfo is currently uncompilable since it depends of headers > that currently are not installed. Did xmlroff-libfo.c make it into the tarball? I downloaded it but it only seems to have two ".c" files, xmlroff-basic.c and xmlroff-init2.c -- David Malcolm www.conglomerate.org |
|
From: Tony G. <Ton...@Su...> - 2003-07-07 22:45:47
|
The new 'libfo-examples' package includes examples of using the libfo library from the 'Sun xmlroff XSL Formatter' project. See http://xmlroff.sourceforge.net/. xmlroff-basic demonstrates the 'basic' interface to libfo. xmlroff-init2 demonstrates using the 'basic' interface with your own memory allocation functions. xmlroff-libfo is currently uncompilable since it depends of headers that currently are not installed. License ======= These examples are licensed under the terms of a BSD-style license. See the file COPYING for details. Mailing List ============ xmlroff and libfo are discussed on the xml...@li... mailing list. See http://lists.sourceforge.net/lists/listinfo/xmlroff-list 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 |
|
From: Tony G. <Ton...@Su...> - 2003-07-07 22:42:45
|
Dave Malcolm wrote at 5 Jul 2003 03:00:37 +0000: > I'm attempting to compile and link a program against libfo (using the > new xmlroff-0.2.3 tarball). ... > I've checked and the "datatype" and "area" header files haven't been > copied up into the installation directory - should they have been? That's something that I haven't worked out yet: whether to expose all the object types or just let everything be an FoObject or, at best, an FoNode and let programs get at an object's properties using g_object_get_property() (or whatever it's called). I have added a new 'libfo-examples' package to the SourceForge site that shows how to use the so-called 'basic' interface where your program/library doesn't have to even know about GLib. The 'xmlroff-libfo' example doesn't compile because I baulked at making area-to-pdf.h an installed file since the stuff in area-to-pdf.h is likely to be subsumed into a 'draw' method of each object type. 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 |
|
From: Tony G. <Ton...@Su...> - 2003-07-07 21:00:18
|
Overview of Changes in Pango 1.2.3.1 ==================================== * Added --disable-gp configure argument for compiling before GNOME Print is installed. * Changed to build and use pangopdf-querymodules instead of pango-querymodules so PangoPDF stays out of the way of Pango. * Other installation fixes. Download from http://sourceforge.net/projects/pangopdf/. The --disable-gp option allows you to compile and install PangoPDF without compiling the GNOME Print backend. If you don't have GNOME Print installed, you can run: ./configure --disable-gp then build and install PangoPDF, then build and install GNOME Print, then run configure again without the --disable-gp option to build PangoPDF with the GNOME Print backend. It's more a workaround than a solution for the Pango-GNOME Print interdependency, but I expect that the real solution will require a separate configure script for the GNOME Print backend. 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 |
|
From: Tony G. <Ton...@Su...> - 2003-07-07 20:48:21
|
Tony Graham wrote at 4 Jul 2003 23:22:50 +0100: > Dave Malcolm wrote at 4 Jul 2003 18:46:01 +0000: ... > > I'm guessing that it's a mismatch between the xmlroff version and > > the PangoPDF version; which version of PangoPDF should I be using? > > You should be using PangoPDF 1.2.3.0. ... > I'll have to find the bug and issue a PangoPDF 1.2.3.1. Done. 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 |
|
From: Dave M. <da...@da...> - 2003-07-05 02:09:16
|
> I've checked and the "datatype" and "area" header files haven't been
> copied up into the installation directory - should they have been?
(replying to my own mail)
I've tried manually creating "datatype" and "area" directories in the libfo include directory, and copying up *.h from the relevant untarred directories into them.
I now get the following errors when trying to build against libfo:
In file included from /usr/local/include/libfo-0.2/libfo/fo-doc.h:14,
from /usr/local/include/libfo-0.2/libfo/fo-xsl-formatter.h:16,
from /usr/local/include/libfo-0.2/libfo/fo-libfo.h:19,
from main.c:18:
/usr/local/include/libfo-0.2/datatype/fo-datatype.h:15:23: fo-object.h: No such file or directory
In file included from /usr/local/include/libfo-0.2/libfo/fo-doc.h:23,
from /usr/local/include/libfo-0.2/libfo/fo-xsl-formatter.h:16,
from /usr/local/include/libfo-0.2/libfo/fo-libfo.h:19,
from main.c:18:
/usr/local/include/libfo-0.2/area/fo-area.h:20:21: fo-node.h: No such file or directory
/usr/local/include/libfo-0.2/area/fo-area.h:21:22: fo/fo-fo.h: No such file or directory
In file included from /usr/local/include/libfo-0.2/area/fo-area.h:33,
from /usr/local/include/libfo-0.2/libfo/fo-doc.h:23,
from /usr/local/include/libfo-0.2/libfo/fo-xsl-formatter.h:16,
from /usr/local/include/libfo-0.2/libfo/fo-libfo.h:19,
from main.c:18:
/usr/local/include/libfo-0.2/area/fo-area-private.h:15:21: fo-node.h: No such file or directory
/usr/local/include/libfo-0.2/area/fo-area-private.h:16:29: fo-node-private.h: No such file or directory
/usr/local/include/libfo-0.2/area/fo-area-private.h:17:22: fo/fo-fo.h: No such file or directory
The problem header files have been included using quotes, rather than <> symbols.
Am I on the right track?
|
|
From: Dave M. <da...@da...> - 2003-07-05 01:59:27
|
I'm attempting to compile and link a program against libfo (using the
new xmlroff-0.2.3 tarball).
I've added a test to libfo-0.2 to my configure.in script; the libfo path
gets added to my includes.
My code tries to include libfo thus:
#include <libfo/fo-libfo.h>
Unfortunately, I get lots of errors:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -DORBIT2=1 -pthread
-I/usr/include/libxml2 -I/usr/include/libgnomeui-2.0
-I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0
-I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2
-I/usr/include/libbonoboui-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0
-I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/linc-1.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/X11R6/include
-I/usr/include/libglade-2.0 -I/usr/local/include/libfo-0.2
-I/usr/local/include -I/usr/include/libgnomeprint-2.2
-I/usr/include/libart-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/libxml2
-I/usr/include/pango-1.0 -I/usr/local/include/pangopdf/pango-1.0
-I/usr/include/freetype2 -I/usr/include/libgnomeprintui-2.2
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/X11R6/include
-DENABLE_PRINTING -DLOCALEDIR=\""/usr/local/share/locale"\"
-DDATADIR=\""/usr/local/share"\" -g -O2 -c main.c
In file included from
/usr/local/include/libfo-0.2/libfo/fo-xsl-formatter.h:16,
from /usr/local/include/libfo-0.2/libfo/fo-libfo.h:19,
from main.c:18:
/usr/local/include/libfo-0.2/libfo/fo-doc.h:14:34:
datatype/fo-datatype.h: No such file or directory
/usr/local/include/libfo-0.2/libfo/fo-doc.h:23:26: area/fo-area.h: No
such file or directory
In file included from
/usr/local/include/libfo-0.2/libfo/fo-xsl-formatter.h:16,
from /usr/local/include/libfo-0.2/libfo/fo-libfo.h:19,
from main.c:18:
/usr/local/include/libfo-0.2/libfo/fo-doc.h:86: parse error before '*'
token
/usr/local/include/libfo-0.2/libfo/fo-doc.h:86: warning: data definition
has no type or storage class
/usr/local/include/libfo-0.2/libfo/fo-doc.h:88: parse error before
"FoDatatype"
/usr/local/include/libfo-0.2/libfo/fo-doc.h:89: parse error before '*'
token
/usr/local/include/libfo-0.2/libfo/fo-doc.h:89: warning: data definition
has no type or storage class
/usr/local/include/libfo-0.2/libfo/fo-doc.h:91: parse error before
"FoDatatype"
/usr/local/include/libfo-0.2/libfo/fo-doc.h:151: parse error before
"FoArea"
/usr/local/include/libfo-0.2/libfo/fo-doc.h:155: parse error before
"FoArea"
I've checked and the "datatype" and "area" header files haven't been
copied up into the installation directory - should they have been?
Dave Malcolm
|
|
From: Dave M. <da...@da...> - 2003-07-05 01:34:25
|
On Fri, 2003-07-04 at 22:22, Tony Graham wrote: [snip] > It appears that pango-xsl-attributes.h isn't currently being > installed, yet I did manage to install it on 16th June. > > (It also appears that I like to install things at 46 minutes past the > hour.) > > I'll have to find the bug and issue a PangoPDF 1.2.3.1. > > In the meantime, you could manually install pango-xsl-attributes.h. I tried manually copying pango-xsl-attributes.h into the install path, and was then able to make and make install xmlroff successfully. Trying it out now... |
|
From: Tony G. <Ton...@Su...> - 2003-07-04 22:20:51
|
Dave Malcolm wrote at 4 Jul 2003 18:46:01 +0000: > I'm trying to build xmlroff-0.2.3 from the source tarball; I've > installed PangoPDF-1.2.3.0 (again, from the source tarball). Thanks for trying it out. > I'm getting this error message: > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"libfo\" > -I/usr/include/libxml2 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I.. -I../area -I../fo > -I../property -I../datatype -g -O2 > -I/usr/local/include/pangopdf/pango-1.0 -I/usr/include/freetype2 > -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/local/include > -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -Wall -c fo-doc-gp.c -MT fo-doc-gp.lo -MD -MP -MF .deps/fo-doc-gp.TPlo > -fPIC -DPIC -o fo-doc-gp.o > In file included from fo-doc-gp.c:11: > /usr/local/include/pangopdf/pango-1.0/pango/pangogp.h:36:40: > pango/pango-xsl-attributes.h: No such file or directory > > > I'm guessing that it's a mismatch between the xmlroff version and > the PangoPDF version; which version of PangoPDF should I be using? You should be using PangoPDF 1.2.3.0. This appears identical to a PangoPDF bug report that was posted yesterday [1]. The poster of the bug report has yet to respond to my questions about his system. Looking at my system (and omitting a few lines), this is what I have in /usr/local/include/pangopdf/pango-1.0: $ ls -tl /usr/local/include/pangopdf/pango-1.0/pango/ total 160 -rw-r--r-- 1 root root 2391 Jun 18 19:46 pangogp-context.h ... -rw-r--r-- 1 root root 4563 Jun 18 19:46 pangox.h -rw-r--r-- 1 root root 3374 Jun 16 10:46 pango-xsl-attributes.h It appears that pango-xsl-attributes.h isn't currently being installed, yet I did manage to install it on 16th June. (It also appears that I like to install things at 46 minutes past the hour.) I'll have to find the bug and issue a PangoPDF 1.2.3.1. In the meantime, you could manually install pango-xsl-attributes.h. 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 [1] https://sourceforge.net/tracker/index.php?func=detail&aid=765231&group_id=73149&atid=536905 |
|
From: Dave M. <da...@da...> - 2003-07-04 17:44:52
|
I'm trying to build xmlroff-0.2.3 from the source tarball; I've installed PangoPDF-1.2.3.0 (again, from the source tarball). I'm getting this error message: gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"libfo\" -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I.. -I../area -I../fo -I../property -I../datatype -g -O2 -I/usr/local/include/pangopdf/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/local/include -I/usr/include/libgnomeprint-2.2 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -Wall -c fo-doc-gp.c -MT fo-doc-gp.lo -MD -MP -MF .deps/fo-doc-gp.TPlo -fPIC -DPIC -o fo-doc-gp.o In file included from fo-doc-gp.c:11: /usr/local/include/pangopdf/pango-1.0/pango/pangogp.h:36:40: pango/pango-xsl-attributes.h: No such file or directory I'm guessing that it's a mismatch between the xmlroff version and the PangoPDF version; which version of PangoPDF should I be using? Thanks in advance Dave Malcolm |
|
From: Tony G. <Ton...@Su...> - 2003-07-04 17:10:46
|
xmlroff-0.2.3 is the first xmlroff release that does not need PDFlib. xmlroff is at http://xmlroff.sourceforge.net/. xmlroff-0.2.3 compiles and runs independently of PDFlib when you use the --disable-pdflib flag when you run configure. Similarly, it is independent of GNOME Print when you use --disable-gp. xmlroff defaults to using PDFlib instead of GNOME Print simply because prior versions supported only PDFlib output. The next release of xmlroff is expected to default to using GNOME Print and to require PDFlib support to be explicitly enabled if it is wanted. The xmlroff website is being updated as I write this. There's a new 'Making a Release' page on the xmlroff Wiki. Suggestions for improvements are welcome. Thanks to Charles Bozeman and Gerrit Haase for providing feedback about the CVS version (and to anyone else who tried it without reporting the lack of a problem). Solutions for the interdependency between PangoPDF and GNOME Print are welcome. 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 |
|
From: Tony G. <Ton...@Su...> - 2003-07-04 10:14:18
|
Charles Bozeman wrote at 2 Jul 2003 22:51:43 -0500: > I successfully compiled the latest CVS version of xmlroff. However the > latest CVS version of pangopdf is missing modules/indic/indic-ft2.c (I > retrieved it from the tarball and it worked). I haven't had time to do > any testing but it looks good so far. Thanks. I've added indic-ft2.c to CVS. 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 |
|
From: Charles B. <cbo...@hi...> - 2003-07-03 03:52:49
|
I successfully compiled the latest CVS version of xmlroff. However the latest CVS version of pangopdf is missing modules/indic/indic-ft2.c (I retrieved it from the tarball and it worked). I haven't had time to do any testing but it looks good so far. C. Bozeman On Wed, 2003-07-02 at 06:54, Tony Graham wrote: > The version of xmlroff currently in CVS compiles and runs without any > dependency on PDFlib if you use the --disable-pdflib flag when you run > configure. > > Similarly, it compiles and runs without GNOME Print if you use > --disable-gp. > > It currently defaults to using PDFlib instead of GNOME Print purely > because xmlroff originally used PDFlib. > > I intend to shortly release this version as xmlroff 0.2.3 (ideally on > July 4 -- Independence Day in the USA), and to follow that with an > xmlroff 0.3.0 that defaults to using GNOME Print and requires you to > enable PDFlib support if you want it. > > I would appreciate it if someone else could also try out the CVS > version before I package it up and announce it. > > 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 > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > xmlroff-list mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlroff-list -- Charles Bozeman <cbo...@hi...> |
2 messages has been excluded from this view by a project administrator.
