Hi Paul

Sorry, the second case should have a contentdepth attribute instead of 
contentwidth. (These both specify a container size into which the image fits)

I’m not sure that I understand your second question. For my purposes, I can see 
in the pdf output that it doesn’t fit. Are you trying to predict, prebuild, 
whether an image will fit or not? Pixel width isn’t an absolute measure but 
look at a few of your cases (image property details) to get a rough idea of 
what pixel width is too large in your case (it may vary depending on screen 

I don’t think it’s relevant in your case but the final complication I had was 
in the online output (javahelp). For that, I tried a whole range of styling 
solutions based on online suggestions but eventually I settled on resizing the 
image in an image editor and testing the output until it was a reasonable width 
in the online output. [Incidentally, resizing images was my best way for me to 
handle inline images as well].

As I said previously, not exactly sophisticated but the most practical solution 
in my case. Feel free to keep asking questions. I’m just sharing my experiences 
and solution until an expert jumps in with something more generalisable!


From: Paul Baumer [mailto:paul.baum...@gmail.com]
Sent: 17 October 2016 04:07 PM
To: Greg Cale <greg.c...@csgi.com>
Cc: docbook@lists.oasis-open.org
Subject: Re: [docbook] Scale Image to fit in width or leave unscaled

Hi Greg,

thanks! I don't see a difference between the attributes of two cases though. A 

Secondly how can I know if an image is too wide to fit on the selected page?


On Mon, Oct 17, 2016 at 4:38 PM, Greg Cale 
<greg.c...@csgi.com<mailto:greg.c...@csgi.com>> wrote:
This is one I have been battling (as a self-taught to novice Docbook user), for 
some time. I was trying to find a common solution for block and inline images. 
What worked in Docbook 4 did not necessarily work after upgrading to Docbook 5. 
Two mins after documenting my solution for my team, your mail came in.

I tried all sorts of combinations of attributes and xsl styling. I ended up 
removing nearly all the image sizing content in our customisation layer and 
settled on this.

For an image that is too wide, add scalefit="1" and contentwidth="100%" 
attributes to the <imagegedata> tag: e.g

        <imagedata fileref="images/excel_ccode.png"/>


        <imagedata scalefit="1" width="100%" fileref="images/excel_ccode.png"/>

2 For an image that is too high to fit onto a page, add scalefit="1" and 
contentwidth="100%" attributes to the <imagegedata> tag

For inline media objects, I just resize them in an image editor – don’t know if 
this is practical in your case though.

There may be other considerations depending on your build tool chain.

I am sure that experts will have a much more sophisticated customisation layer 
solution, but this is simple, works for me and I can easily roll out to the 
rest of my team. I do look forward to seeing solutions from more expert users.

I’d love to get some feedback.


From: Paul Baumer [mailto:paul.baum...@gmail.com<mailto:paul.baum...@gmail.com>]
Sent: 17 October 2016 03:29 PM
To: docbook@lists.oasis-open.org<mailto:docbook@lists.oasis-open.org>
Subject: [docbook] Scale Image to fit in width or leave unscaled


I would like to achieve the following image resizing as a general rule in my 
docbook5. I generate the docbook myself using python. And finally I generate 
pdf from the docbook.

if image width will not fit the page
   it shall be resized to fit in width
   image size shall be left unchanged

I am aware of the scalefit, scale, width and content width. But I am having 
difficulty in using a combination of those to achieve the desired logic above.

All emails in this message string and any attachments are the confidential 
information of CSG Systems International, Inc. (CSG), or its affiliates and 
subsidiaries, and may contain privileged and/or confidential material. If you 
are not an intended recipient, please delete it immediately and notify the 
sender; unintended recipients are not authorized to read or otherwise use the 
information contained herein.

Reply via email to