Improve error reporting when non-number in numeric context

here's the command line example:

sdths03>/cvs/n1800002/epdm/sdt/xsl> xmlroff -o foo.pdf /tmp/xml-1208200476-263 master_sdrl.xsl ** ** libfo:ERROR:(fo-expr-eval.c:504):parse_number: code should not be reached ABORT instruction (core dumped)

See source:trunk/xmlroff/libfo/expr/fo-expr-eval.c@136#L480

To reach line 504, your FO document (the result of the transform) has an expression that contains numbers followed by "." followed by something that isn't a number. I.e., it would match the regular expression "[0-9]+\.[^0-9]".

xmlroff isn't coping, but the production at http://www.w3.org/TR/xsl11/#NT-FloatingPointNumber says it's okay to not have digits after the ".".

Looking at source:trunk/xmlroff/libfo/expr/fo-expr-eval.c@136#L480 again, the assertion was reached because you have a "." that was neither preceded nor followed by digits.

If the "." was preceded by digits, then 'ok' would be TRUE, and the assertion would not be reached.

It would still help if xmlroff did a better job of reporting the error instead of just falling over.

I did find two lines with a O instead of a 0.

But it is still failing with the same error message. The only remaining lines which match that regex are these:

3 xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 4 xmlns:fo="http://www.w3.org/1999/XSL/Format"> 8 <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">

Don't those lines have to be there?

Replying to DCameronMauch:

I did find two lines with a O instead of a 0.

0 is not a problem. It's what comes after a "." that's causing the problem.

The best way to find out (short of implementing the fix) would be to fire up gdb on the core file and look at 'context'.

The next best way would be to run the transform outside xmlroff and search the result for:

["' ]\.[^0-9]

If you could make a minimal FO file that breaks xmlroff and attach it to this ticket, I could look at it.

Without the not so helpful wiki formatting, that regex would be:

["' ]\.[^0-9]

I wrote a perl program to search for that regex. Only finding those three name space definitions that match it. I may have a fundamental misunderstanding: Can I take the XML/XSL files which I have been processing with Apache FOP (too slow, memory footprint too big), and process them with XMLROFF? I attached the XSL file I have been testing with.

You need to either also attach the XML file or run the stylesheet on the XML file using a XSLT processor such as Saxon or xsltproc and attach the output of that, since that's what xmlroff is objecting to.

You can run the same files through xmlroff as you run through FOP, but so far FOP supports more of the spec than does xmlroff.

Replying to DCameronMauch:

compiled on hpux 11.11 with gcc 3.4.3 had to change compiler option "-mt" to "-pthread" after than it compiled with no errors

I'm not sure how to solve it since it probably requires some 'configure' fu, and I can't test any solution, but can you make a separate ticket for the HP-UX problem?

Not really worried about the compiler option issue. I got past it.

Okay. I attached the XML file I have been using for testing. I don't see anything in this file matching that regex.

The offending text is "./images/master_banner.jpg".

The 'src' attribute value should be "url(./images/master_banner.jpg)".

See http://www.w3.org/TR/xsl11/#src and the definition of <uri-specification> in http://www.w3.org/TR/xsl11/#datatype

What does that have to do with the numberic regex thing? I added the "url()" part and fully specified the path. Now I am getting this error:

sdths03>/cvs/n1800002/epdm/sdt/xsl> xmlroff -o foo.pdf /tmp/xml-1208200476-263 master_sdrl.test
**
** libfo:ERROR:(fo-external-graphic.c:1369):resolve_one_dimension: code should not be reached
ABORT instruction (core dumped)

Result of transforming data.xml with master_sdrl.xsl.

updated XSL file with "url()" stuff added

(In [410]) Handling length-range for viewport width/height when resolving dimensions. Re #120.

Replying to DCameronMauch:

What does that have to do with the numberic regex thing?

I have attached '120.fo' which is the result of transforming data.xml with master-sdrl.xsl. That has a 'src' attribute that matches that last regex.

When the attribute was:

src="../images/master_banner.jpg"

when the expression parser got to the first ".", the only "." allowed at that point was as part of a number, so the expression parser tried and failed to evaluate the attribute value as a number.

I added the "url()" part and fully specified the path. Now I am getting this error:

Adding the "url()" would have been sufficient.

{{{ sdths03>/cvs/n1800002/epdm/sdt/xsl> xmlroff -o foo.pdf /tmp/xml-1208200476-263 master_sdrl.test ** ** libfo:ERROR:(fo-external-graphic.c:1369):resolve_one_dimension: code should not be reached ABORT instruction (core dumped) }}}

That is a bug. That, at least, is fixed now, but unless your graphics are almost exactly the right size, you're going to run into #121.

Replying to DCameronMauch:

Not really worried about the compiler option issue. I got past it.

I'm glad that you got past it, but the next person compiling on HP-UX might not get past it so easily. It would help them if it was documented as a problem with a workaround.

Got sidetracked for a while. Put the patch in place and recompiled. I also prescaled the graphics with another tool, so I could remove all the size and scaling directive in the XSL file. Still getting this error:

(xmlroff:12455): GdkPixbuf-CRITICAL **: file gdk-pixbuf.c: line 503: assertion `pixbuf != NULL' failed

Replying to DCameronMauch:

Got sidetracked for a while. Put the patch in place and recompiled. I also prescaled the graphics with another tool, so I could remove all the size and scaling directive in the XSL file. Still getting this error:

It's a different error from previously, which hopefully is a sign of progress.

Can you attach the FO that is failing (e.g., run your XML and stylesheet through xsltproc and attach the result)?

latest requested file

Okay. I attached the resulting output "text.xml" file.

Did you also get this:

(xmlroff:12042): libfo-CRITICAL **: g-file-error-quark: Failed to open file '../images/master_banner.jpg': No such file or directory
Could not load image.

I only get the pixbuf != NULL assertion failures when xmlroff can't find the file. (And the verbosity of the failed assertions is #69.)

Is this still a bug for you?