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.