xmlroff-list

[xmlroff] [ANN] xmlroff 0.3.7

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

xmlroff 0.3.7 is now available from http://sourceforge.net/projects/xmlroff.

This is a development snapshot, to put it politely, so there's a release "on
or about the first of the month".

xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into
an infinite loop when it can't fit something on a page.  xmlroff doesn't go
into an infinite loop anymore; it just happens to not render the problematic
area at all.

Unfortunately, I won't have much time to work on xmlroff until at least the
middle of the month, so if there was going to be a monthly release for
November, this was the best I can do.

When the problem is fixed, there'll be a release that doesn't have to be
labelled as a "development snapshot".

Regards,


Tony.



Changes between 0.3.6 and 0.3.7

* Corrected placement of fo:external-graphic if not first on line
* Added setting pixels-per-inch (for graphics without intrinsic size)
  as configure option
* Working on averting endless loop if area won't fit on page.


Changes:
2005-11-02  Tony Graham  <ton...@us...>

	* === Released 0.3.7 ===

	* NEWS: Updated for 0.3.7.

	* area/fo-area-viewport-reference.c: Removed unnecessary #includes.

	* area/fo-area-viewport-reference-private.h: Added a #include.

	* area/fo-area-page.c: Removed unused variables and #include.

	* Makefile.am: Added 'srpm' target for making SRPM.

	* configure.in, libfo/fo-doc-gp.c: Added --disable-clip configure
	option to turn off clipping in fo-doc-gp.c.

2005-10-11  Tony Graham  <ton...@us...>

	* libfo-compat.xsl: Added changing all keeps below a threshold
	value to 'auto' since numeric keeps currently not supported.

	* libfo/fo-doc-gp.c: More futzing with PANGO_SCALE so images
	appear in right place.

2005-10-02  Tony Graham  <ton...@us...>

	* area/fo-area-page.c: Working on averting endless loop if area
	won't fit on page.

	* configure.in, datatype/fo-length.c, libfo/fo-doc-gp.c: Added
	PIXEL_PER_INCH to configure.in so it appears in config.h.

	* area/fo-area-list-item.c, area/fo-area-private.h,
	area/fo-area.c: Started adding split_after_height() and
	split_after_height_check() functions.

	* datatype/fo-uri-specification.c: Removed unnecessary statement
	left over from creating file by copying another file.

	* libfo/fo-doc-private.h: Removed unnecessary includes.

	* util/fo-hash-table.c, util/fo-pixbuf.c: Updated doc comments.

	* area/fo-area-area.c: Reformatted.

	* area/fo-area-table.c: Renamed some variables to make them easier
	to read.

2005-09-16  Tony Graham  <ton...@us...>

	* util/Makefile.am, libfo/fo-doc-gp.c, util/fo-image-private.h,
	util/fo-image.c, util/fo-pixbuf.c, util/fo-pixbuf.h: Added
	FoPixbuf interface for getting GdkPixbuf from images instead of
	using fo-image-private.h.

	* configure.in: Upped version to 0.3.7.

	* .cvsignore: List of files to ignore when doing 'cvs diff', etc.

Re: [xmlroff] [ANN] xmlroff 0.3.7

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

Tony Graham wrote:
> xmlroff 0.3.7 is now available from http://sourceforge.net/projects/xmlroff.
> 
> This is a development snapshot, to put it politely, so there's a release "on
> or about the first of the month".
> 
> xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into
> an infinite loop when it can't fit something on a page.  xmlroff doesn't go
> into an infinite loop anymore; it just happens to not render the problematic
> area at all.

Tony,

thanks for all your work. It is very much appreciated !
Now I should do my part and work, as I promized, on a dictionary for external
graphics.

Kind regards,
		Stefan

