[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK: Re: Image scaling
>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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC