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.