John Maddock wrote:

...

The release candidate for the PDF build of the 1.38 docs is now available from http://boost.cowic.de/rc/pdf/, unless anyone spots any last minute issues, I'll put these on sourceforge at the weekend.

If you look at the toolset table in bjam.pdf, pages 3-5. There is some text which is "jumbled" on some of the rightmost cells. And in other of those right most cells it compresses the text. I guess for the former it's compressing the text so much that the letter overrun each other. No idea how that might be fixed... But going ahead and posting the PDFs even with that problem is OK by me.

Ah good catch, looks like XEP is being extra clever and compressing preformatted text to ensure it doesn't run off the page... I don't see any easy way to fix this - basically the table is too big/wide for print formatting, and although it's technically possible to generate landscape tables - they can't run over more than one page (there are problems getting the necessary formatting attributes onto the XML as well). I think in the long run, since the first column is mostly empty, could this table be split into 2 tables with just 3 columns each: one for build.bat on Windows and one for build.sh on Unix? Thanks, John.

...

I think in the long run, since the first column is mostly empty, could this table be split into 2 tables with just 3 columns each: one for build.bat on Windows and one for build.sh on Unix?

Sure... But I doubt I'm the only one that has preformated text on the last column of a wide table. Is there a way to tell it to go ahead and force wrap the cell content? And also to have it auto-size the columns, like HTML, as the first column has extra padding?

I've tracked this down to a bug in our XSL customization layer (a "keep-together" attribute was being interpreted a little more literally than I was expecting), I've also changed verbatim blocks (i.e. code blocks) to allow line-wrapping using a "carriage return" character as a hyphenation character, so very long lines of code don't get truncated any more. On the table column width front, I've no idea how to fix this, I'll try and seek some advice on this from the RenderX folks, Meanwhile the latest PDF build is now on the FTP server, John.

It looks to me as though a more serious problem is all the columns seem to be the same width, not automatically made to fit as well as possible. (There might be an FOP option for this but I haven't found one yet).

No, since all the cells have content that's too long to fit, it just chooses equal-width cells, which is pretty reasonable IMO.

I also note that the 'wrap-over' happens when the string is too long to fit - so it might be avoided by splitting it by hand into two or more strings. The Notes:, for example, wrap perfectly.

I need to narrow this down some more, and check I have the latest XEP version: it appears that as soon as you put an fo:inline element inside a table then line wrap gets turned off :-(

Or we could 'complain' to RenderX - they were helpful last time I raised a query?

Let me see if I can create a reduced test case first and figure out what's going on. I'll also look into the more general issue of long lines of code bleeding off the page edge...(which should be fixable using xsl:param's) John.