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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[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.

	controls alignment of the viewport, within the output column

	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'.

	describes the width of the source image (same behavior as

	percentage scaling of the image, relative to the output

	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: 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC