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