This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Notes on graphics and HTML
- From: Norman Walsh <ndw at nwalsh dot com>
- To: docbook-apps at lists dot oasis-open dot org
- Cc: Paul Grosso <pgrosso at arbortext dot com>
- Date: Wed, 01 May 2002 12:41:49 -0700
- Subject: DOCBOOK-APPS: Notes on graphics and HTML
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.
<!-- 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.
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.)
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, which scalefit
should never cause.
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.
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
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.
Instead, the stylesheets define a $nominal.image.width.in.points
and convert percentages to actual values based on that nominal size.
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%. (If a contentwidth is specified, the scaling factor can
be applied to that value and no problem exists.)
If scale is specified but contentwidth is not supplied, the
nominal.image.width.in.points is used to calculate a base size
for scaling.
Warning: as a consequence of these decisions, unless the aspect ratio
of your image happens to be exactly the same as (nominal width / nominal height),
specifying contentwidth="50%" and contentdepth="50%" is NOT going to
scale the way you expect (or really, the way it should).
Don't do that. In fact, a percentage value is not recommended for content
size at all. Use scale instead.
Finally, align and valign are troublesome. Horizontal alignment is now
supported by wrapping the image in a <div align="{@align}"> (in block
contexts!). I can't think of anything (practical) to do about vertical
alignment.
-->
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | To enjoy yourself and make others
http://www.oasis-open.org/docbook/ | enjoy themselves, without harming
Chair, DocBook Technical Committee | yourself or any other; that, to my
| mind, is the whole of
| ethics.--Chamfort