[xmlroff] 'border-style' and 'border-width' properties

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

Hi,
  It looks like I've got border-style and border-width working, at least judging
by a couple tests.

> 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 had to manually edit the new properties' .c files to change the validate
function to check if it's a tblr (rather than the default set of validation
type checks) - I copied this from fo-property-border-color.c.  So I should
send you at least the .c files, unless you want to make this change to each
by hand.
  In terms of sending patches, what is the easiest/best way to do that?  Can
you create a patch that applies to multiple files?  Just do "cvs diff file1
file2 ..."?  Above you seem to be implying a certain way of splitting up the
patches.  I also edited property/fo-property-eval.c and
property/fo-all-property.h (patching in relevant lines from spec-dump's
"make fo-all-property-h-dump") in addition to the above-mentioned dump-info.xml,
fo-context-*, the below-mentioned property/Makefile.am, and the new
properties' .c files (their .h files as dumped by spec-dump are ok, I guess - 
I didn't touch them).  And then the property resolution code in
fo_context_util_border_resolve() in fo-context-util.c.
I think that's it.  So I guess I'm asking: for those
files, what's the best way to submit patches to you?

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

  Cool; I used the expr-eval attribute, using your new
fo_expr_border_style_eval() for border-style and fo_expr_padding_eval() as
you recommended for border-width.  I also set the resolve-enum attributes
to the same thing that the individual border-style/border-width properties
have for that attribute - I was sort of copying what you did for border-color
and am not sure whether these resolve-enum attributes are entirely correct/
necessary.

  Another thing - in my test cases, when I used "border-width", it gave me
a number of warning messages equal to the number of tokens in border-width's
value about datatype != NULL failing in fo_expr_context_push_stack().  Looking
at eval_border_style_expr(), I'm pretty sure you just have an extra

fo_expr_context_push_stack (context, intermediate_value);

where you don't want it - it looks like eval_enum() actually does the
pushing earlier in the function and intermediate_value doesn't get set if
parse_ncname() succeeds, thus the error indicating that intermediate_value
is NULL.  It was working nonetheless, I guess because eval_enum() was
successfully pushing the tokens onto the stack, but letting you know.

  Thanks,
    Julian