On Thursday 02 January 2003 08:37 pm, Beman Dawes wrote: > At 06:08 PM 1/2/2003, Douglas Gregor wrote: > >On Monday 30 December 2002 03:40 pm, Beman Dawes wrote: > >> * Those who access docs directly via the web site. > >> > >> The need here is to continue to have well-integrated HTML available. > > > >What do you mean by "well-integrated"? > > An exact mirror of the web-site, ready to browse with any reasonable web > browser. > > Another way of looking at it is that HTML has special status because it > provides the on-line web documentation, and we can't do anything to break > the web site.
Thanks for the clarification. I expect that we can get this integration in the near future. I also expect that, as the DocBook-based documentation system evolves, we'll find that it can be used to automate more of our mundane tasks. I've already mentioned generation of the library lists; the newest version of the stylesheets also supports generation of testsuite documentation and Jamfiles (hence the Boost.Function breakage in the regression tests). > >This is an important concern: at the moment, the PDF is ~230k and the > > HTML > > >is > >~430k. And that's with only Function, Signals, and Ref documented. > > The PDF doesn't bother me because that will live somewhere separately. > > Is that HTML size a concern? Let's see - the current docs for those > functions adds up to about 132k. What has happened to cause that increase > in size? If we aren't using CVS to store the generated files, then I don't think there is cause for concern. The increase in size comes from lots of little things - DocBook adds a lot more navigation markup than I put in my documentation manually (navigation headers & footers, table of contents in a few places), and there is more in the documentation (e.g., the testsuite descriptions). I also just realized that I had 100k of cruft in the directory :) > >The best solution here is probably to generate them on a nightly basis > > and > > >make them available in some public place. I'll volunteer for that, of > >course. > > Yes, I think keeping the bulk of the generated material on a separate web > site is best. That way no one pays for storage space or download time > unless they use it. > > We can probably set that up as a separate SourceForge project so that no > one person has to worry about the administration. I'll look into this. Would there be any objections to just using the existing 'boost' sourceforge project? > >that don't have DocBook documentation. I would then suggest that the > >"Documentation" link on the Boost site be changed to contain links to the > > > >1.29.0 documentation (in the local directory tree) and to the CVS > >documentation (somewhere off in autogenerated land). > > I don't have enough knowledge yet to comment. I guess it is time to look at > samples. Where should I look? The generated HTML is here: http://www.cs.rpi.edu/~gregod/Boost/ I'm going to try to find a way to make the "Documentation" chapter appear on a single HTML page that serves as the entry point to the documentation. The XML input is in the sandbox under libs/documentation/examples. Doug ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Boost-docs mailing list [EMAIL PROTECTED] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
