Re: DOCBOOK-APPS: How to select <imageobject> alternativein<mediaobject>?

[Bob Stayton <bobs at caldera dot com>]

On Thu, Nov 28, 2002 at 09:47:28PM +0100, Jirka Kosek wrote:
> Bob Stayton wrote:
> 
> > > 1. image selection based on role attribute should be controlled by
> > > on/off parameter
> > 
> > It seems that this should be a feature of the profiling
> > step, not the processing step.  As you say, if someone has
> > role attributes on their imageobjects and are doing
> > profiling without taking "html;fo" into account, then by
> > the time the regular stylesheet gets the content, they
> > won't have the elements for this option to act on.  If they
> > are taking it into account, then they would always want the
> > option on during the formatting step anyway.  So it would
> > seem that it is the profiling step that needs such an
> > option, to enable the profiling step to make exceptions for
> > imageobject role attributes during the profiling step so
> > they survive to the formatting step.
> 
> But I think that exatly for this reason there should be option how to
> switch off new behaviour. Imagine that someone is using role="html" and
> role="fo" on normal paragrahs with profiling to distinguish between
> print and HTML version. If I will add html and fo targets as defaults to
> profile.role, these users wouldn't be happy because profiling will be
> broken for them. 

Good point.
  
> > I'm thinking that people might have other conflicts for the
> > use of the role attribute in their documents. For example,
> > <emphasis role="bold">, or <emphasis role="mystyle"> with
> > the 'emphasis.propagates.style' attribute set to 1 so the
> > HTML stylesheet does <span class="mystyle"> in the HTML.
> > Essentially if you use role for profiling, you cannot use
> > role for other purposes without always including those
> > values in your "profile.role" selection.
> > 
> > Perhaps the non-profiling role values should be in a
> > separate "profile.role.accept" parameter that is a
> > permanent fixture of the stylesheet or customization.  One
> > would perform a particular profiling by setting their
> > profile.role on the command line, and that would be merged
> > by the stylesheet with the values in profile.role.accept.
> > That way, the profiling gets taken care of and the other
> > role attributes survive to be acted upon by the formatting
> > stylesheet.  The default value of profile.role.accept could
> > be "html;fo", and it is customizable.
> 
> I think that profiling on role is not good idea as a whole 

Is that because role may be used for other purposes besides
profiling?  If so, then I agree. I think I would be pretty
shocked to find my <emphasis role="bold"> elements
disappearing in profiled output.  But that is what happens
if I profile on role and don't include 'bold' in my list of
role targets.  In this respect, using role for profiling
is kind of dangerous, because small missing text like that
is pretty hard to spot.

> so I think
> that we shouldn't make profiling code more complex by introducing some
> "magic" like profile.role.accept. I think that people should just have
> option to switch off selection of images based on role if they want to
> do so. After that they can still control image inclusion based on role
> by profiling.

OK. Let me see if I understand.
Let's say we add a parameter "use.role.to.select.image".
If that parameter is 1 (the default), then role="html|fo" is used
by the stylesheet to select an imageobject.
If that parameter is zero, role is not used for image
selection.

If you are not doing profiling on role, then you leave
the default as 1, and you can use role for image selection.
And you can use role for other purposes that the stylesheet
supports, such as emphasis.

If you *are* doing profiling on role, then you need to know
what you are doing.  You need to review your document to
see what values of role have been used that are not
intended for profiling, and include those values in your
collection of profiling targets in 'profile.role'.  If you
want image selection, you set 'use.role.to.select.image'
to zero, and  include either 'html' or 'fo' in
your target list.

I think this is fine.  It is nice and simple for those who
are not doing profiling on role.  For those doing profiling
on role, there are no hidden surprises as long as they
know that *all* role values need to be accounted for.

I think we need to add something to the profiling doc
about how to use role for profiling (and maybe caution them
not to).

-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com