This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Image scaling
- From: "Matt G." <matt_g_ at hotmail dot com>
- To: docbook at lists dot oasis-open dot org
- Date: Thu, 17 Jan 2002 09:56:34 +0000
- Subject: DOCBOOK: Re: Image scaling
- Bcc:
>From: Norman Walsh <ndw@nwalsh.com>
>Subject: DOCBOOK: Image scaling (was Re: DocBook TC Meeting
> Minutes: 15 Jan 2002)
>Date: Wed, 16 Jan 2002 07:23:23 -0500
>
FWIW, I'm finding your description of the semantics of the imagedata
attributes to be very counterintuitive. Graphics (though not necessarily
print-oriented) is one of those things I feel a bit qualified to talk about.
In case anyone cares, I'd like to supply my own interpretation of these
attributes (as described in TDG v2), then enumerate my expectations for the
results of the previous examples.
align:
controls alignment of the viewport, within the output column
depth:
describes the height of the source image, serving as the
authoritative source, in the case that this information is
actually available from the image data representation.
If not provided or otherwise available, this should default
to the value of 'width'.
width:
describes the width of the source image (same behavior as
depth)
scale:
percentage scaling of the image, relative to the output
viewport.
scalefit:
I think this attribute is the primary source of confusion,
and with good reason. If '1', it changes the semantics of
width and height to describe the viewport, and scales the
image to fit that. If '0' (default), the output viewport
defaults to the constraints of the output column, while
retaining the shape of the image (as per 'width' &
'height'). it should display the image as:
w = clmn_width * (scale / 100)
h = depth * clmn_width / img_width * (scale / 100)
So, maybe Yann has a point that this is an area in need of cleanup. I
understand Yann's position that it would be nice to separate out this
formatting information, since its semantics are really presentational.
However, to do this cleanly, you'd have to define an out-of-band layout
format, which could supply formatting information for at least the images
(individually, or perhaps in groups) in a given document. While I think it
could make sense to do that, the benefits are somewhat dubious, and the
managability burden of having to maintain at least two closely coupled
files, per document, may not be justified by the current usage of docbook.
Furthermore, the tools situation is currently in flux (WRT XSL-FO being
still a ways from maturity), and is causing users plenty of trouble.
Therefore, I say we should cleanup the semantics and patch the holes of
imagedata, and maybe consider moving this information out of the core
docbook vocabulary, a ways down the road.
In a follow-on message, I'll attempt to propose an approach for cleaning up
& augmenting the imagedata attributes. But, for now, I'll go over Norm's
examples, as I planned. (for the first few, we actually agree, but keep
reading... ;)
<imagedata fileref="image.eps" width="3in" depth="5in" scalefit="1"/>
Renders the image scaled down to a 3in by 5in region.
<imagedata fileref="image.eps" width="3in" depth="3in" scalefit="1"/>
Renders the image scaled down to a 3in by 3in region.
<imagedata fileref="image.eps" width="3in" depth="5in"/>
Renders the image at clmn_width by clmn_width / 3in * 5in region.
<imagedata fileref="image.eps" scale="120%">
Renders the image in a clmn_width * 1.2 by clmn_width / 6in * 12in region,
*if* the stylesheets/formatter can discover that the image is really 6in by
10in. Otherwise, it might make some assumption about the dpi, and assume a
square pixel aspect ratio (or just treat the image as square, if it's a
vector image w/o a size).
<imagedata fileref="image.eps" width="100%" scalefit="1"/>
Renders the image in a 6in by 10in region, or however big the formatter
thinks the image actually is. (where does TDG say anything about the
semantics of 'width' and 'depth' changing, based on their units?).
<imagedata fileref="image.eps" width="100%"/>
Renders the image in a clmn_width by clmn_width / 6in * 10in region,
depending on what size the formatter discovers/assumes about the image.
>We have all the attributes we need
Clearly, I disagree. As specified in version 2 of TDG, the current
rendering model is counterintuitive and insufficiently flexible. Maybe part
of our disagreement is that you're working from different
information/assumptions than I am, in which case it would really help if
you'd start by better specifying the 'scale' attribute (i.e. is it with
respect to the output viewport, the output column, or the source image, and
does this ever change?). Furthermore, you seem to assume that the image
'width' and 'depth' (I really would have used 'height', since depth is often
used to describe the number of bits per pixel) are still available, if not
explicitly specified. There also seems to be a bit of confusion about
'width' and 'depth'.
>and we need all the attributes we have.
I would say "we need at least all the information that's currently
provided", though I'd sure to see 'scalefit' go the way of the dinosaurs and
keep the image display parameters a bit more orthogonal.
>(That some of this is presentational and not strictly semantic is
>something we have to live with, I think.)
As I said, I definitely agree with this, for the foreseeable future.
Anyhow, thanks for considering my reply (it took me a while to compose, as I
had to revise it a couple times).
Matt Gruenke
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx