From: Tony G. <Ton...@Su...> - 2006-05-31 10:06:12
|
Stefan Seefeld <se...@sy...> writes: > as we talked about xmlroff's usability a while ago, here is an example I just ran into: > > Processing some input file I just generated, I get this output: > > (process:29504): libfo-CRITICAL **: fo_expr_eval: assertion `IS_CHAR (g_utf8_get_char (string))' failed > > (process:29504): libfo-CRITICAL **: fo_property_id_validate: assertion `datatype != NULL' failed > > > > I don't find this output particularly helpful, because: > > * It isn't clear whether this is a warning or an error (though 'CRITICAL' certainly hints > at an error). It's a failed assertion. One of the g_return_if_fail() or g_return_val_if_fail() macro calls in the code. > * It isn't clear whether this is due to invalid input, an unimplemented feature > in xmlroff, or something entirely different. It is due to invalid input. I am actually surprised that you managed to get invalid UTF-8 that far into xmlroff. > * It isn't clear whether there is anything I (as a user) can do to prevent this > problem, by making changes to the input. A failed GLIB assertion macro indicates a programming error, either because the program is doing something wrong or because the programmer didn't anticipate that the user would do something wrong. For example, I had assumed that libxml2 would have caught the invalid UTF-8 when your input XML was parsed to make an FoXmlDoc. If it didn't, then I (or someone else) should add checks for valid UTF-8 and give human-readable error messages, and if there isn't a problem with your input XML, then there's a bug somewhere that should be fixed. > I'm not sure how these points should be addressed, and, whether this could > happen in the 0.4 timeframe. Firstly, we can document the meaning of 'assertion ... failed' messages. Secondly, you can run 'xmllint' on your input document and stylesheet to see if you can find any invalid UTF-8. Thirdly, you can file a SourceForge bug report and attach your input XML to it. Regards, Tony. |