xmlroff-list — xmlroff XSL formatter discussion list

Re: [xmlroff] Plan for xmlroff 0.3.7

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

Tony Graham wrote:
> xmlroff 0.3.6 is almost ready, despite Stefan's efforts to remind me of
> essential features.

I'm sorry, I didn't mean to block a release. Instead, I tried to find spots
where I could help, even with my lack of understanding of the xsl-fo internals.

I do agree that the current handling of the src attribute in external graphic
already covers the majority of all cases, thus greatly enhancing the functionality
of xmlroff.

> It is, I think, simple and obvious to continue with fo:external-graphic
> improvements for xmlroff 0.3.7.
> 
> The tasks for xmlroff 0.3.7 as I see them are:
> 
>  - Support 'http:' (and other) protocols in URI specifications

I may have a look at that.

>  - Improve handling unresolvable 'src' URI specifications (to be done after
>    'http:' support)

What do you imagine to happen ? Drop in a fallback graphic ? Do nothing in
the generated document but print out a warning / error ?

>  - Handle more fo:external-graphic properties and handle their
>    interdependencies:
> 
>     - Handle when one of 'content-width' or 'content-height' is specified

What is the expected behavior ? To stretch / shrink the image to fit ?

>     - Handle 'scale' attribute
> 
>    It would be good to also handle non-auto ipd and bpd and 'display-align'
>    and 'text-align' but that will take more effort.
> 
>  - Add a FoImageManager or similar so the same image isn't opened multiple
>    times

I may look into that.

>  - Handle areas that can't be broken

Yes, please !

Regards,
		Stefan

[xmlroff] Plan for xmlroff 0.3.7

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

xmlroff 0.3.6 is almost ready, despite Stefan's efforts to remind me of
essential features.

It is, I think, simple and obvious to continue with fo:external-graphic
improvements for xmlroff 0.3.7.

The tasks for xmlroff 0.3.7 as I see them are:

 - Support 'http:' (and other) protocols in URI specifications

 - Improve handling unresolvable 'src' URI specifications (to be done after
   'http:' support)

 - Handle more fo:external-graphic properties and handle their
   interdependencies:

    - Handle when one of 'content-width' or 'content-height' is specified

    - Handle 'scale' attribute

   It would be good to also handle non-auto ipd and bpd and 'display-align'
   and 'text-align' but that will take more effort.

 - Add a FoImageManager or similar so the same image isn't opened multiple
   times

 - Handle areas that can't be broken

Regards,


Tony.

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.

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 ?

Committed (with modifications), thank you.

Regards,


Tony.

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

[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

[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

[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.

[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] 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

[xmlroff] [Fwd: Re: [docbook-apps] bug in fo stylesheets: no uri-specification in fo:external-graphic ?]

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

Tony,

I asked on the docbook list concerning the way the src attribute
in fo:external-graphic elements are formatted. Here is the response
I got.

Regards,
		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] Fix for compilation error

[Aron S. <elv...@gm...>]

2005/9/8, Tony Graham <Ton...@su...>:
...
> You are well ahead of the curve, since fo-image.[ch] is only in CVS and i=
s yet
> to be in an xmlroff release.

Oh I know, I just wanted to see what CVS xmlroff would do if I threw
one of my DocBook articles at it ;)

...
>> Maybe some day I'll brush up my C skills and dive into the xmlroff
>> code (have to study the GObject system first). It would be really nice
>
> You can go a long way just by treating all those macros as magic incantat=
ions
> and copying what's been used elsewhere.

Okay. I've now gone through the GObject/GType documentation for the
second time in my life (last time was a couple of years ago I think),
and it sunk in much better this time. It's a pretty neat system I must
say. It's very verbose - but not convuluted, very intricate - but
logical, and it seems like a pretty good fit for an XSL formatter
implementation like xmlroff.

...
> There's also some documentation about the structure of the source code fi=
les
> in the xmlroff documentation.

Yep. Read it.

>
> If you don't want to work too much with C, you could work on improving th=
e
> Java native interface.

I'm afraid I'm a complete Java illiterate. I'm a Ruby/C/C++ guy ;)

...
> I personally am concentrating on xmlroff features, such as image support,
> since it seems to me that's what will make more of a difference in the sh=
ort
> term: it doesn't matter how wonderful the rendering technology is if xmlr=
off
> can't format your documents, as your next paragraph attests.

Agreed!

...
> The whole creating of areas from blocks needs to be revised.  I am workin=
g
> towards it.  The idea of getting external-graphic support working again w=
as to
> have something to compare against when it was reimplemented properly, but=
 even
> that has taken a long time since it's hard to find the time to do the wor=
k.

Ah yes, time, curse it. I have my studies and in November/December an
annoying non-tech work to do for my dad. I'll try to put some of free
time into getting closer to understanding the xmlroff source though.

...
> And one xmlroff goal that I don't think I've actually stated anywhere is =
to
> evolve through the (nominally) monthly releases and to not stop releases =
for a
> major redesign: i.e., I favour evolution, not revolution.  All improvemen=
t is
> good and should not be discredited when it doesn't count towards the big
> changes.

Music to my ears.

...
>> I think you're doing a great job, considering the 400 page
humorless XSL spec ;)
>
> I used to be on the XSL FO subgroup, but it was at Candidate Recommendati=
on
> stage at the time I joined.

