xmlroff-list

[xmlroff] errors during fo:external-graphic processing

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

Here are some more observations when processing fo:external-graphic
elements:

1) The 'src' attribute is an url, meaning it has to be resolved
    relative to the url base of the current node it was found in.
    However, xmlroff tries to read it as a file, i.e. relative to
    the current working directory (for example in fo-image.c:236).
    Shouldn't something like xmlBuildURI() be used to actually
    construct the correct absolute filename ?


2) I now get this error:


(process:7561): libfo-CRITICAL **: Expression evaluation error: Expression not completely evaluated: 
':image/svg+xml'
Object path: 
/FoTree[1]/root[1]/page-sequence[3]/flow[1]/FoBlockBlock[3]/FoBlockLayout[1]/external-graphic[1]

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

My external-graphic element contains an attribute:

content-type="content-type:image/svg+xml"

and it seems as if xmlroff doesn't understand that. What is
not clear to me is whether it doesn't understand the 'image/svg+xml'
type, or whether it doesn't understand the 'content-type' format at all.


3) When I remove that attribute alltogether xmlroff will
    seemingly run forever (well, at least I had to kill it
    after a long while). I didn't have a close look into
    the call stack to find out what it was doing then, though.

Best regards,
		Stefan

Re: [xmlroff] errors during fo:external-graphic processing

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

Stefan Seefeld <se...@sy...> writes:
> Here are some more observations when processing fo:external-graphic
> elements:
>
> 1) The 'src' attribute is an url, meaning it has to be resolved
>    relative to the url base of the current node it was found in.
>    However, xmlroff tries to read it as a file, i.e. relative to
>    the current working directory (for example in fo-image.c:236).
>    Shouldn't something like xmlBuildURI() be used to actually
>    construct the correct absolute filename ?

Your observations are correct.

I have been wondering what to do about that, and about xml:base attributes,
and about http URIs.  I will look into xmlBuildURI().

>
> 2) I now get this error:
>
>
> (process:7561): libfo-CRITICAL **: Expression evaluation error: Expression not completely evaluated: 
> ':image/svg+xml'
> Object path: 
> /FoTree[1]/root[1]/page-sequence[3]/flow[1]/FoBlockBlock[3]/FoBlockLayout[1]/external-graphic[1]
>
> (process:7561): libfo-WARNING **: Unsupported property: (null)
>
> My external-graphic element contains an attribute:
>
> content-type="content-type:image/svg+xml"
>
> and it seems as if xmlroff doesn't understand that. What is
> not clear to me is whether it doesn't understand the 'image/svg+xml'
> type, or whether it doesn't understand the 'content-type' format at all.

Section 5.9 of the XSL 1.0 specification says:

   All property value expressions in attributes within an XSL stylesheet can
   be expressions.

except that patently some of them can't be.

content-type will need yet another special expression parser, and should be
added to libfo-compat.xsl until that happens.

> 3) When I remove that attribute alltogether xmlroff will
>    seemingly run forever (well, at least I had to kill it
>    after a long while). I didn't have a close look into
>    the call stack to find out what it was doing then, though.

Sorry, no quick answer for that one since I haven't seen it before.

I doubt that it relates specifically to removing the attribute since the
attribute currently isn't used.

Regards,


Tony.

Re: [xmlroff] errors during fo:external-graphic processing

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

Tony Graham wrote:

>>1) The 'src' attribute is an url, meaning it has to be resolved
>>   relative to the url base of the current node it was found in.
>>   However, xmlroff tries to read it as a file, i.e. relative to
>>   the current working directory (for example in fo-image.c:236).
>>   Shouldn't something like xmlBuildURI() be used to actually
>>   construct the correct absolute filename ?
> 
> 
> Your observations are correct.
> 
> I have been wondering what to do about that, and about xml:base attributes,
> and about http URIs.  I will look into xmlBuildURI().



Now that looks like something I can contribute (as opposed to
things such as how to split areas), so if you hold on a bit
I may come up with a patch.

Regards,
		Stefan

Re: [xmlroff] errors during fo:external-graphic processing

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

Stefan Seefeld wrote:

> Now that looks like something I can contribute (as opposed to
> things such as how to split areas), so if you hold on a bit
> I may come up with a patch.

What about this one ?

Regards,
		Stefan

Re: [xmlroff] errors during fo:external-graphic processing

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

Stefan Seefeld <se...@sy...> writes:
> Stefan Seefeld wrote:
>> Now that looks like something I can contribute (as opposed to
>> things such as how to split areas), so if you hold on a bit
>> I may come up with a patch.
>
> What about this one ?

Committed (with modifications), thank you.

Regards,


Tony.

