Re: DOCBOOK-APPS: Notes on graphics and HTML
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?
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 ems, $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.
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?
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?
Again, same objection as the last one. 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.
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?
If I'm betraying my ignorance of DocBook facilities that already exist my
apologies; I admit to not being real knowledgeable at this level of detail.
Thanks. ...edN
Re: DOCBOOK-APPS: 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 ems, $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
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 08:47 AM 03/05/2002 -0500, Paul Grosso wrote:
Norm and I discussed this some more off line and we clarified
several things for each other.
Mmmm...
Some more comments embedded.
snip
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.
Don't understand this assertion, I'm afraid, unless you are referring
solely to images. And I think the cut/paste below contradicts this assertion.
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.
Perhaps nobody who says anything notices; there may be a silent but
significant minority that just shrugs and moves on; but that's another
discussion.
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?
My interpretation of what is being suggested is that the image attributes
you set via XML -- XSL -- HTML processing will be imbedded as attribute
values in the HTML source code output; if I'm not mistaken these values
will override any values I may choose to establish in my customized
external CSS; if that is the case then you are taking away my ability and
that of the end user to customize at view time in favour of customizing at,
say, serve time. Further, I'm not convinced customizing at serve time is
necessary when it can be done (in many cases) adequately and more
simply/flexibly at view time, i.e. with CSS and/or alternative CSS files.
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.)
Something got chopped out in your response and I don't remember precisely
what it was. Let's assume it was related to converting inches to pixels/inch.
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.
I've pasted in a section from the HTML 4.01 specification (sorry for the
formatting.) Things may have changed in subsequent versions of HTML but I
don't have them handy.
It seems to indicate that, at minimum, percentages may be specified and
length units. In addition, there are other attributes associated with IMG:
style, vspace, hspace, align, etc. All, in one way or another, potentially
inter-related to the discussion. Here's the clip:
//***
height = length [CN]
Image and object height override.
When specified, the width and height attributes tell user agents to
override the natural image or object size in favor of these values.
When the object is an image, it is scaled. User agents should do their best
to scale an object or image to match the width and height specified by the
author. Note that lengths expressed as percentages are based on the
horizontal or vertical space currently available, not on the natural size
of the image, object, or applet.
The height and width attributes give user agents an idea of the size of an
image or object so that they may reserve space for it and continue
rendering the document while waiting for the image data.
**//
All of this aside, we also have the DIV element, into which an image may be
imbedded and with which a great deal can be done in terms of space.
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.
If relative in addition to pixel level units are permitted and they can be
used in the context of CSS, then it is possible to change the relative
amount of space occupied by an image by changing the CSS that is being
used. This should and can (in at least one instance --
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 11:15 2002 05 03 -0400, Ed Nixon wrote:
At 08:47 AM 03/05/2002 -0500, Paul Grosso wrote:
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.
Don't understand this assertion, I'm afraid, unless you are referring solely to
images. And I think the cut/paste below contradicts this assertion.
I've answered below.
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?
My interpretation of what is being suggested is that the image attributes you set via
XML -- XSL -- HTML processing will be imbedded as attribute values in the HTML
source code output;
Yes. If the DocBook source gives sizing attributes, they
will/should be passed through to the HTML, I would think.
if I'm not mistaken these values will override any values I may choose to establish
in my customized external CSS; if that is the case then you are taking away my
ability and that of the end user to customize at view time in favour of customizing
at, say, serve time.
Then you shouldn't have put those values into the DocBook source.
The stylesheets aren't trying to take anything away from you, they
are just translating the DocBook input into HTML output. If you
have a different plan for how images should be scaled, then I assume
your DocBook input wouldn't have any sizing attributes.
Further, I'm not convinced customizing at serve time is necessary when it can be
done (in many cases) adequately and more simply/flexibly at view time, i.e. with CSS
and/or alternative CSS files.
I don't know how to scale images via CSS in such a way as to
provide much greater end-user flexibility than you can get
with straight HTML. In any case, as I've said above, if you
put size info on the DocBook source, the stylesheets have to
assume you meant it and want it so they translate that, as
best they can, to the HTML.
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.
I've pasted in a section from the HTML 4.01 specification (sorry for the formatting.)
Things may have changed in subsequent versions of HTML but I don't have them handy.
It seems to indicate that, at minimum, percentages may be specified and length units.
In addition, there are other attributes associated with IMG: style, vspace, hspace,
align, etc. All, in one way or another, potentially inter-related to the discussion.
Here's the clip:
//***
height = length [CN]
Image and object height override.
When specified, the width and height attributes tell user agents to override the
natural image or object size in favor of these values.
When the object is an image, it is scaled. User agents should do their best to scale
an object or image to match the width and height specified by the author. Note that
lengths expressed as percentages are based on the horizontal or vertical space
currently available, not on the natural size of the image, object, or applet.
The height and width attributes give user agents an idea of the size of an image or
object so that they may reserve space for it and continue rendering the document
while waiting for the image data.
**//
vspace, hspace, and align have nothing to do with image sizing.
Only html::img.{width,height} have anything *directly* to do
with image sizing. Note that the spec says %Length; is nn
for pixels or nn% for percentage length (that quote comes
straight from the DTD).
So the only capability beyond given a dimension in pixels is
the nn% which, as you note, is a percent of the available width.
This is precisely what Norm and I were discussing in an earlier
message where we exhanged:
-
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
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 10:43 AM 03/05/2002 -0500, Paul Grosso wrote: snip if I'm not mistaken these values will override any values I may choose to establish in my customized external CSS; if that is the case then you are taking away my ability and that of the end user to customize at view time in favour of customizing at, say, serve time. Then you shouldn't have put those values into the DocBook source. The stylesheets aren't trying to take anything away from you, they are just translating the DocBook input into HTML output. If you have a different plan for how images should be scaled, then I assume your DocBook input wouldn't have any sizing attributes. Good point. Would this get me into difficulties if I were trying to single source to other formats such as PDF? Further, I'm not convinced customizing at serve time is necessary when it can be done (in many cases) adequately and more simply/flexibly at view time, i.e. with CSS and/or alternative CSS files. I don't know how to scale images via CSS in such a way as to provide much greater end-user flexibility than you can get with straight HTML. It's not so much a question of how for the flexibility, it's a question of who... and when in the process. snip So the only capability beyond given a dimension in pixels is the nn% which, as you note, is a percent of the available width. This is precisely what Norm and I were discussing in an earlier message where we exhanged: Yes. And as observers of the list content we all know that there is a tremendous volume of mail from people, like myself, trying to get their heads around the handling of images in numerous contexts. It may not have occurred to some of them, for example, to leave out the dimensional data in the XML source. While I still have a question about leaving these values uninitialized in single sourcing to other output formats (including direct display in browsers), it's a useful insight that is somewhat outside technical functionality of the schema and the style-sheets. More of a usage option, if you will. Thanks for that. Since you've brought this thread full circle there's probably not much more to be gained; I'll sign off with again thanks. Regards. ...edN
Re: DOCBOOK-APPS: Notes on graphics and HTML
At 12:41 2002 05 01 -0700, Norman Walsh wrote:
I spent some time today working on new code to map DocBook V4.2 image
semantics (a superset of previous semantics) to HTML. A number of
compromises were required along the way.
I probably won't be able to post the new code until I get back home,
but here are the notes I wrote as I went. Comments, etc., most welcome.
I find use of the terms like width are ambiguous. I've gotten into
writing things like docbook::graphic.width and html::img.width.
!-- The HTML img element only supports the notion of content-area
scaling; it doesn't support the distinction between a content-area and
a viewport-area, so we have to make some compromises.
Pretty much true, but note that html::img.{width,height}=xx% implies
that the graphic should be scaled to xx% of the available width
(aka of the viewport-area).
One thing I'm confused about is whether docbook allows values of the
form xx% for docbook::graphics.{width,depth} and
docbook::graphics.content-{width,depth} and, if so, what they all mean?
Unless I hear otherwise, I'll assume that docbook::graphics.{width,depth}
values can only be lengths with units being one of the following and
nothing else: cm, mm, in, pt, pc, px.
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).
2. If only the viewport-area is provided:
- If scalefit=1, treat it as both the content-area and
the viewport-area. (If you ask for an image in a five inch
area scaled to fit, we'll make the image five inches to fill
that area.)
- If scalefit=0, ignore it.
Note: this is not quite the right semantic and has the additional
problem that it can result in anamorphic scaling,
Why should this have to result in anamorphic scaling? Can't we define the
semantic so that anamorphic scaling doesn't occur?
which scalefit
should never cause.
True.
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 ems, $points.per.em
Or just say that it is an error for docbook::graphics.{width,depth} to be
assigned a value whose unit is em.
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?
Scale can be problematic. Scale applies to the contentwidth, so
a scale of 50 when a contentwidth is not specified is analagous to a
width of 50%.
This is confused/confusing. You are talking about contentwidth and width
in the same sentence without making it clear if you are talking about
docbook::graphic.content-width or docbook::graphic.width or html::img.width.
I think you're talking about docbook::graphics.scale=50. I think you're
saying that this is equivalent to docbook::graphics.content-width=50%. (It
sure isn't equivalent to
