This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: Notes on graphics and HTML
Norm and I discussed this some more off line and we clarified
several things for each other.
Some more comments embedded.
At 08:39 2002 05 03 -0400, Ed Nixon wrote:
>Notes below:
>
>At 02:44 PM 02/05/2002 -0500, Paul Grosso wrote:
>>At 12:41 2002 05 01 -0700, Norman Walsh wrote:
>><snip>
>>> 1. If only the content-area is specified, everything is fine.
>>> (If you ask for a three inch image, that's what you'll get.)
>>
>>Yep (as long as the XSL-HTML stylesheets convert 3in to pixels, since
>>the value of an html::img.{width,height} attribute has to be a unitless
>>number of pixels).
>
>I don't see how this could work given the variability of pixels/inch in screen resolutions and settings. Can you explain?
The short answer is that, in general, pixels don't work. They are
terrible things to use when specifying style. However, the HTML
language and browsers don't give you much of a choice.
The rest of the answer is that, though CSS has an extended discussion
of pixels, the bottom line is most browsers use a default of something
close to 90-96 pixels per inch (as the CSS 2 spec suggests).
As you noticed below, the DocBook stylesheets have a parameter
$pixels.per.inch that defaults to 90, and this is how it "works".
>>> 3. If both the content-area and the viewport-area is specified
>>> on a graphic element, ignore the viewport-area.
>>> (If you ask for a three inch image in a five inch area, we'll assume
>>> it's better to give you a three inch image in an unspecified area
>>> than a five inch image in a five inch area.
>>
>>This is reasonable. I assume one could wrap the 3in image in a 5in block,
>>but I suspect what you suggest above is more likely to make the user happy.
>>
>>> Relative units also cause problems. As a general rule, the stylesheets
>>> are operating too early and too loosely coupled with the rendering engine
>>> to know things like the current font size or the actual dimensions of
>>> an image. Therefore:
>>>
>>> 1. We use a fixed size for pixels, $pixels.per.inch
>>>
>>> 2. We use a fixed size for "em"s, $points.per.em
>
>Ok, that answers my question above but how portable is this solution across platforms and workstation configurations, e.g. for people who, of visual necessity, run their machines a low res.
About as portable as HTML. This is how browsers work.
Sometime it gives lousy results, but usually no one
seems to notice much.
>>Or just say that it is an error for docbook::graphics.{width,depth} to be
>>assigned a value whose unit is "em".
>
>If I understand this correctly, aren't you taking away my ability to create HTML output that conforms with WAI and 508 guidelines? Via CSS?
I don't understand how saying we shouldn't use "em" does this.
Can you explain?
>>> Percentages are problematic. In the following discussion, we speak
>>> of width and contentwidth, but the same issues apply to depth and
>>> contentdepth
>>>
>>> 1. A width of 50% means "half of the available space for the image."
>>> That's fine. But note that in HTML, this is a dynamic property and
>>> the image size will vary if the browser window is resized.
>>>
>>> 2. A contentwidth of 50% means "half of the actual image width". But
>>> the stylesheets have no way to assess the image's actual size. Treating
>>> this as a width of 50% is one possibility, but it produces behavior
>>> (dynamic scaling) that seems entirely out of character with the
>>> meaning.
>>
>>Worse, mapping docbook::graphics.width="200%" to html::img.width="200%"
>>guarantees that the graphic will be twice as large as the window which
>>is almost never what the user wants to see.
>>
>>
>>> Instead, the stylesheets define a $nominal.image.width.in.points
>>> and convert percentages to actual values based on that nominal size.
>>
>>While I can't see a good solution, I also can't imagine this working too well
>>either. What kind of value do you choose for $nominal.image.width.in.points
>>that works more often than it doesn't?
The answer to my own question is that this doesn't work too well,
but there is no better solution (short of an extension that allows
the stylesheet to get the content's implicit dimensions).
>Again, same objection as the last one.
Which is what? (Sorry, I'm not trying to be dense. Must be
too early still for me.)
> Perhaps you're trying to over specify these measures in order to accommodate XSL processing issues which, in tern, are an over specification of the HTML output. Why not leave the Image attributes in HTML for final and dynamic sizing to an external CSS? With a CLASS or ID attribute selector? Surely the admin and upkeep overhead are similar to that of tweaking parameters in the XSL kit and better located in the processing flow. And maybe better understood or learn.
I don't understand what you are suggesting here.
What do you mean "leave the Image attributes in HTML?"
The only attributes on the IMG tag are width and height
and their values must be a unitless number of pixels.
What are you suggesting?
Also, can you tell us more about "dynamic sizing to an external CSS"?
If there is some way, say via properties in the style attribute, that
would allow us to tell browsers how to size graphics, I'd be happy for
us to use that. But I'm unaware of such.
>In general, perhaps this is an decision -- CSS versus XSL parameter -- that should be near the beginning of each update revision cycle?
>
>I know this post is predominantly about image size and scale but I'd like to ask a question about how we would initialize the ALT and TITLE attributes in an image from within the DocBook XML source. Sure a more or less straightforward customization can be done on the XSL style sheets, but shouldn't we be keeping the accessibility issues in view (pardon the pun) at the source, editing level?
Yes, I believe there is a plan for an upcoming release of the DocBook DTD
to add markup to handle such things as ALT and TITLE.
paul