Re: [xmlroff] errors during fo:external-graphic processing

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

Tony Graham wrote:

> Committed (with modifications), thank you.

Great, thanks !

I don't know the xsl-fo specs very well, but does the 'src' attribute in
external-graphic allow any uri type, in particular, any scheme ? In that cases,
you should probably use libxml2's nanohttp module to load the file content,
instead of assuming it is a local file.

Also, I note you have stripped off the content-type attribute with the
libfo-compat.xsl. What content-types does xmlroff support right now, and
how does it detect them ? By file extension ? (I note you are using
'gdk_pixbuf_new_from_file' but documentation for that only indicates
'The file format is detected automatically.' I think supported formats
have to be well-documented.

Thanks,
		Stefan

Re: [xmlroff] errors during fo:external-graphic processing

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

Stefan Seefeld <se...@sy...> writes:
> Stefan Seefeld wrote:
>
>> Now that looks like something I can contribute (as opposed to
>> things such as how to split areas), so if you hold on a bit
>> I may come up with a patch.
>
> What about this one ?

It looks pretty good, though I have yet to try it.

My quibbles are:

 - I don't want to introduce a dependency on xmlChar (and the libxml2 header
   files) in an FO's header file. (You can probably find where there already
   is one amongst the FOs and properties, but if there is, I'd like to remove
   it, too.)

   The xmlChar* should be translated to gchar*.

 - I think we still need fo_external_graphic_new() (i.e., with no arguments)
   for GObject compatibility.

   There probably should either be a
   fo_external_graphic_new_with_base_uri(gchar*) or a
   fo_external_graphic_set_base_uri(gchar*) in addition to
   fo_external_graphic_new().

And after thinking about it for a while, I can dredge up:

 - The base URI property should be declared as a GObject-style property as
   well, which means stuff in fo_external_graphic_class_init(),
   fo_external_graphic_set_property(), fo_external_graphic_get_property(), and
   the base_url should be freed in fo_external_graphic_finalize().

   I can take care of those aspects.

 - The base URI string should be copied to make the FoExternalGraphic property
   value just so it's safer to free either the XmlDoc or the FO.

 - The base URI should be passed to fo_image_new_from_url(gchar* base_uri,
   gchar* uri) since the same URI resolution will be required for
   background-image and possibly other properties.

   (In time, there will be an FoImageManager or similar that you use to get an
   FoImage.  The manager will keep a map of URIs and images so you don't
   create duplicate FoImage objects for the same image, and it can do the URI
   resolution.)

Thank you for doing this.  I will incorporate your ideas before the next
release.

Regards,


Tony.