Oops. No offense, heh. After all, the two things sitting on my bed
table right now is a thrilling documentary by a journalist who was
present on Mount Everest back in '96, when 8 people were killed on the
mountain... and the XSL spec. The latter has seen more reading lately
than the former, so it can't be that dull ;)

2005/9/9, Tony Graham <Ton...@su...>:
> Tony Graham <Ton...@Su...> writes:
> > Aron Stansvik <elv...@gm...> writes:
> ...
> >> I was getting:
> >>
> >> fo-image.c: In function `fo_image_get_width':
> >> fo-image.c:247: error: assignment of read-only member `width'
> >> fo-image.c: In function `fo_image_get_height':
> >> fo-image.c:270: error: assignment of read-only member `height'
> >>
> >> In this newly added file. I fixed by removing the const constrain on
> >> the passed in FoImage (patches attached), don't know if that is the
> >> right thing to do (I'm not such a proficient programmer), but it fixed
> >> the compilation error. Maybe the real solution to this is to not
> >> declare the width and height members the way they are declared? The
> >> funky GObject macros confused my little head. Heh.
> ...
> > It is unlikely that an FoImage will be created for which fo_image_get_w=
idth()
> > and fo_image_get_height() will never be called, so it's probably best t=
o
> > create the FoDatatypes when the image is created.
>
> Done.

Cool.

Now I'll do some more research and then read selected parts of xmlroff
source code, and then I'll probably come back to the list with foolish
questions about the workings of the thing, which you may answer at
your leisure. I'm really interested in how the Glib event loop and
signals would be best put to use in the context of xmlroff. I'm sure
there must be interesting ways in which you can beneficially elaborate
on (or even deviate from) the conceptual procedure described in the
spec.

You WG guys can't have thought of everything, right? ;)

Aron

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] Fix for compilation error

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

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>>>It is unlikely that an FoImage will be created for which fo_image_get_width()
>>>and fo_image_get_height() will never be called, so it's probably best to
>>>create the FoDatatypes when the image is created.
>> Done.
>
> ...but I'm still getting
>
> fo-image.c: In function `fo_image_get_height':
> fo-image.c:286: error: assignment of read-only member `height'
>
> even though I updated from cvs before running 'make'. Am I missing something ?

Cut-and-paste is a powerful tool when used properly.  It wasn't in this case,
since I cut once and pasted twice.  The second cut has now been made.

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] Fix for compilation error

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

Tony Graham wrote:

>>It is unlikely that an FoImage will be created for which fo_image_get_width()
>>and fo_image_get_height() will never be called, so it's probably best to
>>create the FoDatatypes when the image is created.
> 
> 
> Done.

...but I'm still getting

fo-image.c: In function `fo_image_get_height':
fo-image.c:286: error: assignment of read-only member `height'

even though I updated from cvs before running 'make'. Am I missing something ?

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:
> 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

[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] Fix for compilation error

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

