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