This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: Notes on graphics and HTML
- From: Norman Walsh <ndw at nwalsh dot com>
- To: Ed Nixon <ed dot nixon at lynnparkplace dot org>
- Cc: Paul Grosso <pgrosso at arbortext dot com>, docbook-apps at lists dot oasis-open dot org
- Date: Mon, 06 May 2002 16:09:46 -1000
- Subject: DOCBOOK-APPS: Re: Notes on graphics and HTML
- References: <878z73ejuq.fsf@nwalsh.com><5.1.0.14.2.20020503081928.02edbbc0@lynnparknt1>
/ Ed Nixon <ed.nixon@LynnParkPlace.org> was heard to say:
| 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 stylesheets assume a default pixel/inch value. It's a parameter
you can set.
|> > 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.
Actually, I decided to do what you suggest. Make a 5in area and put
the 3in image inside it. But if you turn that off, you get a 3in image.
|> > 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.
Well, you can provide images at different resolutions. And if you're
concerned about accessibility, you should provide text descriptions
too.
| In general, perhaps this is an decision -- CSS versus XSL parameter --
| that should be near the beginning of each update revision cycle?
CSS support is still spotty enough that I'm uncomfortable relying on
it for things that don't degrade usefully.
| 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?
Use textobject.
Be seeing you,
norm
--
Norman Walsh <ndw@nwalsh.com> | There is a great difference
http://www.oasis-open.org/docbook/ | between seeking how to raise a
Chair, DocBook Technical Committee | laugh from everything, and seeking
| in everything what may justly be
| laughed at.--Lord Shaftesbury