[xmlroff] Border shorthands [Was: instream-foreign-object SVG?]

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

Julian Rosse <gn...@th...> writes:
>    Right now dump-info.xml has <property> tags (with only "name" attributes)
> for shorthand
> properties for seven of the eight absolute/relative sides - "border-bottom" is
> missing.  The XSL spec only seems to mention shorthands for the absolute
> sides - border-bottom, border-top, border-left, border-right.  Should the other
> four exist?  There seems to be code talking about border-after's and such in

No, the other four shouldn't exist.  I shouldn't have put them in
dump-info.xml.

> some of the area code, and the spec seems to talk about it in those terms,
> but not for actual element attributes.  Also, right now spec-dump doesn't seem
> to include any of these properties in the files it dumps; I didn't see right
> off what suppresses them.

Selective patching on my part.

>   There are already fo-property-border.[ch] files which seem to have some
> general border-oriented enums and such - will I want to merge these with the
> same-named files that spec-dump will produce, or rename these existing files,
> ...?

You should be able to replace the files without a problem.

At one time, all of the border-related enums were defined in
fo-border.[ch] and all the border types were subclasses of FoBorder.
That was too unwieldy and didn't reflect that fact that 'border' is
itself a property.

The enums have been superseded by the enums in datatype/fo-enum.[ch].
All enums are currently defined there both so a particular enum object
is only created once and so there's less hassle in getting an
enumerated value from a property of a different type using
from-parent(), etc.

The definitions of thin, medium, and thick borders have been
superseded by functions in datatype/fo-length.[ch].

fo_property_border_resolve() has been moved to
fo_property_util_border_resolve() and, thanks to you, has been
significanlty updated.

>   A semantic question for which I didn't notice an answer in the spec right
> off - the spec clearly says that the border-<side> shorthands are of higher
> priority than border-{style,color,width}, and "border" is lowest priority.
> You're allowed to omit any or all of the style, color, and width components
> from the border{,-<side>} shorthands, right (I don't know the XSL spec regex
> vocabulary particularly - ||, etc.)?  e.g., border-top="1px solid" is valid,
> no?  In the case that components are omitted, it would seem intuitive that
> any values already assigned by a lower-priority shorthand which correspond
> to an omitted component on the current one would remain as the value, rather
> than, say, a default value for that omitted component overriding the actually
> specified value from a lower-priority shorthand.  If that is the desired
> semantics, how will that be represented in xmlroff?  In particular, what will,
> say, fo_wsc_get_color() return if that component was omitted from the
> shorthand attribute corresponding to the FoWsc?  I want to say NULL, but that
> seems to indicate other error conditions - would we need some other enum value
> meaning "omitted" or something?  I guess that's somewhere
> between a question and a suggestion.

I was wondering much the same thing when I was implementing
datatype/fo-wsc.[ch].

fo_wsc_new() creates an FoWsc with NULL for all three components, yet
fo_wsc_new_from_values() will complain if you don't provide component
values, so you can see I am conflicted about this.

I had a whole different answer worked out, but it now seems to me that
we should use NULL for a component that is not specified.

Consider this:

   <fo:block border-color="red" border-left="thin solid"/>

I think the result for the left/start border would be thin/solid/red
rather than thin/solid/(text color).

>   If 'inherit' is specified on one of these shorthands, will that be resolved
> in the expr-eval code?  From my perspective, that will already be resolved
> before the fo-context-util code gets ahold of the FoWsc's, right?

The resolved value should be the value from the parent context.

It will be resolved by the expr-eval code (once it's written).

The fo-context-util code shouldn't have to worry about it.

Good questions.  Thanks.

Regards,


Tony.