Re: [xmlroff] [ANN] xmlroff 0.3.7

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> xmlroff 0.3.7 is now available from http://sourceforge.net/projects/xmlroff.
>> This is a development snapshot, to put it politely, so there's a release "on
>> or about the first of the month".
>> xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go
>> into
>> an infinite loop when it can't fit something on a page.  xmlroff doesn't go
>> into an infinite loop anymore; it just happens to not render the problematic
>> area at all.
>
> Tony,
>
> thanks for all your work. It is very much appreciated !

Wow.  I should make disfunctional releases more often.

This release is even more than usual a "work in progress" (and as Stefan's
next message showed, even more of a work in progress than I had considered
it).

> Now I should do my part and work, as I promized, on a dictionary for external
> graphics.

Great.  Let me know if you have any questions.

Regards,


Tony.

Re: [xmlroff] [ANN] xmlroff 0.3.7

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

The libfo-compat.xsl file contains a number of typos, which
the attached patch tries to fix.

Regards,
		Stefan

Re: [xmlroff] [ANN] xmlroff 0.3.7

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

Stefan Seefeld <se...@sy...> writes:
> The libfo-compat.xsl file contains a number of typos, which
> the attached patch tries to fix.

Thanks.  I'll commit the change shortly (or you can do it).

Regards,


Tony.

Re: [xmlroff] [ANN] xmlroff 0.3.7

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

Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:
> 
>>The libfo-compat.xsl file contains a number of typos, which
>>the attached patch tries to fix.
> 
> 
> Thanks.  I'll commit the change shortly (or you can do it).

Done.

Regards,
		Stefan

Please try CVS version [Was: [xmlroff] [ANN] xmlroff 0.3.7]

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

Tony Graham <Ton...@Su...> writes:
...
> xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into
> an infinite loop when it can't fit something on a page.  xmlroff doesn't go
> into an infinite loop anymore; it just happens to not render the problematic
> area at all.
>
> Unfortunately, I won't have much time to work on xmlroff until at least the
> middle of the month, so if there was going to be a monthly release for
> November, this was the best I can do.

I had some time on the train into the office (which is how I get most of the
time that I can spend on xmlroff), and both got the problematic overflowing
area to render and implemented the 'overflow' property for region-body so the
overflowing area can be clipped.

Please try the current code in CVS to see whether it is functional enough to
be worth making another release.

Regards,


Tony.

Re: Please try CVS version [Was: [xmlroff] [ANN] xmlroff 0.3.7]

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

Tony Graham wrote:
> Tony Graham <Ton...@Su...> writes:
> ...
> 
>>xmlroff 0.3.7 fulfills the letter of Stefan's request that xmlroff not go into
>>an infinite loop when it can't fit something on a page.  xmlroff doesn't go
>>into an infinite loop anymore; it just happens to not render the problematic
>>area at all.
>>
>>Unfortunately, I won't have much time to work on xmlroff until at least the
>>middle of the month, so if there was going to be a monthly release for
>>November, this was the best I can do.
> 
> 
> I had some time on the train into the office (which is how I get most of the
> time that I can spend on xmlroff), and both got the problematic overflowing
> area to render and implemented the 'overflow' property for region-body so the
> overflowing area can be clipped.
> 
> Please try the current code in CVS to see whether it is functional enough to
> be worth making another release.

I get a segmentation fault after lots of 'libfo-CRITICAL' messages. The first
one is

(process:12015): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page: 
FoAreaPage (0x9e8ddb8 : 2); child: FoAreaViewportReference (0x9e8dcb8 : 1)

which I assume your latest work was meant to resolve. Right ?

The second such message looks like an identical copy of the first, but the third
one is strange again:

(process:12015): 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]

The expression in question seems to stem from an external-graphic attribute
src="images/ast.svg". I thought xmlroff is able to deal with such paths. Do I remember
wrongly ?

The last errors, which appear to have caused the actual segfault, are assertion errors
such as:

