/ Yann Dirson <[EMAIL PROTECTED]> was heard to say:
| On Thu, Feb 07, 2002 at 03:47:41PM -0500, Norman Walsh wrote:
|> / Rory Hunter <[EMAIL PROTECTED]> was heard to say:
|> | Something like, mediawidth vs. reproductionwidth (but not to pretentious)?
|>
|> I take your point. Unfortunately, removing the existing attributes
|> would require waiting until DocBook V6.0. And the semantics of the
|> existing attributes are reproductionwidth and reproductiondepth.
|
| Maybe I'm just confused, but I'd rather distinguish:
|
| physicalwidth (or mediawidth)
| the actual width of the image
|
| viewportwidth
| the width of the area in which the image is to be reproduced
|
| reproductionwidth
| the effective width of the image
|
| [ed.] If I understand well, in the current proposal "width" stands for my
| "viewportwidth", "contentwidth" stands for my "reproductionwidth", and
| we have nothing for my "physicalwidth". Right ?
That's right, but I don't see what value it would provide. If I hand a
presentation system an image, I only need to say two things about it:
"make it this big" and "reserve this much space in the flow for it".
I think, correct me if I'm wrong, you're worried about the case where
the processor can't inspect the image to determine its natural size.
(For example, an XSLT processor generating FOs can't tell how big a
PNG is.)
In that case, you can tell the system how big to make it and how much
room to leave (or you can let the FO processor make some decisions for
you). Some part of the system (the FO processor) will eventually be
able to tell how big the image actually is (unless it's a format the
processor doesn't understand, in which case it isn't going to work
anyway) and do the right thing.
Be seeing you,
norm
--
Norman Walsh <[EMAIL PROTECTED]> | Any bureaucracy reorganized to
http://www.oasis-open.org/docbook/ | enhance efficiency is
Chair, DocBook Technical Committee | indistinguishable from its
| predecessor.
