Menu
▾
▴
xmlroff-list
|
From: Tony G. <Ton...@Su...> - 2006-02-13 20:21:23
|
I started the "What needs to be done to make xmlroff a success?" thread with a few words about the big picture for xmlroff, then the subsequent discussion brought out a few more big picture ideas. I would now like to revisit the big picture definition to incorporate current ideas into a one- or two-sentence "story" for xmlroff that could be used in the SourceForge project description and as the first thing on http://xmlroff.org so people immediately know what we're doing and where we're heading. Once the story is right, we can use that as a guide for what to do next with xmlroff. I previously wrote: > I would define the purpose of the xmlroff project as: > > To develop an open source, conformant, multilingual XSL formatter capable > of producing printable output from XML for most technical and business > documents. > > The project's principles are: > > - xmlroff should be free. > > - There's room in this world for more than one open source XSL formatter. > > - There's room in this world for open-source, free but not open, and > commercial XSL formatters. > > It's been a while since I've had this sort of conversation with myself, let > alone with anybody else, and I surprised myself by not mentioning C or GNOME. > > Given the above, a successful outcome for the project would be: > > A multilingual XSL formatter with conformantly implements the formatting > objects and properties necessary for formatting most technical and business > documents. And the big picture ideas from more than just me included: - Implement hyphenation - Improve TrueType/OpenType support - Provide a Windows port - Provide a Debian port - Be the best DocBook formatter on the planet - Support more graphics formats - Integrate with editors - Provide a SWIG interface for use from scripting languages (and if I omitted your favourite idea, feel free to comment.) To boil that down to as few words as possible, it looks to me like people want a high-quality, multi-platform formatter that excels at DocBook formatting and that integrates easily with other programs and with scripting languages. So how about that as the "story"? xmlroff is a high-quality, multi-platform XSL formatter that excels at DocBook formatting and that integrates easily with other programs and with scripting languages. Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2006-02-13 20:32:38
|
Tony Graham wrote: > To boil that down to as few words as possible, it looks to me like people want > a high-quality, multi-platform formatter that excels at DocBook formatting and > that integrates easily with other programs and with scripting languages. > > So how about that as the "story"? > > xmlroff is a high-quality, multi-platform XSL formatter that excels at > DocBook formatting and that integrates easily with other programs and with > scripting languages. That sounds good, though there is one important word amiss: 'free' ! There are a number of fo processors out there, but none is free. The only two contenders these days are xmlroff and fop. I'm not sure whether integration is really that big a point. As far as one-click behavior concerns, that's a feature for editors and other 'frontends' that would call into xmlroff. But xmlroff itself doesn't need to care, does it ? Regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2006-02-13 23:16:39
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: > >> To boil that down to as few words as possible, it looks to me like people want >> a high-quality, multi-platform formatter that excels at DocBook formatting and >> that integrates easily with other programs and with scripting languages. >> So how about that as the "story"? >> xmlroff is a high-quality, multi-platform XSL formatter that excels at >> DocBook formatting and that integrates easily with other programs and with >> scripting languages. > > That sounds good, though there is one important word amiss: 'free' ! I did later think of that. If it's on SourceForge, it's free by definition, but that would be so obvious on xmlroff.org, plus there's the lingering bad press from previously using PDFlib. > There are a number of fo processors out there, but none is free. The only > two contenders these days are xmlroff and fop. > > I'm not sure whether integration is really that big a point. As far as > one-click behavior concerns, that's a feature for editors and other 'frontends' > that would call into xmlroff. But xmlroff itself doesn't need to care, does it ? There's one-click behaviour and there's calling xmlroff from your program. If libfo can be called from another program, that's easier and more reliable (memory leaks excepted) than requiring the program to exec the xmlroff executable. If someone uses that to implement one-click formatting, then all the better. I was merely echoing what I saw from the previous discussions, but I do think it's useful to be able to run the formatter from more than just the command line. So the current candidate story becomes: xmlroff is a completely free, high-quality, multi-platform XSL formatter which excels at DocBook formatting that you can run as a standalone formatter or call from your own program. Or words to that effect. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2006-02-14 09:21:48
|
Tony Graham <Ton...@Su...> writes: ... > So the current candidate story becomes: > > xmlroff is a completely free, high-quality, multi-platform XSL formatter > which excels at DocBook formatting that you can run as a standalone > formatter or call from your own program. Or to narrow it to the sound bite: xmlroff aims to be the best DocBook formatter on the planet. Regards, Tony. |
|
From: Tony G. <Ton...@Su...> - 2006-02-16 23:35:10
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: > >> To boil that down to as few words as possible, it looks to me like people want >> a high-quality, multi-platform formatter that excels at DocBook formatting and >> that integrates easily with other programs and with scripting languages. >> So how about that as the "story"? >> xmlroff is a high-quality, multi-platform XSL formatter that excels at >> DocBook formatting and that integrates easily with other programs and with >> scripting languages. > > That sounds good, though there is one important word amiss: 'free' ! I changed the SourceForge project desciption to: xmlroff is a fast, free, high-quality, multi-platform XSL formatter that excels at DocBook formatting and that integrates easily with other programs and with scripting languages. Further suggestions for improvements are welcome. As is help towards living up to this description. Regards, Tony. |
|
From: Oliver K. <ok...@ya...> - 2006-02-14 11:10:52
|
Tony Graham wrote: > > And the big picture ideas from more than just me included: I would have thought that to make xmlroff a success, getting to a stage where libfo-compat.xsl is no longer needed would be most valuable. Or at least to the point where everything output by Norman Walsh's docbook-xsl stylesheet can be handled by xmlroff directly. Part of the problem is that many people trying xmlroff for the first time may not find libfo-compat.xsl until after they've been discouraged by the fact that the first .fo file they attempt to process results in a huge number of warnings, one critical error and no resulting .pdf. A manpage for xmlroff would be useful. It could also point people in the direction of libfo-compat.xsl. If it would help, I could write one. If so, do you prefer docbook or troff format (docbook is probably sensible but the Makefile would need to be able to turn it into troff). > - Provide a Windows port Are you thinking of a full port or just a Cygwin build? > - Integrate with editors I wouldn't make this much of a priority. If someone wants this for their favourite editor, they can easily do it themself. As to getting rid of PangoXSL, I wouldn't if it serves a real purpose. Building it is certainly an obstacle to anyone trying to use xmlroff but that can be more easily solved by producing Debian/Solaris etc packages. Do you have much dealing with the pango people. Any idea why it hasn't been merged? > So how about that as the "story"? > > xmlroff is a high-quality, multi-platform XSL formatter that excels at > DocBook formatting and that integrates easily with other programs and with > scripting languages. That'll do nicely for the package description that goes with the Debian package so thanks for that. I'd perhaps add the word "fast" in there too. Can you improve on the following description for pangoxsl. This is what I used in the initial Debian package: Package: libpangoxsl-1.0-0 Description: Additional XSL atttributes for Pango PangoXSL implements several of the inline properties defined by XSL that are not currently implemented by Pango. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. |
|
From: Tony G. <Ton...@Su...> - 2006-02-14 12:26:51
|
Oliver Kiddle <ok...@ya...> writes: > Tony Graham wrote: >> >> And the big picture ideas from more than just me included: > > I would have thought that to make xmlroff a success, getting to a stage > where libfo-compat.xsl is no longer needed would be most valuable. Or at > least to the point where everything output by Norman Walsh's docbook-xsl > stylesheet can be handled by xmlroff directly. Part of the problem is > that many people trying xmlroff for the first time may not find > libfo-compat.xsl until after they've been discouraged by the fact that > the first .fo file they attempt to process results in a huge number of > warnings, one critical error and no resulting .pdf. So another idea becomes: - (Optionally) cope silently with unsupported properties I have been pecking away at the problem (for the last year and a half, it seems) but haven't yet hooked up fo_libfo_context_set_warning_mode() to the right action to ignore unsupported properties. Still also need to work more on that critical error. > A manpage for xmlroff would be useful. It could also point people in the > direction of libfo-compat.xsl. If it would help, I could write one. If > so, do you prefer docbook or troff format (docbook is probably sensible > but the Makefile would need to be able to turn it into troff). xmlroff.fo tries for the format of a man page, but it is obviously not useful for `man xmlroff`. You could, however, use it as the basis of a real man page. >> - Provide a Windows port > > Are you thinking of a full port or just a Cygwin build? The details have yet to be worked out. We're still at the high-level, often-contradictory ideas stage. What is possible will depend on what is possible with GLib/GObject and Pango on Windows. >> - Integrate with editors > > I wouldn't make this much of a priority. If someone wants this for their > favourite editor, they can easily do it themself. > > As to getting rid of PangoXSL, I wouldn't if it serves a real purpose. > Building it is certainly an obstacle to anyone trying to use xmlroff but > that can be more easily solved by producing Debian/Solaris etc packages. > Do you have much dealing with the pango people. Any idea why it hasn't > been merged? My tardiness. xmlroff used PangoPDF before PangoXSL existed, and PangoPDF used PDFlib, which didn't have an open source compatible license. (I just looked at http://www.pdflib.com/ for the first time in years, and there's now a "pdflib-lite" that maybe could be used with open source, but I don't want to have to go down that road again.) >> So how about that as the "story"? >> >> xmlroff is a high-quality, multi-platform XSL formatter that excels at >> DocBook formatting and that integrates easily with other programs and with >> scripting languages. > > That'll do nicely for the package description that goes with the Debian > package so thanks for that. I'd perhaps add the word "fast" in there > too. Except that xmlroff is not yet multi-platform and does not yet excel at DocBook formatting. > Can you improve on the following description for pangoxsl. This is what > I used in the initial Debian package: > > Package: libpangoxsl-1.0-0 > Description: Additional XSL atttributes for Pango > PangoXSL implements several of the inline properties defined by XSL > that are not currently implemented by Pango. PangoXSL defines defines attributes for several XSL inline properties that are not currently implemented by Pango. It's a bit hard to say "implements" anymore since we got out of the "half-baked Pango port" business with the change from PangoPDF to PangoXSL. The only one that's currently used is the 'callback' attribute, which is used for external graphics, and the actual implementation of getting the graphic into the output is done in FoDocGP (since we're no longer in the "half-baked Pango port" business). Regards, Tony. > Oliver > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any > attachment and all copies and inform the sender. Thank you. The archive for this list is publicly accessible. If you intend any limit on who can read your posts, you are setting yourself up for disappointment. |
|
From: Stefan S. <se...@sy...> - 2006-02-14 12:54:35
|
Tony Graham wrote: > So another idea becomes: > > - (Optionally) cope silently with unsupported properties > > I have been pecking away at the problem (for the last year and a half, it > seems) but haven't yet hooked up fo_libfo_context_set_warning_mode() to the > right action to ignore unsupported properties. That sounds like a fine idea. In fact, the 'xmlroff' application as seen by users could be a frontend that first runs over libfo-compat.xsl to 'internalize' the tree. As xmlroff progresses, this preprocessing could be phased out. >>A manpage for xmlroff would be useful. It could also point people in the >>direction of libfo-compat.xsl. If it would help, I could write one. If >>so, do you prefer docbook or troff format (docbook is probably sensible >>but the Makefile would need to be able to turn it into troff). > > > xmlroff.fo tries for the format of a man page, but it is obviously not useful > for `man xmlroff`. You could, however, use it as the basis of a real man > page. Heh, why not write it in docbook ? :-) >>> - Provide a Windows port >> >>Are you thinking of a full port or just a Cygwin build? > > > The details have yet to be worked out. We're still at the high-level, > often-contradictory ideas stage. > > What is possible will depend on what is possible with GLib/GObject and Pango > on Windows. Out of curiosity: what is pangoxsl and what is its dependency on pango ? Is it a layer on top, a replacement, ore something else ? While I think that porting to cygwin may be reasonable (and not involve much work), I don't think that a native port is such a good idea at this time. It would definitely be useful, but it requires substantial work, and so I think focussing on missing features on a single platform (or set of platforms) will be more valuable in the short term. Regards, Stefan |
|
From: Stefan S. <se...@sy...> - 2006-02-14 14:53:24
|
Chris Bowditch wrote: > Stefan Seefeld wrote: > > >> While I think that porting to cygwin may be reasonable (and not involve >> much work), I don't think that a native port is such a good idea at this >> time. It would definitely be useful, but it requires substantial work, >> and so I think focussing on missing features on a single platform (or >> set of platforms) will be more valuable in the short term. > > > I disagree here. By implementing a complete port to Windows, a lot more > users will be attracted to xmlroff. More users, in turn means more > contributors, which in turn means more features for xmlroff. Well, this is a tradeoff, of course. But given the amount of work to do a full port, compared to the available work force, I believe it is much less efford (all relative, of course) to get xmlroff into a truely usable state where docbook et al. are more popular, and thus xmlroff would have a much bigger impact. On the other hand, if part of the efford to port xmlroff to windows-native is to strip off dependencies (such as glib and the whole GObject system), that would have multiple benefits. Regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2006-02-14 16:15:11
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: > >> So another idea becomes: >> - (Optionally) cope silently with unsupported properties >> I have been pecking away at the problem (for the last year and a half, it >> seems) but haven't yet hooked up fo_libfo_context_set_warning_mode() to the >> right action to ignore unsupported properties. > > That sounds like a fine idea. In fact, the 'xmlroff' application as seen > by users could be a frontend that first runs over libfo-compat.xsl to 'internalize' > the tree. As xmlroff progresses, this preprocessing could be phased out. Why didn't I think of that? There are good arguments for doing a whole host of normalising and validation in XSLT before making FoFo out of the FO. Things like verifying that fo:marker does not contain fo:marker or munging tables to put table cells in the right order and add any missing cells. The upside is that it should be quicker to write and easier to maintain than C code (but complex XSLT can become fairly impenetrable). The downside is that it's likely to be slower than C code and there's a limit to what you can do with validating property values since, theoretically, every property value can be a complex expression. However, I've never had the time to explore the possibility. >>>A manpage for xmlroff would be useful. It could also point people in the >>>direction of libfo-compat.xsl. If it would help, I could write one. If >>>so, do you prefer docbook or troff format (docbook is probably sensible >>>but the Makefile would need to be able to turn it into troff). >> xmlroff.fo tries for the format of a man page, but it is obviously not useful >> for `man xmlroff`. You could, however, use it as the basis of a real man >> page. > > Heh, why not write it in docbook ? :-) And use it as a test case. >>>> - Provide a Windows port >>> >>>Are you thinking of a full port or just a Cygwin build? >> The details have yet to be worked out. We're still at the high-level, >> often-contradictory ideas stage. >> What is possible will depend on what is possible with GLib/GObject and Pango >> on Windows. > > Out of curiosity: what is pangoxsl and what is its dependency on pango ? > Is it a layer on top, a replacement, ore something else ? In the bad old days (exactly five years ago) Pango did not play well with GNOME Print and Pango could only produce bitmaps for on-screen display. Having latched onto Pango as the way to format multilingual blocks of text, and not being impressed by the GNOME Print of the time irrespective of its incompatibilities w.r.t. fonts and everything else with the Pango of the time, I decided to write a PDF backend for Pango using an existing PDF library. I used PDFlib, which I thought at the time was sufficiently open to be compatible with Pango. That led to PangoPDF, which was only supposed to be temporary until I could get the PDF backend accepted by Pango, but that was never going to happen because of the license issue, which took me a long time to realise was an issue. I spent a lot of time keeping PangoPDF up to date with the current Pango and I implemented several XSL-specific properties for it, but much of the additional properties had to be discarded (long before xmlroff and PangoPDF became open source) when Pango changed from its own font selection mechanism to using fontconfig. PangoPDF gave rise to the long-standing impression of xmlroff using a half-baked port of Pango. Details are hazy, but I also implemented a GNOME Print backend for PangoPDF before Pango and GNOME Print officially worked together. When Pango and GNOME Print did finally work together, I got out of both the half-baked Pango port business and the proprietary backend business and gutted PangoPDF to make PangoXSL, which defines some additional PangoAttribute types on which xmlroff still depends. xmlroff depends on PangoXSL for the definition of some additional PangoAttribute types, and it actually uses one of those types. PangoXSL is not a replacement for Pango. If anything, it is a layer on top of Pango. > While I think that porting to cygwin may be reasonable (and not involve > much work), I don't think that a native port is such a good idea at this > time. It would definitely be useful, but it requires substantial work, > and so I think focussing on missing features on a single platform (or > set of platforms) will be more valuable in the short term. It seems like either would be possible. See http://www.gimp.org/~tml/gimp/win32/downloads.html Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2006-02-14 16:29:12
|
Tony Graham wrote: > Stefan Seefeld <se...@sy...> writes: > >>Tony Graham wrote: >> >> >>>So another idea becomes: >>> - (Optionally) cope silently with unsupported properties >>> I have been pecking away at the problem (for the last year and a half, it >>> seems) but haven't yet hooked up fo_libfo_context_set_warning_mode() to the >>> right action to ignore unsupported properties. >> >>That sounds like a fine idea. In fact, the 'xmlroff' application as seen >>by users could be a frontend that first runs over libfo-compat.xsl to 'internalize' >>the tree. As xmlroff progresses, this preprocessing could be phased out. > > > Why didn't I think of that? > > There are good arguments for doing a whole host of normalising and validation > in XSLT before making FoFo out of the FO. Things like verifying that > fo:marker does not contain fo:marker or munging tables to put table cells in > the right order and add any missing cells. > > The upside is that it should be quicker to write and easier to maintain than C > code (but complex XSLT can become fairly impenetrable). The downside is that > it's likely to be slower than C code and there's a limit to what you can do > with validating property values since, theoretically, every property value can > be a complex expression. > > However, I've never had the time to explore the possibility. Another good argument for integration is that it makes it possible to let xmlroff produce meaningful warnings / errors such as "this feature is only partly implemented right now, use flag --foo to use an alternate rendering" etc. You get the idea. The main point, again, is to make xmlroff more accessible to users yet keep the transparency so they can see what works and what not. >>Out of curiosity: what is pangoxsl and what is its dependency on pango ? >>Is it a layer on top, a replacement, ore something else ? [...lots of interesting history skipped...] > xmlroff depends on PangoXSL for the definition of some additional > PangoAttribute types, and it actually uses one of those types. > > PangoXSL is not a replacement for Pango. If anything, it is a layer on top of > Pango. Thanks for the explanation ! Is anybody else using / depending on pangoxsl ? I'm just wondering whether for the purpose of packaging it would be possible to bundle pangoxsl and xmlroff, so users don't have to care. >>While I think that porting to cygwin may be reasonable (and not involve >>much work), I don't think that a native port is such a good idea at this >>time. It would definitely be useful, but it requires substantial work, >>and so I think focussing on missing features on a single platform (or >>set of platforms) will be more valuable in the short term. > > > It seems like either would be possible. See > http://www.gimp.org/~tml/gimp/win32/downloads.html Oh, I didn't know that. A non-issue then, great ! Regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2006-02-14 17:53:34
|
Stefan Seefeld <se...@sy...> writes:
...
>> xmlroff depends on PangoXSL for the definition of some additional
>> PangoAttribute types, and it actually uses one of those types.
>> PangoXSL is not a replacement for Pango. If anything, it is a layer on top
>> of
>> Pango.
>
> Thanks for the explanation ! Is anybody else using / depending on pangoxsl ?
Nothing else.
> I'm just wondering whether for the purpose of packaging it would be possible
> to bundle pangoxsl and xmlroff, so users don't have to care.
There's the slight issue of licenses.
LGPL in PangoXSL could be seen as an continuation of LGPL in PangoPDF, which
was necessary because PangoPDF was a HBPP (half-baked Pango port, to further
institutionalise someone's passing comment). PangoPDF needed to be LGPL
because it did more than use Pango's public interfaces.
PangoXSL defines several structs which are very similar to the structs for
other PangoAttribute types that are defined in Pango's pango-attributes.h.
I really don't know whether the fact that PangoXSL uses only what's public in
pango-attributes.h would allow PangoXSL to use a different license or whether
it uses enough of pango-attributes.h that PangoXSL is definitely a derivative
work.
IANAL, but this paragraph from Section 5 of the LGPL gives some hope that
PangoXSL could be relicensed under a different license since PangoXSL really
only uses or reuses data structure layouts:
If such an object file uses only numerical parameters, data structure
layouts and accessors, and small macros and small inline functions (ten
lines or less in length), then the use of the object file is unrestricted,
regardless of whether it is legally a derivative work. (Executables
containing this object code plus portions of the Library will still fall
under Section 6.)
If it could be relicensed, then it could be included in the xmlroff
distribution.
Regards,
Tony.
|
|
From: Stefan S. <se...@sy...> - 2006-02-14 18:04:06
|
Tony Graham wrote: > If it could be relicensed, then it could be included in the xmlroff > distribution. I'm not sure I understand how it can make a difference license-wise whether you bundle PangoXSL and xmlroff into the same package or not. As long as the licenses are compatible, your package can include code distributed with as many different licenses as you want. Licenses typically talk about 'use' and 'link' etc., and that isn't affected at all by how you package things. Regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2006-02-20 10:16:34
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> If it could be relicensed, then it could be included in the xmlroff >> distribution. > > I'm not sure I understand how it can make a difference license-wise > whether you bundle PangoXSL and xmlroff into the same package or not. > As long as the licenses are compatible, your package can include code > distributed with as many different licenses as you want. > > Licenses typically talk about 'use' and 'link' etc., and that isn't > affected at all by how you package things. I think I finally understand your point. So how would you propose PangoXSL be bundled with xmlroff? How would it work for the SRPM package? Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2006-02-20 12:45:11
|
Tony Graham wrote: > Stefan Seefeld <se...@sy...> writes: > >>Tony Graham wrote: >> >>>If it could be relicensed, then it could be included in the xmlroff >>>distribution. >> >>I'm not sure I understand how it can make a difference license-wise >>whether you bundle PangoXSL and xmlroff into the same package or not. >>As long as the licenses are compatible, your package can include code >>distributed with as many different licenses as you want. >> >>Licenses typically talk about 'use' and 'link' etc., and that isn't >>affected at all by how you package things. > > > I think I finally understand your point. > > So how would you propose PangoXSL be bundled with xmlroff? > > How would it work for the SRPM package? Good question. if both modules are part of the same parent directory, may be that parent directory could contain some 'meta build system' that simply delegates to the subdirs for simple builds, but does a little more for packaging to avoid two distinct packages to be generated. I acknowledge this getting a bit involved, though... Regards, Stefan PS: Did you consider switching to subversion (which sf.net now supports) ? That would make it easier to modify a project's file system layout. |
|
From: Tony G. <Ton...@Su...> - 2006-02-20 18:06:12
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> Stefan Seefeld <se...@sy...> writes: >>>Tony Graham wrote: >>> >>>>If it could be relicensed, then it could be included in the xmlroff >>>>distribution. >>> >>>I'm not sure I understand how it can make a difference license-wise >>>whether you bundle PangoXSL and xmlroff into the same package or not. >>>As long as the licenses are compatible, your package can include code >>>distributed with as many different licenses as you want. >>> >>>Licenses typically talk about 'use' and 'link' etc., and that isn't >>>affected at all by how you package things. >> I think I finally understand your point. >> So how would you propose PangoXSL be bundled with xmlroff? >> How would it work for the SRPM package? > > Good question. if both modules are part of the same parent directory, > may be that parent directory could contain some 'meta build system' > that simply delegates to the subdirs for simple builds, but does > a little more for packaging to avoid two distinct packages to be > generated. I acknowledge this getting a bit involved, though... I don't know how to run nested autoconf (or whatever the term may be). It may be possible to copy the essential parts of PangoXSL's configure.ac into xmlroff's configure.in and just have xmlroff build PangoXSL. It would require some experimentation. > PS: Did you consider switching to subversion (which sf.net now supports) ? > That would make it easier to modify a project's file system layout. If Emacs works as well with subversion as it does with CVS. If it takes more than three keystrokes to check in a file, diff it, or get it's history, or if I can't run `ediff-revision' on a file, then it's not worth it for me to change. Where are the details for SourceForge's support for subversion? Regards, Tony. |
|
From: Stefan S. <se...@sy...> - 2006-02-20 18:24:43
|
Tony Graham wrote: > Stefan Seefeld <se...@sy...> writes: > >>Tony Graham wrote: >>>So how would you propose PangoXSL be bundled with xmlroff? >>>How would it work for the SRPM package? >> >>Good question. if both modules are part of the same parent directory, >>may be that parent directory could contain some 'meta build system' >>that simply delegates to the subdirs for simple builds, but does >>a little more for packaging to avoid two distinct packages to be >>generated. I acknowledge this getting a bit involved, though... > > > I don't know how to run nested autoconf (or whatever the term may be). I typically set up a 'autogen.sh' script that just runs autoheader, autoconf, etc. in a batch for all subprojects. A toplevel configure.ac script would simply call AC_CONFIG_SUBDIRS. > It may be possible to copy the essential parts of PangoXSL's configure.ac into > xmlroff's configure.in and just have xmlroff build PangoXSL. It would require > some experimentation. That may work, too, depending on how much conflicting options there are for both. If this works, it's even simpler. >>PS: Did you consider switching to subversion (which sf.net now supports) ? >> That would make it easier to modify a project's file system layout. > > > If Emacs works as well with subversion as it does with CVS. If it takes more > than three keystrokes to check in a file, diff it, or get it's history, or if > I can't run `ediff-revision' on a file, then it's not worth it for me to > change. I think all that works nicely (I'm not quite sure about ediff-revision, which I haven't used yet myself). The main visible differences are: * checkins are atomic, i.e. you get a list of all modified files that went into a checkin * file / directory renaming works as expected and transparently * subversion keeps a copy of the last checked-out version of all files on your disk, making it take up more space but allowing operations such as 'status' and 'diff' be much faster, and even work when you are offline > Where are the details for SourceForge's support for subversion? subversion support on sf.net is 'experimental', though I know a number of projects that have switched successfully there. (I'v been using subversion myself for a long time now.) Here are the docs: http://sourceforge.net/docs/E09/en/ Regards, Stefan |
|
From: Tony G. <Ton...@Su...> - 2006-02-20 23:48:00
|
Stefan Seefeld <se...@sy...> writes: > Tony Graham wrote: >> Stefan Seefeld <se...@sy...> writes: >> >>>Tony Graham wrote: > >>>>So how would you propose PangoXSL be bundled with xmlroff? >>>>How would it work for the SRPM package? >>> >>>Good question. if both modules are part of the same parent directory, >>>may be that parent directory could contain some 'meta build system' >>>that simply delegates to the subdirs for simple builds, but does >>>a little more for packaging to avoid two distinct packages to be >>>generated. I acknowledge this getting a bit involved, though... >> I don't know how to run nested autoconf (or whatever the term may be). > > I typically set up a 'autogen.sh' script that just runs autoheader, autoconf, > etc. in a batch for all subprojects. A toplevel configure.ac script would > simply call AC_CONFIG_SUBDIRS. Cool. I didn't know AC_CONFIG_SUBDIRS existed, but it makes sense that it does. >> It may be possible to copy the essential parts of PangoXSL's configure.ac into >> xmlroff's configure.in and just have xmlroff build PangoXSL. It would require >> some experimentation. > > That may work, too, depending on how much conflicting options there are for > both. If this works, it's even simpler. I think that AC_CONFIG_SUBDIRS would make it easier to keep the two separate. >>>PS: Did you consider switching to subversion (which sf.net now supports) ? >>> That would make it easier to modify a project's file system layout. >> If Emacs works as well with subversion as it does with CVS. If it takes more >> than three keystrokes to check in a file, diff it, or get it's history, or if >> I can't run `ediff-revision' on a file, then it's not worth it for me to >> change. > > I think all that works nicely (I'm not quite sure about ediff-revision, which > I haven't used yet myself). The main visible differences are: ediff-revision can be very useful. > * checkins are atomic, i.e. you get a list of all modified files that went > into a checkin > * file / directory renaming works as expected and transparently > * subversion keeps a copy of the last checked-out version of all files > on your disk, making it take up more space but allowing operations such > as 'status' and 'diff' be much faster, and even work when you are offline > >> Where are the details for SourceForge's support for subversion? > > subversion support on sf.net is 'experimental', though I know a number of > projects that have switched successfully there. (I'v been using subversion > myself for a long time now.) > > Here are the docs: > > http://sourceforge.net/docs/E09/en/ Thanks. I've read that, and I'm now reading "Subversion for CVS Users" at http://svnbook.red-bean.com/en/1.1/apa.html There's also hope for Emacs. See http://www.emacswiki.org/cgi-bin/wiki/SubVersion I think I'll try a local SubVersion project before switching xmlroff (or PangoXSL). Regards, Tony. |
|
From: Mauro C. <inc...@ya...> - 2006-02-14 17:44:19
|
--- Tony Graham <Ton...@Su...> ha scritto: > I started the "What needs to be done to make xmlroff > a success?" IMO a wrapper exetension for PHP and other scripting language. Mauro Casciari ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Stefan S. <se...@sy...> - 2006-02-14 17:47:20
|
Mauro C. wrote:
> --- Tony Graham <Ton...@Su...> ha scritto:
>
>
>>I started the "What needs to be done to make xmlroff
>>a success?"
>
>
> IMO a wrapper exetension for PHP and other scripting
> language.
What would that wrapper do that can't be done by calling
system('xmlroff ...') ?
Regards,
Stefan
|
|
From: Mauro C. <inc...@ya...> - 2006-02-14 17:54:46
|
--- Stefan Seefeld <se...@sy...> ha scritto:
> Mauro C. wrote:
> > --- Tony Graham <Ton...@Su...> ha scritto:
> >
> >
> >>I started the "What needs to be done to make
> xmlroff
> >>a success?"
> >
> >
> > IMO a wrapper exetension for PHP and other
> scripting
> > language.
>
> What would that wrapper do that can't be done by
> calling
> system('xmlroff ...') ?
better control on error handling, maybe performance.
>
> Regards,
> Stefan
Mauro Casciari
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
|
|
From: Tony G. <Ton...@Su...> - 2006-02-16 22:59:55
|
Stefan Seefeld <se...@sy...> writes:
> Mauro C. wrote:
>> --- Tony Graham <Ton...@Su...> ha scritto:
>>>I started the "What needs to be done to make xmlroff
>>>a success?"
>> IMO a wrapper exetension for PHP and other scripting
>> language.
>
> What would that wrapper do that can't be done by calling
> system('xmlroff ...') ?
If the scripting language's XML DOM implementation is a thin layer over
libxml2's XMLdoc, then it becomes possible to pass a DOM straight to the
thinly wrapped libfo.
Regards,
Tony.
|
|
From: Stefan S. <se...@sy...> - 2006-02-16 23:15:32
|
Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:
>
>>Mauro C. wrote:
>>
>>>--- Tony Graham <Ton...@Su...> ha scritto:
>>>
>>>>I started the "What needs to be done to make xmlroff
>>>>a success?"
>>>
>>>IMO a wrapper exetension for PHP and other scripting
>>>language.
>>
>>What would that wrapper do that can't be done by calling
>>system('xmlroff ...') ?
>
>
> If the scripting language's XML DOM implementation is a thin layer over
> libxml2's XMLdoc, then it becomes possible to pass a DOM straight to the
> thinly wrapped libfo.
I understand that. What I fail to see is that there is indeed a need for
this level of optimization (or whatever else a programmatic interface to
libfo provides), at this time.
I don't doubt that this is nice-to-have. What I'm not sure about is whether
it really deserves to be on a wishlist for xmlroff when other items such
as feature-completeness should figure with far more scores in terms of
priority.
The user of such an API still needs to preprocess his dom tree (possibly by
means of the libxslt API by Daniel Veillard) to apply the libfo-compat.xsl
stylesheet, right ?
Regards,
Stefan
|
|
From: Tony G. <Ton...@Su...> - 2006-02-17 00:35:56
|
Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> Stefan Seefeld <se...@sy...> writes:
>>
>>>Mauro C. wrote:
>>>
>>>>--- Tony Graham <Ton...@Su...> ha scritto:
>>>>
>>>>>I started the "What needs to be done to make xmlroff
>>>>>a success?"
>>>>
>>>>IMO a wrapper exetension for PHP and other scripting
>>>>language.
>>>
>>>What would that wrapper do that can't be done by calling
>>>system('xmlroff ...') ?
>> If the scripting language's XML DOM implementation is a thin layer over
>> libxml2's XMLdoc, then it becomes possible to pass a DOM straight to the
>> thinly wrapped libfo.
>
> I understand that. What I fail to see is that there is indeed a need for
> this level of optimization (or whatever else a programmatic interface to
> libfo provides), at this time.
Some people on this list do want that (and if they can help in implementing
it, so much the better), and it was among the most emphatic responses to the
question of how to make xmlroff a success.
You (AFAICT) and I don't use Windows much if at all, yet we are discussing not
whether but how to do a Windows version of xmlroff. Not because we want to
use xmlroff on Windows ourselves, but because it could put xmlroff in front of
more people, in the hope that some of them will be enamoured/exasperated
enough with xmlroff to want to improve it.
The same argument can be applied to a SWIG wrapper over fo-libfo-basic.h.
While you're not convinced of the necessity, you can just put it down to the
"feel good" factor for script programmers: if it looks like it's built into
the language, they're more likely to use it, so they're more likely to be
enamoured/exasperated enough with xmlroff to want to improve it.
Regards,
Tony.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X