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