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.