(process:12015): libfo-CRITICAL **: file fo-length.c: line 320 (fo_length_get_value): assertion 
`length != NULL' failed

Let me know if I can help debug this further.

Thanks,
		Stefan

Re: Please try CVS version [Was: [xmlroff] [ANN] xmlroff 0.3.7]

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
...
> I get a segmentation fault after lots of 'libfo-CRITICAL' messages. The first
> one is
>
> (process:12015): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page: 
> FoAreaPage (0x9e8ddb8 : 2); child: FoAreaViewportReference (0x9e8dcb8 : 1)
>
> which I assume your latest work was meant to resolve. Right ?

I had left the warning in there so I could see when the code was being used.
It is currently benign.  I should change it to be a warning that is output
only if the 'overflow' property value is 'error-if-overflow'.

> The second such message looks like an identical copy of the first, but the third
> one is strange again:

That hopefully indicates that you have two pages with content that is too big
for the page (or you added content to an area that was already too big for the
page).

> (process:12015): 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]
>
> The expression in question seems to stem from an external-graphic attribute
> src="images/ast.svg". I thought xmlroff is able to deal with such paths. Do I remember
> wrongly ?

I think you remember wrongly.  The value of 'src' should be a
<uri-specification>, which should start with 'url(' and end with ')'.

You can submit an RFE for xmlroff to support 'src' property values without the
'url(...)'.  All it would take would be yet another expression evaluation
function, since "images/ast.svg" is a plausible expression.

I don't know that xmlroff supports SVG graphics.  I haven't tried it.

> The last errors, which appear to have caused the actual segfault, are assertion errors
> such as:
>
> (process:12015): libfo-CRITICAL **: file fo-length.c: line 320 (fo_length_get_value): assertion 
> `length != NULL' failed

This may be a byproduct of the external graphic not being created properly.
It indicates a bug in the error handling previously, since it shouldn't have
got to the point of trying to process null length datatypes.

> Let me know if I can help debug this further.

Please correct your <uri-specification> and, if necessary, try it with a PNG
instead of SVG image.

Regards,


Tony.

Re: Please try CVS version [Was: [xmlroff] [ANN] xmlroff 0.3.7]

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

