This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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 "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.


>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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]