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] | [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"/>

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]