Try the latest docbook-xsl-snapshot. The fix should be in there to not output an empty height attribute.
Bob Stayton Sagehill Enterprises DocBook Consulting [EMAIL PROTECTED] ----- Original Message ----- From: Chris Borg To: 'Bob Stayton' Cc: [email protected] Sent: Tuesday, March 06, 2007 8:45 AM Subject: RE: [docbook-apps] intrinsic size of images Hi, I created myself an account on docbook sourceforge and submitted a bug report. What do you think the best way to proceed is in the mean time? Continue using contentheight (with validation error) or stop using ignore.image.scaling and specify sizing attributes for each HTML image? Regards -----Original Message----- From: Bob Stayton [mailto:[EMAIL PROTECTED] Sent: 03 March 2007 08:00 To: Chris Borg Cc: [email protected] Subject: Re: [docbook-apps] intrinsic size of images Indeed, this seems to be a bug in the handling of image sizing attributes in html/graphics.xsl. The result is an img with height="", which browsers interpret as zero height it seems. Could you please file a bug report on the DocBook SourceForge site so this can get tracked and fixed? Bob Stayton Sagehill Enterprises DocBook Consulting [EMAIL PROTECTED] ----- Original Message ----- From: Chris Borg To: 'Bob Stayton' Cc: [email protected] Sent: Friday, March 02, 2007 2:33 AM Subject: RE: [docbook-apps] intrinsic size of images Hi, I was following this thread as I was working with image sizing at the time. I changed the attribute contentheight to contentdepth as per the comments. This removed a validation error I was receiving (Attribute "contentheight" must be declared for element type "imagedata"). However, I encountered problems with images not displaying in HTML (ok in PDF). It seems contentdepth has a problem when used with the param ignore.image.scaling (set to non-zero) in my customization layer (chunk) . I did notice that images that don't have attributes are displayed e.g. those attached to the <note> tag still displayed in HTML. Using contentdepth and setting ignore.image.scaling" select="'0'" displays the image HTML (but not very nicely though). As a result I am currently setting ignore.image.scaling to non-zero and use the attribute contentheight as this gives the required output. However, I still left with a validation error. I am a newbie to Docbook so may be in error or mis-understanding but something doesn't seem quite right. Thanks.... Chris -----Original Message----- From: Bob Stayton [mailto:[EMAIL PROTECTED] Sent: 18 February 2007 06:44 To: Hinrich Aue; [email protected] Subject: Re: [docbook-apps] intrinsic size of images I found the problem by validating a sample file with the attributes you were trying to use. The description in my book has a typo. Where it says contentheight, the attribute name is actually contentdepth in DocBook. When I validated, it pointed out that I had an invalid attribute. If you are using FOP 0.93, then it works with the right attribute name. If you are using FOP 0.20.5, it is a known problem that it does not handle image scaling correctly. Bob Stayton Sagehill Enterprises DocBook Consulting [EMAIL PROTECTED] ----- Original Message ----- From: Hinrich Aue To: [email protected] Sent: Friday, February 16, 2007 2:16 AM Subject: AW: [docbook-apps] intrinsic size of images Hello again, but I was not specific enough. I'm trying to get the exact behaviour described at http://www.sagehill.net/docbookxsl/ImageSizing.html > To keep a graphic for printed output at its natural size unless it is too > large to fit the available width, in which case shrink it to fit, use > scalefit="1", width="100%", and contentheight="100%" attributes. I tried nearly every combination of Width Contentheight Scalefit But it does not work. When I use > scalefit="1", width="100%", and contentheight="100%" attributes. Then the images are scaled wrong. But I cannot figure out wich part is wrong Xsltproc, Fop or my brain? (most likely my brain, I'm stuck) What works for me now is: Use no attributes for small images - works fine Use width=100% attributes for images too big for the pdf page - images are scaled to the right size. Thanks, Hinrich