Tony Graham <Ton...@Su...> writes:
> Aron Stansvik <elv...@gm...> writes:
...
>> I was getting:
>>
>> fo-image.c: In function `fo_image_get_width':
>> fo-image.c:247: error: assignment of read-only member `width'
>> fo-image.c: In function `fo_image_get_height':
>> fo-image.c:270: error: assignment of read-only member `height'
>>
>> In this newly added file. I fixed by removing the const constrain on
>> the passed in FoImage (patches attached), don't know if that is the
>> right thing to do (I'm not such a proficient programmer), but it fixed
>> the compilation error. Maybe the real solution to this is to not
>> declare the width and height members the way they are declared? The
>> funky GObject macros confused my little head. Heh.
...
> It is unlikely that an FoImage will be created for which fo_image_get_width()
> and fo_image_get_height() will never be called, so it's probably best to
> create the FoDatatypes when the image is created.

Done.

Regards,


Tony.

Re: [xmlroff] Fix for compilation error

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

Aron Stansvik <elv...@gm...> writes:
> Hello. This is my first post to the list.

Welcome to the xmlroff-list, and thank you for your interest in xmlroff.

> I was getting:
>
> fo-image.c: In function `fo_image_get_width':
> fo-image.c:247: error: assignment of read-only member `width'
> fo-image.c: In function `fo_image_get_height':
> fo-image.c:270: error: assignment of read-only member `height'
>
> In this newly added file. I fixed by removing the const constrain on
> the passed in FoImage (patches attached), don't know if that is the
> right thing to do (I'm not such a proficient programmer), but it fixed
> the compilation error. Maybe the real solution to this is to not
> declare the width and height members the way they are declared? The
> funky GObject macros confused my little head. Heh.

You are well ahead of the curve, since fo-image.[ch] is only in CVS and is yet
to be in an xmlroff release.

fo_image_get_width() was defined as:

   FoDatatype * fo_image_get_width  (const FoImage *fo_image)

on the principle that the FoImage should be unchanged just by getting the
width of the image.

I ruined that by saving the width (and height) as part of the FoImage so
there'd be only one FoDatatype for the width (and one for the height) instead
of creating a new one each time fo_image_get_width() (or
fo_image_get_height()) is called.

The alternatives include:

 - Removing the 'const', as you have done

 - Casting the 'const FoImage' to 'FoImage' when making the assignments

 - Creating the width and height FoDatatype when the image is created

 - Creating a new FoDatatype whenever the function is called.

It is unlikely that an FoImage will be created for which fo_image_get_width()
and fo_image_get_height() will never be called, so it's probably best to
create the FoDatatypes when the image is created.

> I think xmlroff is a very promising project, and I think it's

Thank you for your kind words.

> important that there are other free XSL Formatter project besides
> Apache FOP. I saw that one poster on this list expressed the same
> thought I had in mind: Now that Pango supports drawing to Cairo
> surfaces, could this somehow be used by xmlroff?

It should.

Everyone is welcome to work on it.

I personally am concentrating on xmlroff features, such as image support,
since it seems to me that's what will make more of a difference in the short
term: it doesn't matter how wonderful the rendering technology is if xmlroff
can't format your documents, as your next paragraph attests.

> Maybe some day I'll brush up my C skills and dive into the xmlroff
> code (have to study the GObject system first). It would be really nice

You can go a long way just by treating all those macros as magic incantations
and copying what's been used elsewhere.

There's also some documentation about the structure of the source code files
in the xmlroff documentation.

One day, xmlroff will do more with signals, freezing and thawing them, and the
GLib event loop: now that will really make your head spin (as it does mine).

If you don't want to work too much with C, you could work on improving the
Java native interface.

> if I could use xmlroff in my DocBook XML tool chain. It needs to be
> better on the block-level stacking and preserve white-space correctly

The whole creating of areas from blocks needs to be revised.  I am working
towards it.  The idea of getting external-graphic support working again was to
have something to compare against when it was reimplemented properly, but even
that has taken a long time since it's hard to find the time to do the work.

There's now call to improve external-graphic support so you don't need to
specify content-width and content-height (hence the addition of FoImage).
That effort is not wasted, but it doesn't count towards the inline areas
revision.

And one xmlroff goal that I don't think I've actually stated anywhere is to
evolve through the (nominally) monthly releases and to not stop releases for a
major redesign: i.e., I favour evolution, not revolution.  All improvement is
good and should not be discredited when it doesn't count towards the big
changes.

> in my code listings first, and support images. (Don't worry, I'll come
> back with more detailed reports/test cases :))

You should also mention region-before and region-after.

> I think you're doing a great job, considering the 400 page humorless XSL spec ;)

I used to be on the XSL FO subgroup, but it was at Candidate Recommendation
stage at the time I joined.

Regards,


Tony.

[xmlroff] Re: Fix for compilation error

[Aron S. <elv...@gm...>]

> snip
> ...Maybe the real solution to this is to not
> declare the width and height members the way they are declared? The
> funky GObject macros confused my little head. Heh.
> ...

Disregard that. I didn't realize that the declaration was actually in
the .c file, and wrongly thought that the GObject macros did some
magic to declare FoImage :)

Aron

[xmlroff] Fix for compilation error

[Aron S. <elv...@gm...>]

Hello. This is my first post to the list.

I was getting:

fo-image.c: In function `fo_image_get_width':
fo-image.c:247: error: assignment of read-only member `width'
fo-image.c: In function `fo_image_get_height':
fo-image.c:270: error: assignment of read-only member `height'

In this newly added file. I fixed by removing the const constrain on
the passed in FoImage (patches attached), don't know if that is the
right thing to do (I'm not such a proficient programmer), but it fixed
the compilation error. Maybe the real solution to this is to not
declare the width and height members the way they are declared? The
funky GObject macros confused my little head. Heh.

I think xmlroff is a very promising project, and I think it's
important that there are other free XSL Formatter project besides
Apache FOP. I saw that one poster on this list expressed the same
thought I had in mind: Now that Pango supports drawing to Cairo
surfaces, could this somehow be used by xmlroff?

Maybe some day I'll brush up my C skills and dive into the xmlroff
code (have to study the GObject system first). It would be really nice
if I could use xmlroff in my DocBook XML tool chain. It needs to be
better on the block-level stacking and preserve white-space correctly
in my code listings first, and support images. (Don't worry, I'll come
back with more detailed reports/test cases :))

I think you're doing a great job, considering the 400 page humorless XSL sp=
ec ;)

Best regards,
Aron Stansvik