xmlroff-list — xmlroff XSL formatter discussion list

Re: [xmlroff] 'border-color' property

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

Julian Rosse <gn...@th...> writes:
>   I wrote the code for #3 (adding border-style and border-width resolution
> support to fo_context_util_border_resolve()).  However, it won't even be
> able to compile until other stuff is plugged in, so I guess I should wait
> on sending a patch.

Okay.

>> >   I guess just let me know what you'd like me to work on.
>> 
>> #1, I guess.
>
> I added the two <property> tags to dump-info.xml (I copied the attributes
> from looking at the border-color <property> compared to the individual
> border-*-color <property>s), ran make, and looked at
> diffs between some of the output files and the ones in xmlroff/ currently.
> What's the best way to add the relevant new stuff for border-style and
> border-width to the appropriate files?  I figured since I'd be submitting
> it as a patch anyway, maybe the easiest thing would be to run cvs diff on
> the files and then manually edit the patch to only include the lines
> relevant to those two properties.

The easiest way would be to submit the patch for
spec-dump/dump-info.xml and a separate patch for xmlroff/fo-context.c
and xmlroff/fo-context{-private}?.h.

Since the properties' files are new, I'll just merge your
dump-info.xml patch, make the properties' files, and copy them over.

>   I'm also not entirely sure about which
> files need to be updated and which ones need manual editing of what
> spec-dump dumps.  For example, the spec-dump README talks about updating
> fo/fo-* formatting object files when you add a property that those fo's
> may have, but it didn't look like anything in the xmlroff/fo/ cvs had
> border-color added.  Is that because it's a shorthand or something?

Yes.  The FO's don't have properties for the shorthands because the
shorthands are resolved to individual properties.

>   It looks to me like these are some of the things I have to do regarding
> the spec-dumped files:
>
>   manually modify property/fo-property-border-{style,width}.c in similar ways
> to how property/fo-property-border-color.c is different from the file that
> spec-dump dumps and add these and their corresponding header files.

Some of those differences are because I changed my mind on things
after I generated the original fo-property-border-color.[ch] files.

I have modified 'dump-info.xml' to reduce the differences.

I also added support for a 'expr-eval' attribute on <property>
elements in dump-info.xml so there'll be one less piece of manual
fixup on the generated files.

>   add the dumped sections of fo-context.[ch] and fo-context-private.h which
> are relevant to the two properties.

Yes.

When you look at the diffs, you'll see evidence of my indecision about
what to do about components of spaces and traces of a few properties
that haven't been implemented yet.  As you say, add the "relevant"
portions to the files.

>   run "make fo-all-property-h-dump" and add the lines relevant to the two
> properties.

Yes.

> Is that it?

They need to be added to property/Makefile.am, otherwise they'll never
get compiled.

Thanks again.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

[Julian R. <gn...@th...>]

Hi,

  I wrote the code for #3 (adding border-style and border-width resolution
support to fo_context_util_border_resolve()).  However, it won't even be
able to compile until other stuff is plugged in, so I guess I should wait
on sending a patch.

> >   I guess just let me know what you'd like me to work on.
> 
> #1, I guess.

I added the two <property> tags to dump-info.xml (I copied the attributes
from looking at the border-color <property> compared to the individual
border-*-color <property>s), ran make, and looked at
diffs between some of the output files and the ones in xmlroff/ currently.
What's the best way to add the relevant new stuff for border-style and
border-width to the appropriate files?  I figured since I'd be submitting
it as a patch anyway, maybe the easiest thing would be to run cvs diff on
the files and then manually edit the patch to only include the lines
relevant to those two properties.
  I'm also not entirely sure about which
files need to be updated and which ones need manual editing of what
spec-dump dumps.  For example, the spec-dump README talks about updating
fo/fo-* formatting object files when you add a property that those fo's
may have, but it didn't look like anything in the xmlroff/fo/ cvs had
border-color added.  Is that because it's a shorthand or something?
  It looks to me like these are some of the things I have to do regarding
the spec-dumped files:

  manually modify property/fo-property-border-{style,width}.c in similar ways
to how property/fo-property-border-color.c is different from the file that
spec-dump dumps and add these and their corresponding header files.

  add the dumped sections of fo-context.[ch] and fo-context-private.h which
are relevant to the two properties.

  run "make fo-all-property-h-dump" and add the lines relevant to the two
properties.

Is that it?

Thanks,
  Julian

Re: [xmlroff] 'border-color' property

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

Tony Graham <Ton...@Su...> writes:
> gn...@th... writes:
...
>> 2. Add parallel functions to fo_expr_border_color_eval() and
>> eval_border_color_expr() to expr/fo-expr-eval.[ch] for border-style and
>> border-width
...
>> spec-dump and adding/merging stuff.  I looked at expr/fo-expr-eval.c; I
>
> Just run 'make'.  See the README.  The default target makes the
> necessary files.
>
>> might be able to help with #2, but that would be more challenging,
>
> I wouldn't wish #2 on you.  I'll do that.

