[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: Re: Notes on graphics and HTML
/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC