On 2013-08-21 16:24-0700 Alan W. Irwin wrote: > In the next day or so I plan to play a bit more with dblatex to see if > I can generate dvi results with it, and I am also ready to deal with > any issues you find as well, but otherwise I believe I have completed > this project.
Hi Andrew: It turned out the source of the dvi issue was a dblatex bug (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720624 for a description of the problem and a patch to fix it). Once I applied that patch, the dblatex command finally started working properly to generate dvi results both when dblatex was invoked directly or indirectly via "xmlto --with-dblatex". Please give the updated documentation build a spin following the (newly updated as of revision 12497) directions in doc/docbook/README.developers. Also, please feel free to update that file if you feel more details about the packages required by xmlto are needed. Revision 12497 is the last commit I plan to do in the near term concerning the DocBook backend tools that we use unless you find some easily fixed issue in the documentation build. In the medium term (i.e., after the next release when we will be using these new backend tools to help generate our website) I plan two more DocBook backend changes. The first of those is to disable use of the deprecated SGML/DSSSL backend tools completely which will allow me to do the second change which is to use UTF-8 directly in our DocBook source. The big advantage of UTF-8 is it allows us to include a potentially enormous range of glyphs in our DocBook source including all of the mathematical and human-language glyphs that appear in our examples. Part of that range allows overlining and underlining so UTF-8 provides a fundamental solution for representing the UTF-8 string "S̅(f̲r̲e̲q̲)" in our documentation (which is the last outstanding issue of the present approach as far as I know). (I hope your mailer is UTF-8 aware so you can read that UTF-8 string as intended!) The only disadvantage (which I consider to be minor) of UTF-8 is that the dvi format is fundamentally incompatible with it outside the very narrow range of glyphs currently represented in our documentation. The inescapable conclusion is that the dvi format will have to be dropped from our documentation once we extend the range of glyphs in our documentation in the slightest. (In fact, UTF-8 glyphs for overlining and underling are already outside the valid glyph range of the dvi format.) For further comments about how UTF-8 can be implemented for PDF, PostScript, and HTML and the excellent results I have already had with a proof of concept for that implementation please see the updated discussion in doc/docbook/README.developers. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