Tony Graham wrote:
> Stefan Seefeld <se...@sy...> writes:
> 
>>Tony Graham wrote:
> 
> ...
> 
>>I get a segmentation fault after lots of 'libfo-CRITICAL' messages. The first
>>one is
>>
>>(process:12015): libfo-CRITICAL **: fo_area_page_size_request:: Cannot split child:: page: 
>>FoAreaPage (0x9e8ddb8 : 2); child: FoAreaViewportReference (0x9e8dcb8 : 1)
>>
>>which I assume your latest work was meant to resolve. Right ?
> 
> 
> I had left the warning in there so I could see when the code was being used.
> It is currently benign.  I should change it to be a warning that is output
> only if the 'overflow' property value is 'error-if-overflow'.
> 
> 
>>The second such message looks like an identical copy of the first, but the third
>>one is strange again:
> 
> 
> That hopefully indicates that you have two pages with content that is too big
> for the page (or you added content to an area that was already too big for the
> page).
> 
> 
>>(process:12015): 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]
>>
>>The expression in question seems to stem from an external-graphic attribute
>>src="images/ast.svg". I thought xmlroff is able to deal with such paths. Do I remember
>>wrongly ?
> 
> 
> I think you remember wrongly.  The value of 'src' should be a
> <uri-specification>, which should start with 'url(' and end with ')'.
> 
> You can submit an RFE for xmlroff to support 'src' property values without the
> 'url(...)'.  All it would take would be yet another expression evaluation
> function, since "images/ast.svg" is a plausible expression.
> 
> I don't know that xmlroff supports SVG graphics.  I haven't tried it.
> 
> 
>>The last errors, which appear to have caused the actual segfault, are assertion errors
>>such as:
>>
>>(process:12015): libfo-CRITICAL **: file fo-length.c: line 320 (fo_length_get_value): assertion 
>>`length != NULL' failed
> 
> 
> This may be a byproduct of the external graphic not being created properly.
> It indicates a bug in the error handling previously, since it shouldn't have
> got to the point of trying to process null length datatypes.
> 
> 
>>Let me know if I can help debug this further.
> 
> 
> Please correct your <uri-specification> and, if necessary, try it with a PNG
> instead of SVG image.

Ok, I tuned the xslt stylesheet a bit and now I only get the first two libfo-CRITICAL
errors (warnings). However, xmlroff still segfaults:

0x005a291a in fo_area_size_request_default (child=0x9458540) at fo-area.c:2063

(the rhs 'return_child' is 0x0, and so dereferencing next_part crashes the application)

Let me know if I should mail you the full stack trace.

Regards,
		Stefan

[xmlroff] Re: Please try CVS version

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> Stefan Seefeld <se...@sy...> writes:
...
>>>Let me know if I can help debug this further.
>> Please correct your <uri-specification> and, if necessary, try it with a PNG
>> instead of SVG image.
>
> Ok, I tuned the xslt stylesheet a bit and now I only get the first two libfo-CRITICAL
> errors (warnings). However, xmlroff still segfaults:

Now the messages really are warnings, but you'll still get them regardless of
the 'overflow' property value.

> 0x005a291a in fo_area_size_request_default (child=0x9458540) at fo-area.c:2063
>
> (the rhs 'return_child' is 0x0, and so dereferencing next_part crashes the application)
>
> Let me know if I should mail you the full stack trace.

It would be better to send me the FO file.

BTW, I'm back to not having much time for xmlroff until the weekend: no train
journeys in the next couple of days, then a nine-hour flight on Saturday.

Regards,


Tony.

Re: [xmlroff] Re: Please try CVS version

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

Tony Graham <Ton...@Su...> writes:
> Stefan Seefeld <se...@sy...> writes:
...
>> 0x005a291a in fo_area_size_request_default (child=0x9458540) at fo-area.c:2063
>>
>> (the rhs 'return_child' is 0x0, and so dereferencing next_part crashes the application)
>>
>> Let me know if I should mail you the full stack trace.
>
> It would be better to send me the FO file.
>
> BTW, I'm back to not having much time for xmlroff until the weekend: no train
> journeys in the next couple of days, then a nine-hour flight on Saturday.

I believe I have fixed that bug: the sample file that you sent me now formats.

My changes are checked in to CVS.  Please try again.

Regards,


Tony.

Re: [xmlroff] Re: Please try CVS version

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

Tony Graham wrote:

> I believe I have fixed that bug: the sample file that you sent me now formats.
> 
> My changes are checked in to CVS.  Please try again.

I did, and it generated a pdf indeed. That's great progress !
I now see a lot of errors of the form

(process:27427): GnomePrint-CRITICAL **: file gnome-print-stdapi.c: line 908 
(gnome_print_glyphlist): assertion `gp_gc_has_currentpoint (pc->gc)' failed

What is that ? What does 'gc' stand for ? garbage collection ? graphic context ? :-)

Incidentally, I don't see any images in the pdf (I believe I had seen them prior to
this last change). May that be related ?

Thanks !
		Stefan

Re: [xmlroff] Re: Please try CVS version

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> I believe I have fixed that bug: the sample file that you sent me now formats.
>> My changes are checked in to CVS.  Please try again.
>
> I did, and it generated a pdf indeed. That's great progress !
> I now see a lot of errors of the form
>
> (process:27427): GnomePrint-CRITICAL **: file gnome-print-stdapi.c: line 908 
> (gnome_print_glyphlist): assertion `gp_gc_has_currentpoint (pc->gc)' failed
>
> What is that ? What does 'gc' stand for ? garbage collection ? graphic context ? :-)

GNOME Print graphic context.

Running your T.fo, I don't get any error messages at all.

> Incidentally, I don't see any images in the pdf (I believe I had seen them prior to
> this last change). May that be related ?

It could be related, however the error that you show is from trying to print a
PangoLayout.

It may be related to the changes in area-to-pdf.c to support clipping the
region-body FoAreaViewportReference for certain values of 'overflow', since I
also just checked in changes to that.

Regards,


Tony.