On 9/11/2011 1:36 PM, Jon Elson wrote: > Kent A. Reed wrote: >> If I accomplish nothing else, let me at least get y'all to "go slow." >> The documentation sources may be in a precarious state but they can be >> made immeasurably worse through haste (oh the stories I could tell...). >> > Well, the problem is that we DIDN'T go slow! We had a documentation > system that worked, > and produced both PDF and HTML documents in a coherent fashion, and > everything was working. > It used LyX, which was not enjoyed by many developers. It was decided > to go with asciidoc > apparently without much testing, and at least I was totally unaware that > the method of inserting > math equations, etc. was totally non-working for the HTML. Apparently > it has been like this > on the new docs since November or so. Now, also, it appears that in > re-organizing the docs, > large sections are not getting built in the PDFs. I totally get your point, Jon, but let's not compound the problem by moving even more in haste. I'm hopeful that applying a little elbow grease will get this beast across the finish line.
Case in point: I created a filename list of all the 2.4-branch .lyx files and compared it to a similar filename list of all the 2.5-branch .lyx files. The two lists differed by just one file: ./gui/gladevcp.lyx shows up in the newer branches. This says to me that the old material hasn't been lost, just not completely transformed. This says nothing about the disposition of any material newly prepared for 2.5/2.6, of course. As for the latexmath problem. As Pavel noted, one approach is to create image files from the formulas, (just as is done now for the line art). If that's the way it has to be done, then we should be able to automate the process, so that the needed image files are generated directly from the same asciidoc files used for the remainder of the documentation, and not maintained separately as the line-art files are now. I've been exploring the logic of the Makefile and am beginning to understand how the creation of pdf and html documents differ. More later. > So, this is a significant regression, and as we are approaching a new > release, it would be really > good to fix this, even if it requires manual intervention, before the > final release of 2.5 is > published. Agreed. Having bad documentation can be even more frustrating than having no documentation at all. > Jon Regards, Kent ------------------------------------------------------------------------------ Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
