xmlroff-list

[xmlroff] Getting ready for next xmlroff release

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

I have made minor but useful improvements to fo:external-graphic support:

 - You don't need to specify content-width and content-height

 - Images appear in the right place instead of the top-left of the reference
   area

 - Images scale if you specify a different content-height or content-width,
   including specifying a percentage.

There is more work to be done on the multiple, interdependent properties of
fo:external-graphic, but I've done as much as I can do this month and still
get a release out "on or about the first of the month" since there's the
inevitable cleanup and documentation to do and new 'testsuite' and 'testing'
releases to do.

You are welcome to build from CVS to find bugs before I make them public.

Regards,


Tony.

Re: [xmlroff] Getting ready for next xmlroff release

[Stefan S. <se...@sy...>]

Tony Graham wrote:
> I have made minor but useful improvements to fo:external-graphic support:
> 
>  - You don't need to specify content-width and content-height
> 
>  - Images appear in the right place instead of the top-left of the reference
>    area
> 
>  - Images scale if you specify a different content-height or content-width,
>    including specifying a percentage.
> 
> There is more work to be done on the multiple, interdependent properties of
> fo:external-graphic, but I've done as much as I can do this month and still
> get a release out "on or about the first of the month" since there's the
> inevitable cleanup and documentation to do and new 'testsuite' and 'testing'
> releases to do.
> 
> You are welcome to build from CVS to find bugs before I make them public.

That's great news, and I will definitely try it out. Back to the

area split problem I was seeing: I'm not sure how to work around that,
as I don't know what it means, i.e. what input will trigger it.
Do you have any advise ? Do, by any chance, anobody here know what
kind of docbook construct will trigger it when using Norm's fo stylesheets ?

Many thanks,
		Stefan

Re: [xmlroff] Getting ready for next xmlroff release

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

Stefan Seefeld <se...@sy...> writes:
...
> That's great news, and I will definitely try it out. Back to the
>
> area split problem I was seeing: I'm not sure how to work around that,
> as I don't know what it means, i.e. what input will trigger it.
> Do you have any advise ? Do, by any chance, anobody here know what
> kind of docbook construct will trigger it when using Norm's fo stylesheets ?

Without having looked at the problem for a while, the code that directs that
areas should be split should recognise that it has previously tried to split
at the same height and failed in trying.  It should just put the unsplittable
areas on the page and move on to the next page.

That would require keeping track of the last attempted height (and possibly
the last FoArea that needed splitting) so it knows that it's a repeat.

Another problem that's been known to cause it, I think, is page-height="auto"
(or no page-height specified).

Regards,


Tony.

Re: [xmlroff] Getting ready for next xmlroff release

[Stefan S. <se...@sy...>]

Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:
> ...
> 
>>That's great news, and I will definitely try it out. Back to the
>>
>>area split problem I was seeing: I'm not sure how to work around that,
>>as I don't know what it means, i.e. what input will trigger it.
>>Do you have any advise ? Do, by any chance, anobody here know what
>>kind of docbook construct will trigger it when using Norm's fo stylesheets ?
> 
> 
> Without having looked at the problem for a while, the code that directs that
> areas should be split should recognise that it has previously tried to split
> at the same height and failed in trying.  It should just put the unsplittable
> areas on the page and move on to the next page.
> 
> That would require keeping track of the last attempted height (and possibly
> the last FoArea that needed splitting) so it knows that it's a repeat.
> 
> Another problem that's been known to cause it, I think, is page-height="auto"
> (or no page-height specified).

I see. Noting that you mentioned a redesign of the area-generating code was
on the TODO list, may I suggest that xmlroff does not attempt any splits at all
and generate an error message instead ?
That should be a QuickHack with the benefit of

a) still generating output so people can inspect *something* and
b) be a bit more clear (to users and potential developers) about what
    missing feature caused the error.

Thanks !
		Stefan

Re: [xmlroff] Getting ready for next xmlroff release

[Stefan S. <se...@sy...>]

Tony Graham wrote:

> You are welcome to build from CVS to find bugs before I make them public.

I'v hacked a quick 'return child;' into fo_area_page_size_request just to
get a little further.

I'm not sure whether this is a bug, but now I'm seeing:

(process:27752): libfo-CRITICAL **: Expression evaluation error: Expression not completely 
evaluated: '/ast.svg'
Object path: 
/FoTree[1]/root[1]/page-sequence[5]/flow[1]/FoBlockBlock[2]/FoBlockLayout[3]/external-graphic[1]

(process:27752): libfo-WARNING **: Unsupported property: (null)

(process:27752): libfo-CRITICAL **: file fo-uri-specification.c: line 235 
(fo_uri_specification_get_value): assertion `uri_specification != NULL' failed

The 'ast.svg' string above comes from an <fo:external-graphic src="images/ast.svg" .../>
element in the input file. It seems as if the content of the 'src' attribute isn't
formatted the way xmlroff expects it, and so all subsequent errors are a consequence
of that. What is going on here ? Is the input really incorrect ?

Thanks,
		Stefan

Re: [xmlroff] Getting ready for next xmlroff release

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> You are welcome to build from CVS to find bugs before I make them public.
>
> I'v hacked a quick 'return child;' into fo_area_page_size_request just to
> get a little further.
>
> I'm not sure whether this is a bug, but now I'm seeing:
>
> (process:27752): libfo-CRITICAL **: Expression evaluation error: Expression not completely 
> evaluated: '/ast.svg'
> Object path: 
> /FoTree[1]/root[1]/page-sequence[5]/flow[1]/FoBlockBlock[2]/FoBlockLayout[3]/external-graphic[1]
>
> (process:27752): libfo-WARNING **: Unsupported property: (null)
>
> (process:27752): libfo-CRITICAL **: file fo-uri-specification.c: line 235 
> (fo_uri_specification_get_value): assertion `uri_specification != NULL' failed
>
> The 'ast.svg' string above comes from an <fo:external-graphic src="images/ast.svg" .../>
> element in the input file. It seems as if the content of the 'src' attribute isn't
> formatted the way xmlroff expects it, and so all subsequent errors are a consequence
> of that. What is going on here ? Is the input really incorrect ?

According to the spec, yes, your input is incorrect.

The content of 'src' is <uri-specification>, which begins with 'url(' and ends
with ')'.

Regards,


Tony.

Re: [xmlroff] Getting ready for next xmlroff release

[Stefan S. <se...@sy...>]

Tony Graham wrote:

> According to the spec, yes, your input is incorrect.
> 
> The content of 'src' is <uri-specification>, which begins with 'url(' and ends
> with ')'.

I just found out that the current fo stylesheets for docbook will generate
the url() form when I undefine some parameters that I had defined before for
use with fop. Sorry for the noise.

xmlroff now segfaults again, this time in fo_area_size_request_default
(which may be related to my quick hack I described earlier).

I'll turn back to my own work now ;-), hoping that you will be able to sort
out the area management soon.

Many thanks for your great work !

Stefan