Re: [boost] New Acknowldegement for RenderX
Doug Gregor <dgregor <at> osl.iu.edu> On Aug 17, 2007, at 11:23 AM, Paul A Bristow wrote:
Unless we had a central place where we built Boost PDF documentation. Ideally, we'd have an automated (nightly?) process that built Boost documentation in PDF and HTML. MetaComm is (was?) building the HTML; we'd just need one license to build the PDF.
So on the grounds that it costs nothing to say thanks, I still feel it's the right thing to do.
Makes it harder it ask for that one copy to build PDFs of Boost documentation, if we've already given them the publicity in a public acknowledgment.
Doug, - try us. I hereby grant you permission to use XEP to format Boost project's documentation in server environment until our VP of Sales - Kevin Brown, contacts Boost and emails our formal license for such purpose. Kevin should do it either tonight or in several days (he's out of town). He will also send you a license for DevKit that includes API. I think you will find it useful. Let me know if you need anything else: Java PDF, Docbook PDF related tools: www.renderx.com/tools our new development - DiType: http://moin.renderx.com/rxwiki We always like to work with technology people who promote open standards. Roman Kagarlitsky, CEO www.renderx.com
Roman Kagarlitsky wrote:
Doug, - try us.
I hereby grant you permission to use XEP to format Boost project's documentation in server environment until our VP of Sales - Kevin Brown, contacts Boost and emails our formal license for such purpose.
Kevin should do it either tonight or in several days (he's out of town).
He will also send you a license for DevKit that includes API. I think you will find it useful.
Let me know if you need anything else: Java PDF, Docbook PDF related tools: www.renderx.com/tools our new development - DiType: http://moin.renderx.com/rxwiki
We always like to work with technology people who promote open standards.
Roman, Very many thanks for that: it's a generous offer and I'm sure we'll be able to put that to good use. Doug: is there server space we can put this on? The tricky part I suspect is getting links to images to function correctly, we may need some adjustments to BBv2 before we can make full use of this? John.
Taking this to the docs list... John Maddock wrote:
Doug: is there server space we can put this on?
I brought the possible need for a documentation building server with the moderators last week. Which includes you John ;-) I mentioned setting up a buildbot for this. In particular it would be possible to have a doc building slave which others can ask to build docs with (from the buildbot web interface). If the doc builder is the OSL machine the docs can be made available through beta.boost.org.
The tricky part I suspect is getting links to images to function correctly, we may need some adjustments to BBv2 before we can make full use of this?
Which images? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Taking this to the docs list...
John Maddock wrote:
Doug: is there server space we can put this on?
I brought the possible need for a documentation building server with the moderators last week. Which includes you John ;-)
Um, so you did, now where did I leave that brain of mine....
I mentioned setting up a buildbot for this. In particular it would be possible to have a doc building slave which others can ask to build docs with (from the buildbot web interface). If the doc builder is the OSL machine the docs can be made available through beta.boost.org.
The tricky part I suspect is getting links to images to function correctly, we may need some adjustments to BBv2 before we can make full use of this?
Which images?
Here's the outstanding issue: suppose I have a quickbook file that references some png's (or whatever): [$../graphs/graph1.png] The path ../ is set up so that it's relative to where the html docs are generated (in a html/ subdirectory), but FO files and PDF's currently end up in a long mangled path under bin.v2/. So... neither admonishment graphics, nor referenced image files are found, unless you manually move them to where the FO processor is looking for them. Not fun :-( So the question is how do we get the server to "work". If we instruct it to build from a Jamfile in SVN, then IMO we need to fix up BBv2 so that .fo and .pdf files get placed in a sub-directory (called pdf?) just like HTML does, and then hopefully external image files will get automatically found. In fact I believe this is the "right thing to do" anyway, as it eases local building. Alternatively, the easiest option for the server setup might be to only accepts self-contained .fo files with all the images embedded inside it. Unfortunately I don't believe that XSLT processing can automatically embed externally referenced image files, so that would need a post-processing step or something. Thoughts? John.
John Maddock wrote:
Rene Rivera wrote:
Taking this to the docs list...
John Maddock wrote:
Doug: is there server space we can put this on?
I brought the possible need for a documentation building server with the moderators last week. Which includes you John ;-)
Um, so you did, now where did I leave that brain of mine....
I mentioned setting up a buildbot for this. In particular it would be possible to have a doc building slave which others can ask to build docs with (from the buildbot web interface). If the doc builder is the OSL machine the docs can be made available through beta.boost.org.
The tricky part I suspect is getting links to images to function correctly, we may need some adjustments to BBv2 before we can make full use of this?
Which images?
Here's the outstanding issue: suppose I have a quickbook file that references some png's (or whatever):
[$../graphs/graph1.png]
The path ../ is set up so that it's relative to where the html docs are generated (in a html/ subdirectory), but FO files and PDF's currently end up in a long mangled path under bin.v2/. So... neither admonishment graphics, nor referenced image files are found, unless you manually move them to where the FO processor is looking for them. Not fun :-(
I think the idea of "setting paths ... so that it's relative to where the html docs are generated" is wrong -- if you add "--build-dir" option to bjam, all your paths will be wrong, even with HTML. Is there any option to quickbook/boostbook/docbook to specify search paths for images?
So the question is how do we get the server to "work". If we instruct it to build from a Jamfile in SVN, then IMO we need to fix up BBv2 so that .fo and .pdf files get placed in a sub-directory (called pdf?) just like HTML does, and then hopefully external image files will get automatically found. In fact I believe this is the "right thing to do" anyway, as it eases local building.
Uh, well, removing toolset and other things from build path will be easy. The problem is that now HTML generation is weird -- it generates to $srcdir/html and unconditionally putting thigns to srcdir is bad. So I'd suppose we need to fix that first, and then again, relative paths to images won't work.
Alternatively, the easiest option for the server setup might be to only accepts self-contained .fo files with all the images embedded inside it. Unfortunately I don't believe that XSLT processing can automatically embed externally referenced image files, so that would need a post-processing step or something.
I have no idea/comment on this alternative. - Volodya
Vladimir Prus wrote:
Here's the outstanding issue: suppose I have a quickbook file that references some png's (or whatever):
[$../graphs/graph1.png]
The path ../ is set up so that it's relative to where the html docs are generated (in a html/ subdirectory), but FO files and PDF's currently end up in a long mangled path under bin.v2/. So... neither admonishment graphics, nor referenced image files are found, unless you manually move them to where the FO processor is looking for them. Not fun :-(
I think the idea of "setting paths ... so that it's relative to where the html docs are generated" is wrong -- if you add "--build-dir" option to bjam, all your paths will be wrong, even with HTML.
Is there any option to quickbook/boostbook/docbook to specify search paths for images?
Yes there is, it's the image.src.path option. I haven't tried it though, because the path specified in the <xsl:param> Jamfile option requires a trailing / in the name, but bjam "helpfully" strips the slash from filenames, so specifying paths to external elements that way is currently broken anyway. In any case, how would we set a relative URL from what is currently an "unmentionable" path where the pdf docs are built to the image location? Or even an absolute path for that matter - is $(BOOST_ROOT) generally available in a Jamfile these days?
So the question is how do we get the server to "work". If we instruct it to build from a Jamfile in SVN, then IMO we need to fix up BBv2 so that .fo and .pdf files get placed in a sub-directory (called pdf?) just like HTML does, and then hopefully external image files will get automatically found. In fact I believe this is the "right thing to do" anyway, as it eases local building.
Uh, well, removing toolset and other things from build path will be easy. The problem is that now HTML generation is weird -- it generates to $srcdir/html and unconditionally putting thigns to srcdir is bad. So I'd suppose we need to fix that first, and then again, relative paths to images won't work.
I can only speak for myself here: but personally I really like where the html is placed now, and I'd like pdf's etc to do the same. Frankly I'd be pretty unhappy if the location changed, and coincidently, it would break quite a bit of Boost's current docs. John.
John Maddock wrote:
Vladimir Prus wrote:
Here's the outstanding issue: suppose I have a quickbook file that references some png's (or whatever):
[$../graphs/graph1.png]
The path ../ is set up so that it's relative to where the html docs are generated (in a html/ subdirectory), but FO files and PDF's currently end up in a long mangled path under bin.v2/. So... neither admonishment graphics, nor referenced image files are found, unless you manually move them to where the FO processor is looking for them. Not fun :-(
I think the idea of "setting paths ... so that it's relative to where the html docs are generated" is wrong -- if you add "--build-dir" option to bjam, all your paths will be wrong, even with HTML.
Is there any option to quickbook/boostbook/docbook to specify search paths for images?
Yes there is, it's the image.src.path option.
I haven't tried it though, because the path specified in the <xsl:param> Jamfile option requires a trailing / in the name,
Truly weird interface, I would say.
but bjam "helpfully" strips the slash from filenames, so specifying paths to external elements that way is currently broken anyway.
In any case, how would we set a relative URL from what is currently an "unmentionable" path where the pdf docs are built to the image location? Or even an absolute path for that matter - is $(BOOST_ROOT) generally available in a Jamfile these days?
It is, as a quick look at $svn_trunk/Jamroot will reveal.
So the question is how do we get the server to "work". If we instruct it to build from a Jamfile in SVN, then IMO we need to fix up BBv2 so that .fo and .pdf files get placed in a sub-directory (called pdf?) just like HTML does, and then hopefully external image files will get automatically found. In fact I believe this is the "right thing to do" anyway, as it eases local building.
Uh, well, removing toolset and other things from build path will be easy. The problem is that now HTML generation is weird -- it generates to $srcdir/html and unconditionally putting thigns to srcdir is bad. So I'd suppose we need to fix that first, and then again, relative paths to images won't work.
I can only speak for myself here: but personally I really like where the html is placed now, and I'd like pdf's etc to do the same.
So, the requirement that user should be able to build boost from a readonly medium without copying is lifted?
Frankly I'd be pretty unhappy if the location changed, and coincidently, it would break quite a bit of Boost's current docs.
What's going to break, specifically? Note that even now, the doc location is different when building full boost docs, and when building docs for just a single library. - Volodya
Vladimir Prus wrote:
Is there any option to quickbook/boostbook/docbook to specify search paths for images?
Yes there is, it's the image.src.path option.
I haven't tried it though, because the path specified in the <xsl:param> Jamfile option requires a trailing / in the name,
Truly weird interface, I would say.
None the less, all the Docbook XSL stylesheets when they accept a path-prefix *require* that it terminate in a /.
In any case, how would we set a relative URL from what is currently an "unmentionable" path where the pdf docs are built to the image location? Or even an absolute path for that matter - is $(BOOST_ROOT) generally available in a Jamfile these days?
It is, as a quick look at $svn_trunk/Jamroot will reveal.
Ah, OK good.
I can only speak for myself here: but personally I really like where the html is placed now, and I'd like pdf's etc to do the same.
So, the requirement that user should be able to build boost from a readonly medium without copying is lifted?
The user doesn't need to build docs though: they already exist in the distribution.
Frankly I'd be pretty unhappy if the location changed, and coincidently, it would break quite a bit of Boost's current docs.
What's going to break, specifically? Note that even now, the doc location is different when building full boost docs, and when building docs for just a single library.
Yep, which is a real pain. There are several recent libraries in SVN now that use quickbook, but put there docs in libs/libname/doc/html rather than integrating into the central doc/ build, which IMO is getting out of hand and doesn't scale to large numbers of libraries. See regex, Bimap, um quickbook, and I'm sure others for examples. But all this is moot, if there is a way to put the output *wherever you want it*, *and* there is a way to pass URL's to xsltproc without bjam helpfully stipping off the trailing / :-) John.
Vladimir Prus wrote:
Uh, well, removing toolset and other things from build path will be easy. The problem is that now HTML generation is weird -- it generates to $srcdir/html and unconditionally putting thigns to srcdir is bad. So I'd suppose we need to fix that first, and then again, relative paths to images won't work.
FWIW: I have worked out a solution that almost works. I wrote a manifest install generator that is able to take the path to a manifest file as its input and will copy all files that are described by this file to whatever location is desired. I did this with some little shell scripts (residing in bjam actions) and making use of copy and mkdir commands as the only external tools required. This works already for windows and linux. Currently boostbook.jam however is hardwired to generate the docs to $src/html, but this is easy to change. Roland aka speedsnail
Roland Schwarz wrote:
Vladimir Prus wrote:
Uh, well, removing toolset and other things from build path will be easy. The problem is that now HTML generation is weird -- it generates to $srcdir/html and unconditionally putting thigns to srcdir is bad. So I'd suppose we need to fix that first, and then again, relative paths to images won't work.
FWIW: I have worked out a solution that almost works. I wrote a manifest install generator that is able to take the path to a manifest file as its input and will copy all files that are described by this file to whatever location is desired.
OK, and I have a makefile that puts the output where I want it, and finds all the images etc :-) John.
John Maddock wrote:
OK, and I have a makefile that puts the output where I want it, and finds all the images etc :-)
Sorry, I lost track. I was speaking of Jamfiles. Do you mean Jamfile when saying Makefile? Roland aka speedsnail
Roland Schwarz wrote:
John Maddock wrote:
OK, and I have a makefile that puts the output where I want it, and finds all the images etc :-)
Sorry, I lost track. I was speaking of Jamfiles. Do you mean Jamfile when saying Makefile?
I realise you were speaking of Jamfiles, but no, I really do mean a Makefile if you can still remember what those are like :-) John.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Roman Kagarlitsky Sent: 18 August 2007 05:30 To: boost@lists.boost.org Subject: Re: [boost] New Acknowldegement for RenderX
Doug Gregor <dgregor <at> osl.iu.edu> On Aug 17, 2007, at 11:23 AM, Paul A Bristow wrote:
Unless we had a central place where we built Boost PDF documentation. Ideally, we'd have an automated (nightly?) process that built Boost documentation in PDF and HTML. MetaComm is (was?) building the HTML; we'd just need one license to build the PDF.
So on the grounds that it costs nothing to say thanks, I still feel it's the right thing to do.
Makes it harder it ask for that one copy to build PDFs of Boost documentation, if we've already given them the publicity in a public acknowledgment.
Doug, - try us.
I hereby grant you permission to use XEP to format Boost project's documentation in server environment until our VP of Sales - Kevin Brown, contacts Boost and emails our formal license for such purpose.
Kevin should do it either tonight or in several days (he's out of town).
He will also send you a license for DevKit that includes API. I think you will find it useful.
Let me know if you need anything else: Java PDF, Docbook PDF related tools: www.renderx.com/tools our new development - DiType: http://moin.renderx.com/rxwiki
We always like to work with technology people who promote open standards.
Roman Kagarlitsky, CEO www.renderx.com
This is an kind offer we would be most curmudgeonly to refuse ;-) (It would be nice if RenderX were *using* Boost too - then we can include you in our 'Who's Using Boost' page). Thanks. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (6)
-
John Maddock -
Paul A Bristow -
Rene Rivera -
Roland Schwarz -
Roman Kagarlitsky -
Vladimir Prus