xmlroff-list

[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

[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

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.

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

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