[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] Image sizing in HTML output
On Wed, Jul 16, 2003 at 09:39:17PM -0700, Seth Nickell wrote: > Hi, > > I'm an author of a fairly long document (the GNOME Human Interface > Guidelines http://usability.gnome.org/hig) with a lot of images (all > PNG). Because our images generally represent screenshots, we have > written a little tool that regenerates them automatically from an > interface prototyping tool's file format. Thus we have a file per > chapter that contains most of the screenshots as abstract UI mockups and > we can run a little command and it generates the PNGs for us. > > The sizes of images change though, and not always in predictable ways > (i.e. when we actually modify a mockup we expect the PNGs size to > change). For example, a minor change in the default "theme" of GNOME > will result in screenshots whose size varies from the previous version > by several pixels in either dimension. > > The problem is that we've run into serious issues with our HTML output > if we do not hardcode image sizes in the DocBook source using depth and > width attributes. If we don't hardcode sizes, relative linking functions > terribly in most browsers. The browser jumps to a physical location on > the page, before the images are loaded. Then when the images load, the > page is much longer and the place you wanted to be is well off the > screen. This is a sort of embarassing UI problem for set of interface > guidelines :-) > > Does anyone have a trick or technique for addressing this problem (or > suggestions of how they would do it)? Right now I'm either going to grin > and bear it (which means doing a lot of unnecessary work "maintaining" > sync between PNG sizes and docbook attributes) or write some sort of > nasty Perl hack that rewrites the HTML output to add in depth and width > tags. If you are using Saxon or Xalan, set the use.extensions paramter to 1 (and make sure the graphicsize.extension parameter is not changed from its default of 1). That activates some Java functions that calculate the intrinsic size of the graphic image. The intrinsic width and depth values are passed to the 'process.image.attributes' template in html/graphics.xsl as the parameters scaled.contentwidth and scaled.contentdepth, respectively. That template outputs the attributes for <img>. You could add another "xsl:when" case to the first xsl:choose in that template to output a height: ... <xsl:when test="$scaled.contentdepth != ''"> <xsl:attribute name="height"> <xsl:value-of select="$scaled.contentdepth"/> </xsl:attribute> </xsl:when> </xsl:choose> There is a caution here, though. If the Java function cannot determine the intrinsic depth, then the default value of the scaled.contentdepth parameter passed to the template will be set to the $nominal.image.width value, which is 540, probably not what you want. (it should be $nominal.image.depth, a bug I just fixed in CVS). So you might want to make this attribute conditional on the value not matching the nominal value. If you can't use Saxon or Xalan, then you will have to add contentdepth attributes to each image. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 The SCO Group fax: (831) 429-1887 email: bobs@sco.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]