> Regards,
> 		Stefan
> Index: result-to-fo.c
> ===================================================================
> RCS file: /cvsroot/xmlroff/xmlroff/result-to-fo.c,v
> retrieving revision 1.25
> diff -u -r1.25 result-to-fo.c
> --- result-to-fo.c	13 Jun 2005 22:22:41 -0000	1.25
> +++ result-to-fo.c	10 Sep 2005 14:54:33 -0000
> @@ -216,7 +216,8 @@
>      break; /* end 'd' */
>    case 'e':
>      if (strcmp (name, "external-graphic") == 0) {
> -      fo_node = fo_external_graphic_new ();
> +      xmlChar *base_uri = xmlNodeGetBase(node->doc, node);
> +      fo_node = fo_external_graphic_new (base_uri);
>        ok = TRUE;
>      }
>      break; /* end 'e' */
> Index: fo/fo-external-graphic-private.h
> ===================================================================
> RCS file: /cvsroot/xmlroff/xmlroff/fo/fo-external-graphic-private.h,v
> retrieving revision 1.7
> diff -u -r1.7 fo-external-graphic-private.h
> --- fo/fo-external-graphic-private.h	9 Sep 2005 11:00:57 -0000	1.7
> +++ fo/fo-external-graphic-private.h	10 Sep 2005 14:54:34 -0000
> @@ -23,6 +23,7 @@
>    FoFo        parent_instance;
>  
>    FoDoc      *fo_doc;
> +  xmlChar    *base_url;
>    FoImage    *fo_image;
>    gdouble     area_width;
>    gdouble     area_height;
> Index: fo/fo-external-graphic.c
> ===================================================================
> RCS file: /cvsroot/xmlroff/xmlroff/fo/fo-external-graphic.c,v
> retrieving revision 1.19
> diff -u -r1.19 fo-external-graphic.c
> --- fo/fo-external-graphic.c	9 Sep 2005 11:00:57 -0000	1.19
> +++ fo/fo-external-graphic.c	10 Sep 2005 14:54:36 -0000
> @@ -84,6 +84,7 @@
>  #include "fo-property-src.h"
>  #include "fo-property-text-align.h"
>  #include "fo-property-width.h"
> +#include "libxml/uri.h"
>  
>  /* ORC = U+FFFC
>   *     = 1111 1111 1111 1100 (UTF-16)
> @@ -1290,9 +1291,17 @@
>   * Return value: the new #FoExternalGraphic.
>   **/
>  FoFo*
> -fo_external_graphic_new (void)
> +fo_external_graphic_new (xmlChar *base_url)
>  {
> -  return FO_FO (g_object_new (fo_external_graphic_get_type (), NULL));
> +  FoFo *fo_fo = FO_FO(g_object_new (fo_external_graphic_get_type (), NULL));
> +  FO_EXTERNAL_GRAPHIC(fo_fo)->base_url = base_url;
> +  return fo_fo;
> +}
> +
> +xmlChar*
> +fo_external_graphic_get_base_url (FoFo *fo_fo)
> +{
> +  return FO_EXTERNAL_GRAPHIC(fo_fo)->base_url;
>  }
>  
>  /**
> @@ -1403,7 +1412,8 @@
>                                GError   **error)
>  {
>    FoExternalGraphic *fo_external_graphic;
> -
> +  gchar *src, *url;
> +  
>    g_return_if_fail (fo != NULL);
>    g_return_if_fail (FO_IS_EXTERNAL_GRAPHIC (fo));
>    g_return_if_fail (FO_IS_CONTEXT (current_context));
> @@ -1419,8 +1429,9 @@
>    fo_external_graphic_set_line_height (fo,
>  				       fo_property_line_height_resolve (fo_external_graphic->line_height,
>  									fo_context_get_font_size (fo->context)));
> -  fo_external_graphic->fo_image =
> -    fo_image_new_from_url (fo_uri_specification_get_value (fo_property_get_value (fo_external_graphic->src)));
> +  src = fo_uri_specification_get_value (fo_property_get_value (fo_external_graphic->src));
> +  url = xmlBuildURI(fo_external_graphic->base_url, src);
> +  fo_external_graphic->fo_image = fo_image_new_from_url (url);
>    fo_external_graphic_layout_resolve (fo_external_graphic);
>  }
>  
> Index: fo/fo-external-graphic.h
> ===================================================================
> RCS file: /cvsroot/xmlroff/xmlroff/fo/fo-external-graphic.h,v
> retrieving revision 1.4
> diff -u -r1.4 fo-external-graphic.h
> --- fo/fo-external-graphic.h	30 Mar 2004 22:45:41 -0000	1.4
> +++ fo/fo-external-graphic.h	10 Sep 2005 14:54:36 -0000
> @@ -28,7 +28,9 @@
>  
>  
>  GType         fo_external_graphic_get_type      (void) G_GNUC_CONST;
> -FoFo *fo_external_graphic_new (void);
> +FoFo *fo_external_graphic_new (xmlChar *base_uri);
> +
> +xmlChar*    fo_external_graphic_get_base_url (FoFo       *fo_fo);
>  
>  FoProperty* fo_external_graphic_get_alignment_adjust (FoFo       *fo_fo);
>  void        fo_external_graphic_set_alignment_adjust (FoFo       *fo_fo,

Re: [xmlroff] errors during fo:external-graphic processing

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>> Committed (with modifications), thank you.
>
> Great, thanks !

Thank you both for pushing for implementing the capability and for doing the
hardest part of the work with your patch.

> I don't know the xsl-fo specs very well, but does the 'src' attribute in
> external-graphic allow any uri type, in particular, any scheme ? In that cases,
> you should probably use libxml2's nanohttp module to load the file content,
> instead of assuming it is a local file.

Yes, it could be a HTTP URI.

I did start looking at nanohttp yesterday (and you'd also have to consider
nanoftp), but I'm not considering holding up the release until they are
added.  We can work on those for the next release.

> Also, I note you have stripped off the content-type attribute with the
> libfo-compat.xsl. What content-types does xmlroff support right now, and

As you pointed out, xmlroff can't parse content-type values.

> how does it detect them ? By file extension ? (I note you are using
> 'gdk_pixbuf_new_from_file' but documentation for that only indicates
> 'The file format is detected automatically.' I think supported formats
> have to be well-documented.

You know as much as I do about supported file formats, since all I know is
that line from the GDK documentation.

I had forgotten that 'content-type' is an extended conformance requirement,
whereas we're still targetting basic conformance, so while 'content-type'
support would be nice to have, it is not yet essential.

I have added comments to the conformance information to indicate that xmlroff
only does local files and the image formats supported by the underlying image
library.

We can add tests to the testsuite to show what common file formats are
supported and what aren't.

Regards,


Tony.