Re: [xmlroff] Plan for xmlroff 0.3.7

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> xmlroff 0.3.6 is almost ready, despite Stefan's efforts to remind me of
>> essential features.
>
> I'm sorry, I didn't mean to block a release. Instead, I tried to find spots
> where I could help, even with my lack of understanding of the xsl-fo internals.

You didn't block a release.  I doubt that you've even delayed it.  And your
contributions are useful.

> I do agree that the current handling of the src attribute in external graphic
> already covers the majority of all cases, thus greatly enhancing the functionality
> of xmlroff.

Except the base URI evaporates if you run the input XML through a stylesheet.
I still have to think about that one.

>> It is, I think, simple and obvious to continue with fo:external-graphic
>> improvements for xmlroff 0.3.7.
>> The tasks for xmlroff 0.3.7 as I see them are:
>>  - Support 'http:' (and other) protocols in URI specifications
>
> I may have a look at that.

You would be welcome.

>>  - Improve handling unresolvable 'src' URI specifications (to be done after
>>    'http:' support)
>
> What do you imagine to happen ? Drop in a fallback graphic ? Do nothing in
> the generated document but print out a warning / error ?

You obviously haven't tried an unresolvable 'src' URI recently.

A comprehensible warning message and avoiding the current numerous failed
assertion messages would be a start.  I haven't thought much beyond that.

>>  - Handle more fo:external-graphic properties and handle their
>>    interdependencies:
>>     - Handle when one of 'content-width' or 'content-height' is specified
>
> What is the expected behavior ? To stretch / shrink the image to fit ?

If one is non-auto and the other is 'auto', the 'auto' one uses the same scale
factor.

The spec explains most of it fairly well, except the fo:external-graphic
explanation omits mention of the effect of 'scaling-method'.

>>     - Handle 'scale' attribute
>>    It would be good to also handle non-auto ipd and bpd and 'display-align'
>>    and 'text-align' but that will take more effort.
>>  - Add a FoImageManager or similar so the same image isn't opened multiple
>>    times
>
> I may look into that.

It should be pretty simple.  If should be pretty similar to the hashing in
FoColor, except for reasons I can't articulate, I want a separate class for
this rather than hiding the existence of the hashing ability.

The FoImageManager should also have a 'reset' function that flushes the cache,
which would be called at the end of document processing.

>>  - Handle areas that can't be broken
>
> Yes, please !

If I can lure you or other people into working on the other pieces with my
help, I can work on this.

Regards,


Tony.