Dear Editors:
During recent work to integrate our FO processor with a
MathML processor,
several questions came up about what information can be
passed from the FO
processor to the MathML processor. MathML content can be
either in an
fo:external-graphic or an fo:instream-foreign-object, and
these questions
apply to each of these FOs.
MathML allows at least some of its formatting properties to
be inherited
from its surrounding text.[1] The question is: What are FO
documents allowed
to provide to them? The properties in question for MathML
are "color",
"font-size", and "background-color", but
it is conceivable that
font-selection properties might be useful as well. None of
these properties
"apply" to either fo:external-graphic or
fo:instream-foreign-object in the
1.1 Recommendation.
[1] http://www.w3.org/TR/MathML/chapter3.html#presm.commatt
I see three possible answers to the question:
1. FO content and content from other namespaces have an
arms-length
relationship, and the FO document should not directly affect
the rendering
of the non-FO content, except as allowed for in
fo:instream-foreign-object,
where FO and non-FO attributes may be passed to the
processor of the non-FO
content.
2. The fact that certain properties "apply" to
fo:external-graphic and
fo:instream-foreign-object does not prevent these objects
from passing the
values of other properties to the processors of their
content.
3. The XSL-FO Recommendation does not intend to expose all
properties to
children of fo:external-graphic and
fo:instream-foreign-object, but does
intend to expose those that might be needed by processors of
the content of
those objects.
There may be other options as well that I have not thought
of. Please
provide any guidance that you can to clarify the intent
here. If the correct
answer is #3, please consider adding the properties
enumerated above to
those that "apply" to these two formatting
objects. For the case of MathML
at least, I don't see a downside. If a MathML author wants
to explicitly
control these properties (NOT inherit them), he can do so.
There may be
other namespaces or applications where introducing the FO
properties into
the content processing would be a form of pollution. But
preventing that
would seem to be the responsibility of either the FO
processor or the
content processor, not so much the availability of the raw
material (exposed
properties) itself.
I realize that adding such properties to fo:external-graphic
is a bit
awkward at best. It certainly looks silly to apply these
properties to a
JPEG image, for example. I also realize that this list of
properties may not
be comprehensive for all possible needs of content in other
namespaces.
Thank you in advance for your help.
Victor Mote
The FOray Project www.foray.org
|