OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[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