[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC