xmlroff-list — xmlroff XSL formatter discussion list

[xmlroff] PangoXSL license? [Was: xmlroff's "story"?]

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

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.

Re: [xmlroff] xmlroff's "story"?

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

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

Re: [xmlroff] xmlroff's "story"?

[Mauro C. <inc...@ya...>]

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

Re: [xmlroff] xmlroff's "story"?

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

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

Re: [xmlroff] xmlroff's "story"?

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

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.

Re: [xmlroff] xmlroff's "story"?

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

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

Re: [xmlroff] xmlroff's "story"?

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

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

Re: [xmlroff] xmlroff's "story"?

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

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.

Re: [xmlroff] xmlroff's "story"?

[Oliver K. <ok...@ya...>]

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.

Re: [xmlroff] xmlroff's "story"?

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

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.

Re: [xmlroff] xmlroff's "story"?

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

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.

Re: [xmlroff] make testing more accessible to contributors

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

Tony Graham wrote:

> Something like the DocBook 'docbook-testdocs' package [1] run through the
> DocBook stylesheets and libfo-compat.xsl?
> 
> If we are going to want to become the best little DocBook formatter on the
> planet, that would be one place to start.
> 
> Regards,
> 
> 
> Tony.
> 
> [1] http://sourceforge.net/project/shownotes.php?release_id=98501&group_id=21935

Excellent ! I'll have a look at it tonight...

Thanks,
		Stefan

Re: [xmlroff] xmlroff's "story"?

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

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

Re: [xmlroff] make testing more accessible to contributors

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> Stefan Seefeld <se...@sy...> writes:
>>
>>>When trying to confine a bug I tried to first see whether it was already
>>>covered by an existing test. Unfortunately, I found the existing test
>>>infrastructure a bit confusing / hard to use.
>>>
>>>Is there anything that could be done to make that easier ? Ideally
>>>I would only need to have to check out an additional module (not two !)
>>>and then run 'make check' (or similar) in it.
>>>I did glance over some READMEs both in 'testsuite' as well as 'testing',
>>>but couldn't quite get it to work.
>> Are you still stuck?
>
> Sorry, haven't had time to look at it again after your explanations.
> The reason I asked originally was because I was looking for some test
> case I could use to find out whether some issues I observed with my own
> document were known / expected.
>
> Meanwhile I get my answer without looking at the test suite.
>
> I still think that the test suite is important not only to developers,
> but also to users who want to know what they can expect from xmlroff.
> However, for the latter it would be best if features were expressed in
> terms of their own language, e.g. docbook constructs that would fail,
> instead of fo (which most users only care little about).
>
> However, I can understand that it is out of the scope for xmlroff, and
> you in particular, to set up a list of such issues.
> Or may be it is some combination of the existing test suite results
> with the filtering done by libfo-compat.xsl...

Something like the DocBook 'docbook-testdocs' package [1] run through the
DocBook stylesheets and libfo-compat.xsl?

If we are going to want to become the best little DocBook formatter on the
planet, that would be one place to start.

Regards,


Tony.

[1] http://sourceforge.net/project/shownotes.php?release_id=98501&group_id=21935

Re: [xmlroff] Re: Debian xmlroff package

[Oliver K. <ok...@ya...>]

Tony Graham wrote:
> Where does the configure script depend on libxml2?

Sorry. Seems I'm wrong. I must have run xmlroff's configure by mistake
when I was determining dependencies.

> When the libxml2 issue is sorted out, I'll make a new PangoXSL release with
> the correct license, and that will have config.guess and config.sub from
> automake 1.8, since that's what I have installed.

1.8 is really quite old. The lastest is here:
http://ftp.gnu.org/pub/gnu/automake/automake-1.9.6.tar.bz2

If you've not already done it, don't forget the make distclean removing
config.log too, thanks.

Cheers

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.

[xmlroff] xmlroff's "story"?

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

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.

Re: [xmlroff] make testing more accessible to contributors

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

Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:
> 
>>When trying to confine a bug I tried to first see whether it was already
>>covered by an existing test. Unfortunately, I found the existing test
>>infrastructure a bit confusing / hard to use.
>>
>>Is there anything that could be done to make that easier ? Ideally
>>I would only need to have to check out an additional module (not two !)
>>and then run 'make check' (or similar) in it.
>>I did glance over some READMEs both in 'testsuite' as well as 'testing',
>>but couldn't quite get it to work.
> 
> 
> Are you still stuck?

Sorry, haven't had time to look at it again after your explanations.
The reason I asked originally was because I was looking for some test
case I could use to find out whether some issues I observed with my own
document were known / expected.

Meanwhile I get my answer without looking at the test suite.

I still think that the test suite is important not only to developers,
but also to users who want to know what they can expect from xmlroff.
However, for the latter it would be best if features were expressed in
terms of their own language, e.g. docbook constructs that would fail,
instead of fo (which most users only care little about).

However, I can understand that it is out of the scope for xmlroff, and
you in particular, to set up a list of such issues.
Or may be it is some combination of the existing test suite results
with the filtering done by libfo-compat.xsl...

Regards,
		Stefan

Re: [xmlroff] What needs to be done to make xmlroff a success?

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

"Gerrit P. Haase" <ge...@fa...> writes:
> - Emacs / Xemacs integration.
> - OpenOffice integration
> - More editor integration (Nedit, ....)
> - Standalone FOP editor with xmlroff integration?
>
> So I could edit a FOP document and with one click I get the PDF.

It sounds like you want Conglomerate: http://www.conglomerate.org/

Regards,


Tony.

Re: [xmlroff] Re: Debian xmlroff package

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

Oliver Kiddle <ok...@ya...> writes:
...
> Does PangoXSL's configure script need to check for libxml2? The library

Where does the configure script depend on libxml2?

> doesn't appear to actually link to libxml2. Also, make distclean should
> remove config.log and it'd be nice if the config.guess and config.sub
> files were updated with newer versions.

When the libxml2 issue is sorted out, I'll make a new PangoXSL release with
the correct license, and that will have config.guess and config.sub from
automake 1.8, since that's what I have installed.

Regards,


Tony.

Re: [xmlroff] Re: Debian xmlroff package

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

Please either subscribe or post from the address from which you subscribed.

Oliver Kiddle <ok...@ya...> writes:
> I wrote:
>> I maintain one other Debian package so could try to produce one for
>> xmlroff if nobody else is planning to do it.
>
> I've just had a look at what it would involve.
>
> PangoXSL appears to be released under the GPL and, if my understanding

That surprised me, so I checked.

In my definitive PangoXSL workspace, COPYING was a link to
/usr/share/automake-1.8/COPYING.  There was no COPYING in CVS.  I have now
checked in the LGPL licence.

I conclude that there wasn't a COPYING file the first time that I ran the
autotools so automake helpfully provided one without my noticing.  Talk about
viral licensing.

The 'pangopdf' project on SourceForge has always been listed as LGPL.

> is correct, that means that xmlroff can't be linked against it unless it
> to was released under the GPL. Would it perhaps make sense to re-licence
> PangoXSL under the LGPL. Apart from anything else, that could help
> achieve the stated objective of PangoXSL - to be merged with Pango -
> given that Pango itself is released under the LGPL.

The previous inclusion of GPL license text was an administrative oversight.

> I think the strange nuclear clause in the xmlroff licence is not a
> problem for Debian inclusion assuming that the intention is to disclaim
> warranty rather than to discriminate against people running nuclear
> facilities by not letting them use the software. I'll need to check on
> this, though.

The "strange nuclear clause" is in the BSD-style license under which Sun
released xmlroff to open source.

> Does PangoXSL's configure script need to check for libxml2? The library

Probably not.  It may be a hangover from either PangoPDF or xmlroff.

> doesn't appear to actually link to libxml2. Also, make distclean should
> remove config.log and it'd be nice if the config.guess and config.sub
> files were updated with newer versions.
>
> Anyway, an initial package for pangoxsl is at:
>   http://www.geocities.com/okiddle/pangoxsl.zip
> Would be good if anyone has a chance to look at it and see if they can
> make any improvements. Sorry for using zip - geocities is fussy. The zip
> file contains the package source and i386 .debs.

I don't use Debian, so I'm no use for checking it.

Regards,


Tony.

[xmlroff] Re: Debian xmlroff package

[Oliver K. <ok...@ya...>]

I wrote:
> I maintain one other Debian package so could try to produce one for
> xmlroff if nobody else is planning to do it.

I've just had a look at what it would involve.

PangoXSL appears to be released under the GPL and, if my understanding
is correct, that means that xmlroff can't be linked against it unless it
to was released under the GPL. Would it perhaps make sense to re-licence
PangoXSL under the LGPL. Apart from anything else, that could help
achieve the stated objective of PangoXSL - to be merged with Pango -
given that Pango itself is released under the LGPL.

I think the strange nuclear clause in the xmlroff licence is not a
problem for Debian inclusion assuming that the intention is to disclaim
warranty rather than to discriminate against people running nuclear
facilities by not letting them use the software. I'll need to check on
this, though.

Does PangoXSL's configure script need to check for libxml2? The library
doesn't appear to actually link to libxml2. Also, make distclean should
remove config.log and it'd be nice if the config.guess and config.sub
files were updated with newer versions.

Anyway, an initial package for pangoxsl is at:
  http://www.geocities.com/okiddle/pangoxsl.zip
Would be good if anyone has a chance to look at it and see if they can
make any improvements. Sorry for using zip - geocities is fussy. The zip
file contains the package source and i386 .debs.

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.

Re: [xmlroff] What needs to be done to make xmlroff a success?

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

Tony Graham <Ton...@Su...> writes:
> Tony Graham <Ton...@Su...> writes:
> ...
>>    What needs to be done to make xmlroff a success?
...
> I'm just looking for ideas at this point.
> 
>  - What would it take for xmlroff to become the first thing you load onto your
>    computer after the OS?
> 
>  - What would it take for you to junk your current word processor or
>    formatting system in favour of XSL-FO and xmlroff?
> 
>  - What would it take for xmlroff to be your tool of choice for formatting
>    XML?

This is the last (hopefully) list before we act on some of these...

 - Implement...

 - Implement region-before, region-after, etc.

 - Implement markers

 - Implement hyphenation

 - Improve TrueType/OpenType support

 - Provide RPMs as well as SRPMs and .tar.gz downloads

 - Provide a Windows port

 - Provide a Debian port

 - Provide a Solaris port

 - Improve developer documentation

 - Improve end-user documentation

 - Rewrite in a more OO language

 - Rewrite in...

 - Rewrite in D

 - Rewrite in C++

 - Keep it in C

 - Lose the reliance on GLib/GObject

 - Get rid of PangoXSL

 - Sack the maintainer

 - Put the statement of purpose on the xmlroff web page

 - Counteract outdated negative perceptions from when xmlroff used PDFlib

 - Be the best DocBook formatter on the planet

 - Support more graphics formats

 - Support PNG with alpha in PDF

 - Support TIFF with ICC colour profiles in PDF

 - Support SVG graphics

 - Produce output in...

 - Produce output in SVG

 - Document current graphic and output capabilities

 - Integrate with editors

 - Provide one-click formatting from within an editor

 - Provide a SWIG interface for use from scripting languages

 - Replace current JNI interface with SWIG

 - Make an Ant task for running xmlroff from Ant build files

 - Make it easier to add and run tests

 - Put a statement of purpose on the main web page

 - Replace the "Implementation Plan" page on the website

Regards,


Tony.

Re: [xmlroff] make testing more accessible to contributors

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

Stefan Seefeld <se...@sy...> writes:
> When trying to confine a bug I tried to first see whether it was already
> covered by an existing test. Unfortunately, I found the existing test
> infrastructure a bit confusing / hard to use.
>
> Is there anything that could be done to make that easier ? Ideally
> I would only need to have to check out an additional module (not two !)
> and then run 'make check' (or similar) in it.
> I did glance over some READMEs both in 'testsuite' as well as 'testing',
> but couldn't quite get it to work.

Are you still stuck?

Regards,


Tony.

[xmlroff] Re: Debian xmlroff package

[Oliver K. <ok...@ya...>]

Noah Slater wrote:
> Are there any Debian users on the list willing to make an ITP (Intent
> To Package) for this software and ultimately becoming the downstream
> maintainer of the package?

There is an old ITP that became an RFP:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182445

To what extent have things changed since the message by Bart Schuller?
I'm assuming the pdflib issue is gone but the "half done fork of pango"
is still an issue.

I maintain one other Debian package so could try to produce one for
xmlroff if nobody else is planning to do it.

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.

Re: [xmlroff] Errors with libfo

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

Noah Slater <ns...@gm...> writes:
> Actually, I tried this and xmlroff segfaults. If you need a dump of
> some sort I would be happy to oblige - just tell me what command to
> run.

Please file a bug on SourceForge and include or attach the error messages and
the FO file.  Quote at least part of the most significant error message in the
bug title.

Of course, if a bug was filed for every DocBook document that xmlroff couldn't
process, there'd be an infinite list of bug reports, but while there's only a
few reports, it's easy enough to keep track of.

Regards,


Tony.

> Thanks,
> Noah
>
> On 1/31/06, Tony Graham <Ton...@su...> wrote:
>> Noah Slater <ns...@gm...> writes:
>> > Trying to run xmlroff against a simple fo file results in lots of
>> > errors and then aborts.
>>
>> If you run the FO file through libfo-compat.xsl you will get far fewer error
>> messages.
>>
>> It looks like xmlroff will still fail, but it should be simpler to work out
>> why after you've removed the unsupported properties.
>>
>> Regards,
>>
>>
>> Tony.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> xmlroff-list mailing list
>> xml...@li...
>> https://lists.sourceforge.net/lists/listinfo/xmlroff-list
>>
>
>
> --
> "Creativity can be a social contribution, but only in so
> far as society is free to use the results." - R. Stallman
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> xmlroff-list mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlroff-list