Done for 'border-style'.  I'm still assuming for the moment that you
can use the 'padding' eval function for 'border-width'.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

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

gn...@th... writes:
...
>> Are you ready for 'border-width' and 'border-style'?
>
> Sure.  I've been looking at a lot of the relevant code.  Judging by our
> discussions and looking at the ChangeLog entries for adding border-color, it
> looks like some of the tasks are:
>
> 1. Add border-style and border-width <property>s to spec-dump and add/merge
> the relevant dumped files
>
> 2. Add parallel functions to fo_expr_border_color_eval() and
> eval_border_color_expr() to expr/fo-expr-eval.[ch] for border-style and
> border-width
>
> 3. Add similar code to the border-color patch I submitted to
> fo_context_util_border_resolve() for border-style and border-width
>
> 4. Add lines for border-width and border-style to property/fo-property-eval.c
> (? - spec-dump doesn't generate this, right?)

No, it doesn't, although it easily could, I guess.

>   Correct (I'm just checking here)?  Are there other tasks?
>
>   I can definitely do #3 if it is just duplicating the logic that I added
> for border-color.  I'm not sure I know the mechanics of #1 exactly - running

Yes for #3.

> spec-dump and adding/merging stuff.  I looked at expr/fo-expr-eval.c; I

Just run 'make'.  See the README.  The default target makes the
necessary files.

> might be able to help with #2, but that would be more challenging,

I wouldn't wish #2 on you.  I'll do that.

> especially the lexing/parsing code, I'd think.  #4 looks trivial.

It is.

>   I guess just let me know what you'd like me to work on.

#1, I guess.

You'll need #2 real soon, but you should at least be able to use the
padding evaluation function for 'border-width'.

>   On another note, how do I get the cvs xmlroff/ sources into a
> configure-able/make-able state?  I just did "autoconf configure.in" and it
> yelled at me for some undefined macros.  I can give you details if this is
> news.  I'm not familiar with the autotools etc.

Run autogen.sh.

You may also need to run 'libtoolize' before you run autogen.sh.

Let me know how you get on.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

[<gn...@th...>]

Hi,

> Thanks, Julian.  I've checked in your patch.  It should be generally
> available from anonymous CVS shortly.

Cool, thanks.

> Are you ready for 'border-width' and 'border-style'?

Sure.  I've been looking at a lot of the relevant code.  Judging by our
discussions and looking at the ChangeLog entries for adding border-color, it
looks like some of the tasks are:

1. Add border-style and border-width <property>s to spec-dump and add/merge
the relevant dumped files

2. Add parallel functions to fo_expr_border_color_eval() and
eval_border_color_expr() to expr/fo-expr-eval.[ch] for border-style and
border-width

3. Add similar code to the border-color patch I submitted to
fo_context_util_border_resolve() for border-style and border-width

4. Add lines for border-width and border-style to property/fo-property-eval.c
(? - spec-dump doesn't generate this, right?)

  Correct (I'm just checking here)?  Are there other tasks?

  I can definitely do #3 if it is just duplicating the logic that I added
for border-color.  I'm not sure I know the mechanics of #1 exactly - running
spec-dump and adding/merging stuff.  I looked at expr/fo-expr-eval.c; I
might be able to help with #2, but that would be more challenging,
especially the lexing/parsing code, I'd think.  #4 looks trivial.

  I guess just let me know what you'd like me to work on.

  On another note, how do I get the cvs xmlroff/ sources into a
configure-able/make-able state?  I just did "autoconf configure.in" and it
yelled at me for some undefined macros.  I can give you details if this is
news.  I'm not familiar with the autotools etc.

  Thanks,

   Julian

[xmlroff] Re: border-color patch

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

gn...@th... writes:
...
> OK.  I'll look at the expression code some.  I looked at a fair amount of
> spec-dump; I'm pretty handy with XSLT and felt like I got the gist of what

To add the new properties to the spec-dump just requires adding some
<property> elements to dump-info.xml and then running the Make
targets.

> was going on.  You indicated that we'd need a new FoDatatype for
> border{,-top,-left,-right,-bottom}, right?  Whereas border-style and
> border-width will be FoTblr's too?  I should look at the relevant sections of
> the spec more closely too.

The datatype we want is not in the spec.  I've had to invent FoTblr
and FoPcw because they were useful.  There's a couple like FoToken
that I've created because I thought they'd be useful but have never
used.

Fo??? would just be a case of copying and modifying one of the
existing datatypes.  Copying and modifying FoTblr is probably
simplest.  It would also need to be added to fo-all-datatype.h and to
datatype/Makefile.am.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

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

gn...@th... writes:
>   I changed fo_context_util_border_resolve() to understand border-color.  It
> appears to be working!

Thanks, Julian.  I've checked in your patch.  It should be generally
available from anonymous CVS shortly.

I also have some test cases that I'll check into the 'testsuite'
module, which will put it in the odd position of having tests for a
to-be-released property but not for the just-added functionality.

Speaking of the next release, I'll be in Australia at around the first
of next month, so I'll have to see what I can do about doing a release
while I'm there.

Are you ready for 'border-width' and 'border-style'?

Regards,


Tony.

Re: [xmlroff] 'border-color' property

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

gn...@th... writes:
>   I changed fo_context_util_border_resolve() to understand border-color.  It
> appears to be working!

Great!

..
>> In principle, that's a technique that will scale better when xmlroff
>> gets around to handling reference-orientation, since when the
>> relationship between relative and absolute is no longer fixed, you
>> really don't want a single function that's 16 times as long as
>> resolve_absolute_relative_padding() just to do nearly the same thing
>> 16 times over.
>
>   Yeah, I see what you mean.  It seems like borders, as I'm sure you're
> aware, are maybe the ugliest in terms of shorthands, relative vs. absolute, etc.

Yep.  Ugly, alright.

> since there is the overall "border" shorthand, the shorthands "border-color",
> "border-style", and "border-width", the shorthands "border-top",
> "border-bottom", "border-left", and "border-right", and then the specific
> relative and absolute attributes for style, color, and width.  Again, the spec
> is super-clear about the precedence/resolution rules, but it's a lot more
> overlap/hierarchy.  So I guess

There's also the slight matter of needing multiple, different property
expression evaluators for the differing allowed values of different
shorthands.  xmlroff, for a long time, wasn't set up to support
different expression evaluation routines for different properties, but
happily now it does.

As I see it, 'border', 'border-left', 'border-right', 'border-top',
and 'border-bottom' will use a common routine for evaluating their
property values.  That routine will produce a yet-to-be-implemented
FoDatatype representing a width-style-color combination (although, as
we now know, the colour could actually be 'transparent').

'border-width', 'border-style', and 'border-color' will need separate
property expression evaluation routines that each produce a FoTblr
datatype (for 'top-bottom-left-right' values, as you've seen).

The eventual border resolution function will then get to churn through
all of those.

> it would be nice to separate out a function somehow like
> resolve_absolute_relative_padding() to avoid a really long if-else nesting
> hell, but it will still be a lot more complicated than padding, right?

It will be done one day, but it wasn't the sort of thing I'd ask you
to do as a first stab at working on xmlroff.

As I see it, the resolution of 'border', 'border-left', etc., and
'border-width', etc. into 'border-left-color', etc. only happens one
way.

For the part that is dependent on reference orientation, there would
be a function similar to resolve_absolute_relative_padding(), but by
then the structures to supply as the absolute and relative parameters
would be in a multi-dimensional array.  The border resolution function
would just index into the array based on the reference orientation and
the border side to get the absolute and relative parameters for the
factored-out resolution function.

Data-driven programming, but we're not there yet.

>   What's the preferred way of creating and submitting a patch?  If you can't
> tell, I'm new at the whole contributing-to-open-source-projects thing.

Send me the 'cvs diff' output.

>   In the unrelated-but-hindering-stuff department, the pdf's I'm generating
> have no visible text in them.  I'll look at making sure I have the right

I can see how that would be a problem...

> versions of packages installed (are fontconfig and freetype the most relevant
> ones here?), but just seeing if you have a hunch what my environment is missing
> - I don't know much of anything about fonts.

Do you get any error messages when running xmlroff?

What OS are you using?

What xmlroff version are you using?

What PangoXSL version are you using?

What Pango version are you using?

What libgnomeprint version are you using?

If you're using libgnomeprint 2.8.0, see
https://sourceforge.net/forum/forum.php?forum_id=412127 for a possible
cause of your problem.

Thanks for doing this work, and I look forward to seeing your patch.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

[<gn...@th...>]

Hi,
  I changed fo_context_util_border_resolve() to understand border-color.  It
appears to be working!

> fo_context_util_border_resolve() currently does practically the same
> thing twelve different ways: it resolves the absolute and relative
> properties for each of 'color', 'width', and 'style' for each of the
> four borders of an FO that has borders.
> 
 ...
> fo_context_util_padding_resolve() takes a different approach to the
> fact that you do practically the same thing for each of the four
> sides: rather than copying the code four times with slightly different
> function names each time, fo_context_util_padding_resolve() leaves all
> the processing to the resolve_absolute_relative_padding() function and
> just calls it four times with the values appropriate for each side.
> 
> In principle, that's a technique that will scale better when xmlroff
> gets around to handling reference-orientation, since when the
> relationship between relative and absolute is no longer fixed, you
> really don't want a single function that's 16 times as long as
> resolve_absolute_relative_padding() just to do nearly the same thing
> 16 times over.

  Yeah, I see what you mean.  It seems like borders, as I'm sure you're
aware, are maybe the ugliest in terms of shorthands, relative vs. absolute, etc.
since there is the overall "border" shorthand, the shorthands "border-color",
"border-style", and "border-width", the shorthands "border-top",
"border-bottom", "border-left", and "border-right", and then the specific
relative and absolute attributes for style, color, and width.  Again, the spec
is super-clear about the precedence/resolution rules, but it's a lot more
overlap/hierarchy.  So I guess
it would be nice to separate out a function somehow like
resolve_absolute_relative_padding() to avoid a really long if-else nesting
hell, but it will still be a lot more complicated than padding, right?

  What's the preferred way of creating and submitting a patch?  If you can't
tell, I'm new at the whole contributing-to-open-source-projects thing.

  In the unrelated-but-hindering-stuff department, the pdf's I'm generating
have no visible text in them.  I'll look at making sure I have the right
versions of packages installed (are fontconfig and freetype the most relevant
ones here?), but just seeing if you have a hunch what my environment is missing
- I don't know much of anything about fonts.

Thanks for all the explanations.

  Thanks,
    Julian

Re: [xmlroff] ANN: xmlroff 0.3.2

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

Tony Graham <Ton...@Su...> writes:
> Hiroki Sato <hr...@al...> writes:
...
>>  I could not fetch pangoxsl-1.6.0.1.tar.gz.  Is this URL correct?
>>
>>  | For pangoxsl: pangoxsl-1.6.0.1.tar.gz
>>  | http://prdownloads.sourceforge.net/pangopdf/pangoxsl-1.6.0.1.tar.gz?download
>
> No, it's not correct (but you already knew that).  It's:

It is now correct.  It turns out I had a bug fix from October that I
could release as 1.6.0.1.  My thanks to Gerrit Haase for providing the
fix, and my apologies for forgetting to release it.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

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

gn...@th... writes:
...
>   I can try adding border-color resolution support.  I checked out

Great!

> fo-context-util - it looks like I'd be modifying
> fo_context_util_border_resolve() to understand the shorthand border-color
> property and using code similar to fo_context_util_paddings_resolve() to
> deal with the border-color FoTblr, no?  Just checking that I am on the
> right track...  Chapter 5 of the XSL spec is quite clear about the precedence

You are on the right track.

> rules for shorthand properties etc.  I'll probably have questions though...

I would be surprised, very surprised, if you didn't have questions
over the combination of the XSL spec and the xmlroff code.

>   In general, I am starting to slowly work my way through the XSL spec, getting
> the hang of GObject, and getting a better feel for the code and how things
> fit together.

Let me try to prime the pump...

AFAICT, the immediate problem of adding 'border-color' support boils
down to adding the equivalent of the "if (shorthand_component !=
null)" block from resolve_absolute_relative_padding() to the color
handling portions of fo_context_util_border_resolve().


fo_context_util_border_resolve() currently does practically the same
thing twelve different ways: it resolves the absolute and relative
properties for each of 'color', 'width', and 'style' for each of the
four borders of an FO that has borders.

fo_context_util_border_resolve() works on the FoContext of the current
FO; that is, it works on the full set of absolute and relative
property values that were specified on the current FO.

The result from running fo_context_util_border_resolve() is that the
current FoContext is updated with the absolute and relative property
values resolved as specified in the XSL spec.

One twist in the tale is that if neither an absolute nor relative
color property is provided (e.g., if neither 'border-left-color' or
'border-start-color' for the start border), then you use the same
color as the text, i.e., use the either 'color' property value of the
current FO or the 'color' property value of the parent FO if 'color'
is not set on the current FO.

Another twist is when the style is 'none', then the border has zero
width no matter what values are used for the absolute and relative
border width properties.


fo_context_util_padding_resolve() is a later version of handling much
the same problem.  Handling padding is much simpler since padding only
has width, even though the width can have conditionality.  Because
padding is simpler, that was my first attempt at a shorthand property.

fo_context_util_padding_resolve() takes a different approach to the
fact that you do practically the same thing for each of the four
sides: rather than copying the code four times with slightly different
function names each time, fo_context_util_padding_resolve() leaves all
the processing to the resolve_absolute_relative_padding() function and
just calls it four times with the values appropriate for each side.

In principle, that's a technique that will scale better when xmlroff
gets around to handling reference-orientation, since when the
relationship between relative and absolute is no longer fixed, you
really don't want a single function that's 16 times as long as
resolve_absolute_relative_padding() just to do nearly the same thing
16 times over.


Some things you will see a lot of in the code:

   FoDatatype *datatype;
   FoProperty *property = ...;
   ...
   datatype = fo_property_get_value (property);

      As a comment on using GObjects: since GObjects are only
      object-oriented by convention, you need to pass the GObject as
      (usually) the first argument of a function that operates on the
      GObject.  In an object-oriented language that does things with
      dots to signify methods of objects, this would probably be
      expressed as 'property.getValue()'.

      As a comment on using FoProperty: you can use
      fo_property_get_value() to get (a pointer to) the FoDatatype
      that is the value of the property.

      FoDataypes are (or should be) immutable.  (I'm still working on
      modifying all the datatypes so they are, but when you could
      change the value of a datatype that was the value of a property,
      it sometimes caused strange behaviour in other FOs because their
      property's value had also been changed.  At least some of the
      time, I also think of making FoProperty objects immutable for
      much the same reason.)


  FoProperty *property;
  ...
  property = fo_property_border_left_style_new ();

     This gets a new instance of the property type, to which you will
     probably assign a value shortly afterwards.


  fo_property_set_value (absolute, datatype);

     Sets a property's value.


  FoProperty *property;
  ...
  property = fo_property_border_left_style_get_initial ();

     This gets an instance of the property that is set to the initial
     value as specified in the XSL spec.  In practice, this always
     returns the same property instance since for non-inherited values
     it saves creating a lot of instances that all have the same value
     and are never going to change.  You *really* don't want to change
     the value of a FoProperty you got this way.


  property = fo_context_get_margin_left (current_context);
  fo_context_set_border_left_style (current_context, property);

      Getter and setter for FoContext components.


One last thing that I only found out on the weekend...  The CSS2
errata says that individual border's colour values should be "<color>
| transparent" (i.e., the same as 'background-color').  It probably
won't make any difference to fo_context_util_border_resolve(), but I
thought I'd mention it since you'd start to wonder when you look in
the spec and see "[<color> | transparent]{1,4} | inherit" for
'border-color' and just '<color> | inherit' for the individual colour
properties.

Regards,


Tony.

Re: [xmlroff] 'border-color' property

[<gn...@th...>]

Hi,

> I implemented the property, but haven't hooked it into the property
> resolution code.
> 
> If someone wants to test their knowledge of the source code, they
> could look at what I did (starting with the 'spec-dump' module) to see
> how well they understand what I did and why.  For the really
> adventurous, they can look at fo-context-util and see what would need
> to be done to support it similarly to how the 'padding' property
> is resolved w.r.t. the non-shorthand 'padding-*' properties.

  I can try adding border-color resolution support.  I checked out
fo-context-util - it looks like I'd be modifying
fo_context_util_border_resolve() to understand the shorthand border-color
property and using code similar to fo_context_util_paddings_resolve() to
deal with the border-color FoTblr, no?  Just checking that I am on the
right track...  Chapter 5 of the XSL spec is quite clear about the precedence
rules for shorthand properties etc.  I'll probably have questions though...
  In general, I am starting to slowly work my way through the XSL spec, getting
the hang of GObject, and getting a better feel for the code and how things
fit together.

 Thanks,
  Julian

Re: [xmlroff] ANN: xmlroff 0.3.2

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

Hiroki Sato <hr...@al...> writes:
> Tony Graham <Ton...@Su...> wrote
>   in <m3k...@Su...>:
>
> T> xmlroff 0.3.2 is now available.  The xmlroff website has not yet been
> T> updated, and there's not yet a test case for testing the new colour
> T> support.
>
>  I could not fetch pangoxsl-1.6.0.1.tar.gz.  Is this URL correct?
>
>  | For pangoxsl: pangoxsl-1.6.0.1.tar.gz
>  | http://prdownloads.sourceforge.net/pangopdf/pangoxsl-1.6.0.1.tar.gz?download

No, it's not correct (but you already knew that).  It's:

http://prdownloads.sourceforge.net/pangopdf/pangoxsl-1.6.0.0.tar.gz?download

It must have been my error when updating the PangoXSL version number
in the INSTALL file some time when the PangoXSL version changed.  The
xmlroff version number in the INSTALL file is automatically updated
for each release.  I'll have to do something about either
automatically updating the PangoXSL download URL or just referring to
the PangoXSL project's download page.

Thanks for pointing this out.  I'll change the INSTALL file and
re-upload the xmlroff release.

Regards,


Tony.

Re: [xmlroff] ANN: xmlroff 0.3.2

[Hiroki S. <hr...@al...>]

Hi,

Tony Graham <Ton...@Su...> wrote
  in <m3k...@Su...>:

T> xmlroff 0.3.2 is now available.  The xmlroff website has not yet been
T> updated, and there's not yet a test case for testing the new colour
T> support.

 I could not fetch pangoxsl-1.6.0.1.tar.gz.  Is this URL correct?

 | For pangoxsl: pangoxsl-1.6.0.1.tar.gz
 | http://prdownloads.sourceforge.net/pangopdf/pangoxsl-1.6.0.1.tar.gz?download

-- 
| Hiroki SATO

[xmlroff] ANN: xmlroff 0.3.2

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

xmlroff 0.3.2 is now available.  The xmlroff website has not yet been
updated, and there's not yet a test case for testing the new colour
support.

Regards,


Tony.


From the SourceForge new item:

------------------------------------------------------------
xmlroff 0.3.2 -- X11 colours

xmlroff is an XSL formatter written in C. xmlroff 0.3.2 adds support
for X11 colour names in 'color', etc. property values.
------------------------------------------------------------


From the NEWS file:

------------------------------------------------------------
Changes between 0.3.1 and 0.3.2

* Added support for X11 colour names as 'color' keywords
* Removed rewriting of 'color' and similar properties from
  libfo-compat.xsl
* Improved documentation
* Minor bug fixes
------------------------------------------------------------


From the ChangeLog:

------------------------------------------------------------
2005-03-02  Tony Graham  <ton...@us...>

	* === Released 0.3.2 ===

	* fo/fo-fo.c: fo_fo_validate_content(): Removed unused,
	out-of-date code.

	* NEWS: Updated for 0.3.2.

2005-02-28  Tony Graham  <ton...@us...>

	* util/Makefile.am: Corrected reference to
	libfo_util_include_HEADERS.

	* expr/fo-expr-eval.c, expr/fo-expr-eval.h: Added
	fo_expr_border_color_eval() for 'border-color' shorthand.

	* libfo/fo-libfo-basic.c: Minor comment fixup.

	* property/fo-property-eval.c: Added 'border-color'.

	* property/fo-property-background-color.c,
	property/fo-property-util.c, property/fo-property-util.h: Moved
	'background-color' validate and resolve_enum functions to
	fo-property-util.

	* fo-context.h, property/Makefile.am, property/fo-all-property.h,
	fo-context-private.h, fo-context.c: Added 'border-color' property.

	* fo/fo-multi-properties-private.h, fo/fo-multi-properties.c,
	fo/fo-multi-properties.h: Updated to match current spec-dump.

	* Makefile.am: Added 'util' to SUBDIRS and includes.

	* property/fo-property-border-color.c,
	property/fo-property-border-color.h: 'border-color' property.

2005-02-27  Tony Graham  <ton...@us...>

	* libfo/fo-libfo-context.c, libfo/fo-libfo-context.h: Added
	PostScript as allowed output format.

	* configure.in: Added util/Makefile to AC_OUTPUT().  Escaped a
	macro name to quieten newer autoconfs.

	* fo-object.c, fo-object.h: Added fo_object_equal() and
	fo_object_hash() for use with FoHashTable.

	* libfo-compat.xsl: Removed rewriting of @color,
	@background-color, etc.

	* datatype/fo-color.c, datatype/fo-color.h: Added
	fo_color_new_with_value() backed by FoHashTable.

	* expr/fo-expr-eval.c, expr/fo-expr-func.c: Using new
	fo_color_new_with_value().

	* fo/fo-multi-properties.c: Removed some out-of-date casts.

	* libfo/fo-libfo-basic.c: Added some doc comments.

	* property/fo-property-util.c: Added X color name support copied
	from Pango/GDK/Tk.

	* util/fo-hash-table.c, util/fo-hash-table.h: Hash table object
	for FoObjects.

	* util/Makefile.am: Makefile.am for 'util' subdirectory.

2005-01-31  Tony Graham  <ton...@us...>

	* configure.in: Added INSTALL.in to AC_OUTPUT().  Upped version to
	0.3.2.

	* INSTALL: Removed since now created from INSTALL.in.

	* INSTALL.in: Added INSTALL.in to create INSTALL with correct
	version numbers.
------------------------------------------------------------

[xmlroff] 'border-color' property

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

When the X11 colours took longer than expected, I used the remaining
time on the weekend to implement 'border-color' rather than work on
external graphics (unfortunately).

I implemented the property, but haven't hooked it into the property
resolution code.

If someone wants to test their knowledge of the source code, they
could look at what I did (starting with the 'spec-dump' module) to see
how well they understand what I did and why.  For the really
adventurous, they can look at fo-context-util and see what would need
to be done to support it similarly to how the 'padding' property
is resolved w.r.t. the non-shorthand 'padding-*' properties.

For the less adventurous and less source-code-inclined, we'll need
test case FO files for testing 'border-color' once it's fully
implemented.  Any volunteers?

Feel free to ask questions about any if this if you need to.

Regards,


Tony.

[xmlroff] X11 colours

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

The code now in CVS implements mapping the X11 colour names to FoColor
objects.

I also added fo_color_new_with_value() so that colours are immutable
once created, and I put a hash table (actually, a FoHashTable) in
FoColorClass so there's only ever one instance of a particular colour.

Along the way, I added FoHashTable as an object-aware hash table type
and added fo_object_equal() and fo_object_hash() so every FoObject so
every FoObject type can define its own equality and hash functions.

I also discovered that fo_color_get_color_fuschia() has been returning
purple for I don't know how long.

If anyone has time to write a test case, we need a test case or two to
test the X11 colour support (although not every colour unless you're
really enthusiastic).  I would suggest a property/color/color2.fo to
keep it separate from the spec-defined colours in
property/color/color1.fo.

Given my recent experience with fuschia, I would also suggest that the
test case include both the colour specified by name and the colour
specified by value to make sure the right colour is being found when
specified by name.

Can someone create such a test case?

Regards,


Tony.

Re: [xmlroff] help offer

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

gn...@th... writes:
...
>> As to where to help, the field is wide open.  The next things that I
>> will be working on are recognising X colour names, getting graphics to
>> work again, and region-before and region-after.
>
> I'm thinking it might be better for me to spend some more time with the
> source code, GLib, GObject, etc. before jumping into real coding.  But
> whatever you think is most useful can dictate, I guess.  I saw your
> replies to Peter Saint-Andre's offer for help recently - might some of those
> tasks be good for starting?  Has he tackled any of them?

Not that I know of.

However, since you say you are a C coder and Peter says he's not, I
would prefer if you were able to work on the C source code side of things.

> I can give you more specifics about my current knowledge etc. if that would
> be useful in pointing me at tasks.
>  
>> I actually have this weekend off just to work on xmlroff.  I now have
>> to wonder whether I should work on code or documentation.
>
> Yup.  Well I should have some time this weekend too; let me know if there's
> anything I could immediately tackle to help.

Unless you have an itch that you need to scratch right away, then
looking over the code is probably the best way to start.

When you have questions, as I hope you will, please post them here.

When you're ready to take on a task, let me know.  There's many things
that need doing.

Regards,


Tony.

Re: [xmlroff] help offer

[<gn...@th...>]

Cool.

> For xmlroff, you don't need to read up on GNOME, just on GLib and
> GObject.  xmlroff doesn't have a GUI, so it doesn't extend to the
> level of needing GNOME libraries.  AFAIK, Dave Malcolm's Conglomerate
> is the only project to moot a GUI for xmlroff.

OK; I got the Gnome 2 Developer's Guide and am checking those libs out.

> As to where to help, the field is wide open.  The next things that I
> will be working on are recognising X colour names, getting graphics to
> work again, and region-before and region-after.

I'm thinking it might be better for me to spend some more time with the
source code, GLib, GObject, etc. before jumping into real coding.  But
whatever you think is most useful can dictate, I guess.  I saw your
replies to Peter Saint-Andre's offer for help recently - might some of those
tasks be good for starting?  Has he tackled any of them?

I can give you more specifics about my current knowledge etc. if that would
be useful in pointing me at tasks.
 
> I actually have this weekend off just to work on xmlroff.  I now have
> to wonder whether I should work on code or documentation.

Yup.  Well I should have some time this weekend too; let me know if there's
anything I could immediately tackle to help.

> 
> Regards,
> 
> 
> Tony.

 Thanks,
  Julian

Re: [xmlroff] help offer

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

Julian,

gn...@th... writes:
>   I'd like to offer coding (and possibly other) help.  I have only started to
> read about the relevant GNOME libraries and have a pretty rudimentary
> understanding of XSL(-FO), but would like to learn both well.  I have XML/XSLT
> and C experience.  Thanks,

Thanks for your offer, and welcome to the xmlroff-list and xmlroff.

Your offer is gratefully accepted.  Have you ever known an open-source
project that did not accept help?

For xmlroff, you don't need to read up on GNOME, just on GLib and
GObject.  xmlroff doesn't have a GUI, so it doesn't extend to the
level of needing GNOME libraries.  AFAIK, Dave Malcolm's Conglomerate
is the only project to moot a GUI for xmlroff.

As to where to help, the field is wide open.  The next things that I
will be working on are recognising X colour names, getting graphics to
work again, and region-before and region-after.

I actually have this weekend off just to work on xmlroff.  I now have
to wonder whether I should work on code or documentation.

Regards,


Tony.

[xmlroff] help offer

[<gn...@th...>]

Hi,
  I'd like to offer coding (and possibly other) help.  I have only started to
read about the relevant GNOME libraries and have a pretty rudimentary
understanding of XSL(-FO), but would like to learn both well.  I have XML/XSLT
and C experience.  Thanks,

   Julian Rosse

Re: [xmlroff] Re: xmlroff 0.3.1

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

Tony Graham <Ton...@Su...> writes:
...
> Mixing testing and XSLT, the 'testing' module could do with an
> overhaul.  Its current limitations include:

 - Running tests is all-or-nothing: it should be possible to run
   subsets of tests or an individual test.

Regards,


Tony.

Re: [xmlroff] Re: xmlroff 0.3.1

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

Peter Saint-Andre <st...@ja...> writes:
> In article <m33...@Su...>, Tony Graham <Ton...@Su...> 
> wrote:
>
>> xmlroff 0.3.1  is now available.  Also new testsuite and testing
>> packages and a new testresults package with the results of running
>> xmlroff 0.3.1 on the testsuite.
>
> Thanks for your work on xmlroff. I discovered it just today and hope to 
> give it a whirl here soon. What help is needed on the project? (Note: I 
> am not a C coder, but could help with testing, XSLTs, etc.)

Thank you for your offer.  It is, of course, gratefully accepted.

On the testing side, there are several thousand tests from NIST and
elsewhere that could be incrementally added to the xmlroff test
results once someone does the initial work of running them once and
checking the result.

On the XSLT side, I have a nagging irritation with the DocBook website
stylesheets that wouldn't take much to fix.

The 'spec-dump' module is all XSLT, but since you're avowedly not a C
coder, it's unlikely that I could interest you in that.

Mixing testing and XSLT, the 'testing' module could do with an
overhaul.  Its current limitations include:

 - It is hardcoded for producing PDF, but it should be possible to
   configure a test setup to produce and meaningfully compare
   PostScript output.

 - It is probably too hardcoded to running the tests from the
   directory containing the 'testing' perl scripts and stylesheets.
   Beyond running tests for both PDF and PostScript output, I need a
   test setup that I can run to compare the current xmlroff version
   against the previous release as well as keeping my current test
   setup that I continually run as I make changes to xmlroff.

 - The current setup to change between static reports and reports with
   forms is beyond clunky.

 - Updating results using the form in an individual report doesn't
   regenerate the individual report.

 - Now that Mozilla, etc. supports XSLT, the reports should be XML
   with styles applied rather than batch-generated HTML.

 - Currently the test results are all recorded in one file that
   conforms to the DTD developed for the XSL 1.0 Candidate
   Recommendation testing.  That is useful if we ever need to exchange
   test result information, but it's unlikely that we will unless
   xmlroff implements any XSL 1.1 features for the XSL 1.1 Candidate
   Recommendation testing phase.  As such, if the individual reports
   become XML, then it would be convenient if the test result
   information stayed in the individual files and the single
   testresults.xml file was just generated if and when required by
   merging the information from the individual XML files.

 - The look of the reports needs work.

The choice is yours.

Regards,


Tony.

p.s. If you're reading the xmlroff-list using gmane, you can configure
     your subscription so you're not also sent list posts as email.

[xmlroff] Re: xmlroff 0.3.1

[Peter Saint-A. <st...@ja...>]

In article <m33...@Su...>, Tony Graham <Ton...@Su...> 
wrote:

> xmlroff 0.3.1  is now available.  Also new testsuite and testing
> packages and a new testresults package with the results of running
> xmlroff 0.3.1 on the testsuite.

Thanks for your work on xmlroff. I discovered it just today and hope to 
give it a whirl here soon. What help is needed on the project? (Note: I 
am not a C coder, but could help with testing, XSLTs, etc.)

Peter

[xmlroff] xmlroff 0.3.1

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

xmlroff 0.3.1  is now available.  Also new testsuite and testing
packages and a new testresults package with the results of running
xmlroff 0.3.1 on the testsuite.

Now to find the energy to announce it on the XSL-related mailing
lists...

Regards,


Tony.

Changes between 0.3.0 and 0.3.1

* Improved documentation
* Minor bug fixes

2005-01-29  Tony Graham  <ton...@us...>

	* === Released 0.3.1 ===

	* fo/fo-simple-page-master.c: Fixed a compiler warning from
	out-of-date casting.

	* docs/xmlroff-docs.sgml: Added extra documentation lifted from
	Wiki pages.

	* docs/Makefile.am: Added missing files to distribution.

2005-01-04  Tony Graham  <ton...@us...>

	* catalog.xml: catalog.xml is created from catalog.xml.in.

2005-01-03  Tony Graham  <ton...@us...>

	* docs/debugging.xml, docs/directory-structure.xml,
	docs/fo-c-file.xml, docs/generating-source.xml: Documentation
	lifted from xmlroff Wiki.

	* catalog.xml: Catalog file for libfo-compat.xsl.

	* Makefile.am, configure.in: Upped version to 0.3.1.

	* result-to-fo.c, area/fo-area.c, fo/fo-block-area.c,
	fo/fo-block-fo.c, fo/fo-list-block.c, fo/fo-table-border-fo.c:
	Fixed some "FIXME" problems.