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.