From: <ai...@us...> - 2008-09-22 20:18:27
|
Revision: 8794 http://plplot.svn.sourceforge.net/plplot/?rev=8794&view=rev Author: airwin Date: 2008-09-22 20:18:14 +0000 (Mon, 22 Sep 2008) Log Message: ----------- Update (and considerably simplify) developer information for the PLplot documentation. Modified Paths: -------------- trunk/doc/docbook/README.developers Modified: trunk/doc/docbook/README.developers =================================================================== --- trunk/doc/docbook/README.developers 2008-09-22 17:50:53 UTC (rev 8793) +++ trunk/doc/docbook/README.developers 2008-09-22 20:18:14 UTC (rev 8794) @@ -1,8 +1,5 @@ PLPLOT DOCUMENTATION IN THE DOCBOOK FORMAT (Notes for contributors/developers) - - Authors: Rafael Laboissi\xE8re <ra...@ic...> - Alan W. Irwin <ir...@be...> $Id$ @@ -17,175 +14,49 @@ includes man pages of the API as well as complete versions of the documentation in html, dvi, postscript, pdf, and info form. -This documentation project started as a conversion (under the direction of -Rafael Laboissi\xE8re) of the old (1995 or earlier) version of the PLplot -documentation in latexinfo format to DocBook SGML. Since that conversion, -there has been a lot of work by RL to upgrade to DocBook 4.1 XML, improve -the configuration of the documentation builds, and to extend the output -forms to many different formats. The build system has now been essentially -stabilized. - -Another aspect of this project (under the direction of Alan W. Irwin) has -been to improve the content of the documentation that was converted from the -1995 version. - -The content improvement that has occurred includes a complete API -description. This XML source for the API has been parsed both to generate -man pages and perl wrappers. We have also revised some sections and added -several others. Despite this extensive effort there is still quite a bit to -do as evidenced by the many times the string "NEEDS DOCUMENTATION" appears -in the results. Thus, AWI asks for your help to address some of these -remaining documentation issues. - Configuring and Building ======================== -If you help with improving the content, you will want to build the -documentation from the DocBook source so you can immediately see and +If you would like to help with improving the content, you will want to build +the documentation from the DocBook source so you can immediately see and evaluate the results of your efforts. -Here is how. It is assumed you have the appropriate automake, autoconf, and -DocBook software packages loaded on your machine (see Package Lists, below). -Although in the past we built the documentation successfully on RH 6.2, that -distribution is now so outdated (and no longer available to us) that -we have removed those instructions. Here we concentrate on the Debian -woody instructions. Until we gain experience ourselves with other -modern versions of distributions, you will have to infer what to do for them -based on our Debian woody experience. +Here is how. Simply add the cmake option -DBUILD_DOC=ON to your normal +cmake command-line options for the PLplot build. The resulting cmake step +looks for all the tools required for the documentation build and turns off +the documentation build and gives WARNING messages if any of those required +tools are missing. Those messages should be sufficient for you to figure +out what DocBook/XML related tools you need to install in order to build the +documentation. N.B. As far as we know, the complete set of required tools +is only available on Linux so you will need a Linux system to do a +documentation build. -A. Package Lists. +If you are in a hurry you can validate your changes to the files in +doc/docbook/src by simply typing the -Debian woody: I am not sure all of these are required, but this is what -I have on my system. I am positive the -doc packages are not required, but -it is nice to have them. +make validate -(1) docbook-xml docbook docbook-dsssl docbook-xsl-stylesheets (docbook-doc) +command at the top of the build tree. This make target is only available if +the PLplot CMake-based build system has found the onsgmls software +application (which is distributed as part of openjade) on your system. This +quick check works regardless of whether you decide to build the +documentation with -DBUILD_DOC=ON or not. Using "make validate" is +especially useful if you are just making a series of simple changes to the +files in doc/docbook/src, and you don't really feel it is necessary to check +every change by doing a complete documentation build. -(2) tetex-extra (tetex-doc) +Testing the documentation that has been built. +============================================== -(3) jadetex +All tests are performed in the doc/dockbook/src subdirectory _of the build +tree_. The given test commands are for the bash shell, and $version is +currently 5.9.0. There are no known DocBook back-end issues revealed by the +following tests. -(4) sp - -(5) tidy - -(6) Additional packages (mostly perl modules) required by docbook2x: -libxml2 -libxml-parser-perl (XML::Parser) -libxml-writer-perl (XML::Writer) -libxml-catalog-perl (XML::Catalog) -libxml-dom-perl (XML::Dom) -libxml-perl (XML::Parser::PerlSAX) -libtext-wrapi18n-perl (Text::Wrap) -sgmlspl (which brought in libsgmls-perl) -libxslt1-dev (which brought in libxslt1) - -B. docbook2X. - -Use at least version 0.8.2 available at http://docbook2x.sourceforge.net. -This upstream version has bugs that are fixed in the Debian package -available at http://packages.debian.org/docbook2x. - -C. Configuration - -Within this current directory execute - -setenv YOUR_SHELL1_USERNAME airwin - -but you will want to adjust to the location of the docbook2X perl -subdirectory on your own machine and your own shell1 username as well. -YOUR_SHELL1_USERNAME is only used if you are updating the live website (see -below). - -Now execute: - -./bootstrap.sh #if you are using a fresh copy -rm -f config.cache #if you are rebuilding with new configuration from old copy - -Now execute: - -./configure --with-www-user=$YOUR_SHELL1_USERNAME - -The configure script checks for the following programs: jade, jadetex, -pdfjadetex, perl, and dvips. You should have them installed (see package list -above) and present in the path in order to build the varous versions of the -output documentation. You may also specify the locations of these programs -with the configure options --with-<prog>. Type `./configure --help' for -details. - -The jade program needs to access several DTDs (Document Type Definition). -The availability of the DTDs in the system is checked as well by the -configure script. If they are not found, it is possible to specify them -with the option `--with-sgml-catalogs=CATALOGS', where `CATALOGS' must be a -colon (:) separated list of files. These files must exist in the systems -and contain entries mapping DTD public identifiers into system identifiers. - -On Debian, the default catalog is /etc/sgml/catalog, and it is set up -perfectly to find all the DTD's required. Our catalog experience with RH -6.2 was terrible, but it now looks like RedHat 7.x has a similar catalog -setup to Debian. - -On SuSE-8.1, the configure options must be: ---with-sgml-catalogs=/etc/sgml/catalog:/usr/share/sgml/CATALOG.db42xml \ ---with-xml-declaration=/usr/share/sgml/openjade/xml.dcl - -The configure script also checks for certain essential perl modules (see -package list above). - -If the ./configure completes normally without warning messages or error -messages, then that is a sign you can at least try the next step. But if -there are any problems in the ./configure step, then you probably have to -add packages that you are missing and/or sort out catalog problems -(see note on SGML Catalogs, below). - -D. Tex resources - -If you run out of tex resources (which happened to me with default resources -with Debian woody) then you must add to them. Here is the way to do it with -Debian woody. - -cd /etc/texmf -edit texmf.cnf - -typically the resource that is exhausted is save_size, and in fact -the default 5000 is a ridiculously small value. So change all variations -(save_size, save_size.context, save_size.jadetex, and save_size.pdfjadetex) -to 50000. - -To make these new values available: -dpkg-reconfigure tetex-bin -dpkg-reconfigure jadetex - -[Under SuSE-8.1 and some other distributions, that's enough to execute -"texconfig init" after editing /etc/texmf/texmf.cnf] - -E. Build documentation - -If you don't run out of tex resources, then - -make - -builds all forms of the documentation. - -(To just build the html part use the command - -make plplotdoc-html-0.4.3.tar.gz - -) - -F. Test documentation - -cd src - 1. man pages. -These are the tcsh commands to check the man pages. Do the bash command -equivalent if that is your shell of choice +(for MANPAGE in *.3plplot; do nroff -man $MANPAGE ; done) |less -foreach tmp (*.3plplot) -nroff -man $tmp |less -end - 2. info pages. info --file plplotdoc.info @@ -193,91 +64,24 @@ 3. web pages. Browse with your favorite browser the index.html file within the current src -directory. Looks good! Mozilla has all the greek letters in Table 3.3. -Konqueror probably would as well if I loaded international support for it. +directory. konqueror and mozilla/firefox/iceweasel give good looking +results including the Greek letters in Table 3-4. 4. dvi file -xdvi plplotdoc-0.4.3.dvi +xdvi plplot-$version.dvi -(Note, there is an xdvi facility to follow cross-references, and that works -well [unlike current info results]) +5. PostScript file -5. postscript file +gv plplot-$version.ps.gz -gv plplotdoc-0.4.3.ps.gz - -Looks good! - 6. pdf file -acroread plplotdoc-0.4.3.pdf +xpdf plplot-$version.pdf -Some problems (ff and fi get translated into weird character strings), but -on the whole not too bad. For example, cross references seem to work well. +Installing the generated documentation (and the rest of the +generated website) at plplot.sf.net +=========================================================== -G. Installing at the live site for plplot.sf.net - -After the output results are tested (see under previous heading), the -results should be copied (assuming you have made a significant change to the -documentation) to the plplot live web site if you have an account on -shell1.sourceforge.net. - -The following command uses ssh a lot so you will be entering your password -a lot at shell1 unless you remember to execute ssh-agent and ssh-add -first. It is only this command which uses your login id at shell1 -which you entered (didn't you?) in the ./configure step above. - -To copy all results to the live website use: - -make www-install - -(You should use this command with discretion after you have carefully -checked all the documentation forms you have created since it completely -removes the old documentation from the live web site and replaces it with -exactly what you have created.) - -Congratulations! You are done (at least until you add some more -documentation to the src/*.xml files, the DocBook source files for all the -PLplot documentation). - -Appendix: Note on SGML Catalogs - -The jade program, as well as the programs in the sp suite -(http://www.jclark.com/sp), work by loading the definitions of DTDs, which -are files present in the system. These files are referred to as "system -identifiers" in the SGML jargon. - -The PLplot DocBook XML sources uses "public identifiers" for declaring the -included DTDs. Here is the complete list that is currently needed by -the PLplot documentation project: - -"-//James Clark//DTD DSSSL Style Sheet//EN" -"-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN" -"-//Norman Walsh//DOCUMENT DocBook Print Stylesheet//EN" -"-//OASIS//DTD DocBook XML V4.1//EN" - -You will find where these public identifiers are used in the XML source by: - -find src -type f | xargs grep PUBLIC -src/plplotdoc-html.dsl.in:<!DOCTYPE style-sheet PUBLIC "@DSSSL_DTD_PUBID@" [ -src/plplotdoc-html.dsl.in: PUBLIC "@DB_SS_HTML_PUBID@" -src/plplotdoc-print.dsl.in:<!DOCTYPE style-sheet PUBLIC "@DSSSL_DTD_PUBID@" [ -src/plplotdoc-print.dsl.in: PUBLIC "@DB_SS_PRINT_PUBID@" -src/plplotdoc.xml.in:<!DOCTYPE book PUBLIC "@DOCBOOK_DTD_PUBID@" [ - -where the various symbols are defined in configure -grep PUBID= configure -DSSSL_DTD_PUBID="-//James Clark//DTD DSSSL Style Sheet//EN" -DB_SS_HTML_PUBID="-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN" -DB_SS_PRINT_PUBID="-//Norman Walsh//DOCUMENT DocBook Print Stylesheet//EN" -DOCBOOK_DTD_PUBID="-//OASIS//DTD DocBook XML V4.1//EN" - -**the key on any Linux/Unix docbook system is to find the catalog file(s) -with the correct mapping between the required pubid's and the system files.** - -On Debian GNU/Linux (version woody) systems, the actual files (system -identifiers) that corresponds to the above 4 public identifiers are properly -identified with the default catalog file: /usr/lib/sgml/catalog. This -may be true on other distributions as well, but if not, the above -information may help to sort out the problem. +Follow the directions in README.Release_Manager_Cookbook. That file is +located in the top-level source tree. This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ai...@us...> - 2010-11-19 22:58:52
|
Revision: 11337 http://plplot.svn.sourceforge.net/plplot/?rev=11337&view=rev Author: airwin Date: 2010-11-19 22:58:46 +0000 (Fri, 19 Nov 2010) Log Message: ----------- Add a list of the back-end tools used to build PLplot documentation in various formats from our DocBook source files. Modified Paths: -------------- trunk/doc/docbook/README.developers Modified: trunk/doc/docbook/README.developers =================================================================== --- trunk/doc/docbook/README.developers 2010-11-19 20:08:26 UTC (rev 11336) +++ trunk/doc/docbook/README.developers 2010-11-19 22:58:46 UTC (rev 11337) @@ -31,14 +31,65 @@ is only available on Linux so you will need a Linux system to do a documentation build. -If you are in a hurry you can validate your changes to the files in -doc/docbook/src by simply typing the +The DocBook Back-end Tool Chains +================================ +PLplot uses a number of different applications to generate +PLplot documentation in various formats from our source DocBook XML files. + +1. man pages. + +Our man pages are generated with a configured home-brew perl script +bin/api2man.pl(.in). That script uses XML::DOM::Parser to parse the +combination of plplotdoc.xml (for entity definitions) and api.xml +(the subset of our DocBook source files which describes our core +library's API) to obtain the information used to generate the man +pages. + +2. info pages. + +Our info pages are generated by a combination of + +bin/info-clean.pl --> db2x_xsltproc --> db2x_texixml --> makeinfo + +where info-clean.pl is a home-brew perl script required (as far as I +can tell from reading comments in it) to get around some of the +db2x_xsltproc limitations. db2x_xsltproc and db2x_texixml are from +the docbook2x package. + +3. web pages. + +Our web pages are generated with openjade. + +4. dvi file + +Our dvi file is generated by + +openjade --> jadetex + + +5. PostScript file + +Our PostScript file is generated from the above dvi file +using dvips. + + +6. pdf file + +openjade --> pdfjadetex + +Validation +========== + +Validation checks that the PLplot Docbook files in doc/docbook/src are +well-formed XML and correspond to the DocBook schema. You can perform +such validation by typing the + make validate command at the top of the build tree. This make target is only available if the PLplot CMake-based build system has found the onsgmls software -application (which is distributed as part of openjade) on your system. This +application (which is distributed as part of OpenSP) on your system. This quick check works regardless of whether you decide to build the documentation with -DBUILD_DOC=ON or not. Using "make validate" is especially useful if you are just making a series of simple changes to the This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ai...@us...> - 2013-08-24 22:39:25
|
Revision: 12497 http://sourceforge.net/p/plplot/code/12497 Author: airwin Date: 2013-08-24 22:39:23 +0000 (Sat, 24 Aug 2013) Log Message: ----------- Update these developer directions based on the current xmlto backend tools that are being used. Also include some plans about further changes once we allow UTF-8 strings in our documentation. Modified Paths: -------------- trunk/doc/docbook/README.developers Modified: trunk/doc/docbook/README.developers =================================================================== --- trunk/doc/docbook/README.developers 2013-08-24 22:36:57 UTC (rev 12496) +++ trunk/doc/docbook/README.developers 2013-08-24 22:39:23 UTC (rev 12497) @@ -12,7 +12,7 @@ (README.developers) instructions for building the documentation from the DocBook source files in this directory. The documentation that is built includes man pages of the API as well as complete versions of the -documentation in html, dvi, postscript, pdf, and info form. +documentation in HTML, dvi, PostScript, PDF, and info form. Configuring and Building ======================== @@ -21,14 +21,17 @@ the documentation from the DocBook source so you can immediately see and evaluate the results of your efforts. -Here is how. Simply add the cmake option -DBUILD_DOC=ON to your normal -cmake command-line options for the PLplot build. The resulting cmake step -looks for all the tools required for the documentation build and turns off -the documentation build and gives WARNING messages if any of those required -tools are missing. Those messages should be sufficient for you to figure -out what DocBook/XML related tools you need to install in order to build the -documentation. N.B. As far as we know, the complete set of required tools -is only available on Linux so you will need a Linux system to do a +Here is how. Simply add the cmake option -DBUILD_DOC=ON to your +normal cmake command-line options for the PLplot build. The resulting +cmake step looks for all the tools required for the documentation +build and turns off the documentation build and gives WARNING messages +if any of those required tools are missing. Furthermore, at run-time +xmlto (used below) checks for required backend tools. So cmake +messages with the -DBUILD_DOC=ON option _and_ run time messages from +xmlto should be sufficient for you to figure out what DocBook/XML +related tools you need to install in order to build the documentation. +N.B. As far as we know, the complete set of required tools is only +available on Linux so you will need a Linux system to do a documentation build. The DocBook Back-end Tool Chains @@ -57,27 +60,103 @@ db2x_xsltproc limitations. db2x_xsltproc and db2x_texixml are from the docbook2x package. -3. web pages. +3. Our HTML and print(dvi, PostScript, and PDF) results are all generated +with xmlto using respectively no special options and the html subcommand, +the experimental --with-dblatex option and dvi subcommand, and +the experiemtnal --with-fop option and the ps and pdf subcommands. -Our web pages are generated with openjade. +N.B. for the dvi results to work as of this date (2013-08) it is +necessary to apply the dblatex patch given at +http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720624 -4. dvi file +The backend tools that the xmlto convenience script selects are +all XML/XSL as opposed to the previous set of SGML/DSSSL backend +tools used to create the HTML and print results. For more information +see "Further notes on the backend tools" below. -Our dvi file is generated by -openjade --> jadetex +Further notes on the backend tools +================================== +Note from AWI on the project he just completed (as of 2013-08) to use +xmlto (a shell script that gives convenient access to a wide variety +of XML/XSL DocBook backend tools) as the DocBook backend generator for +HTML and print (dvi, PostScript, and PDF) forms of our documentation. +(The man and info forms of our documentation are already prepared +using XML/XSL DocBook backend tools.) -5. PostScript file +One immediate advantage of xmlto is that it detects +(at run time) whether all the software components it needs are installed +so this substantantially reduces the testing for DocBook backend components +required of our build system. -Our PostScript file is generated from the above dvi file -using dvips. +The use of the old/deprecated SGML/DSSSL backend tools for HTML and +print are still available (as of 2013-08) if the developer +specifies the PLplot cmake option -DDOCBOOK_XML_BACKEND=OFF along with +-DBUILD_DOC=ON. However, the HTML results from that option are not +very good (the Greek characters in the table giving Roman-Greek +equivalents are gibberish) presumably because bit-rot has set in for +the SGML/DSSSL tools in the decade since there has been any upstream +development for those tools. So at the start of the next release +cycle the plan is to drop use of the SGML/DSSSL backend tools +altogether. +The only limitation of the current xmlto backend results that I am +aware of is the representation of S̅(f̲r̲e̲q̲) is not done very well in +HTML (an empty string is used rather than S̅(f̲r̲e̲q̲)) or the print +results (S(freq) is used rather S̅(f̲r̲e̲q̲)). Note that overlining and +underlining do not work at all for modern PLplot device drivers such +as cairo and qt so a much higher priority should be given to fixing +those issues rather than fixing the issue of representing overlining +and underlining in the generation of the documentation! Furthermore, +instead of using special tricks for dealing with the representation of +overlining/underlining (as was done for the SGML/DSSSL backend tools), +the correct thing to do in the long term (i.e., after the use of +SGML/DSSSL backend tools is completely removed since SGML is not +compatible with UTF-8) is to make the tool chain used to convert our +DocBook documentation to various formats completely UTF-8 aware so +that, for example, UTF-8 glyphs for underlining overlining as well +as UTF-8 strings such as occur in our unicode examples +23, 24, and 26 could be included directly in the DocBook source of +our documentation. -6. pdf file +As if this date (2013-08) it appears to me the best UTF-8 way forward +for html is the current html method (which should be transparent +to UTF-8 strings although I haven't tested that in detail with +truly exotic UTF-8 strings). And the best UTF-8 way forward for +print results is the experimental --backend=xetex option for the +dblatex command. -openjade --> pdfjadetex +To demonstrate the UTF-8 power of xelatex try the xelatex command on +the example given at http://en.wikipedia.org/wiki/XeTeX. All those +non-Western glyphs _and_ scripts seem to come out fine in the +resulting pdf and conversion to an equivalent PostScript result with +pdf2ps seemed to preserve all those glyph and script results as well. +Furthermore, I recently tried +dblatex --backend=xetex -o plplotdoc.xetex.pdf --pdf plplotdoc-print.xml + +and the resulting plplotdoc.xetex.pdf document looked good (both Greek +table and function API) with the default style. Although currently +unnecessary from my perspective, it looks like the dblatex -p option +is what you should use to style such results further if anyone feels +the need. (Note that the --backend=xetex dblatex option is not +accessible from the xmlto --with-dblatex command.) + +The only drawback of this xetex approach that I can determine at the +present time is you can only produce PDF with it. PostScript could +then be generated using pdf2ps, but there is absolutely no way to +produce dvi results using xelatex or the --backend=xetex option for +the dblatex command. So if we do start inserting general UTF-8 +strings into our DocBook source (say a table of Math symbols or +comments concerning our multilingual Peace flag example), we would +have to complete drop dvi, but I think that is an acceptable price to +pay for the huge range of glyphs that are available with UTF-8. So I +believe that dropping dvi and moving to the above command to generate +our PDF documentation is something we should consider for the near +future (when the possibility of using of the SGML backend tools is +completely removed from our build system). + Validation ========== @@ -96,6 +175,15 @@ files in doc/docbook/src, and you don't really feel it is necessary to check every change by doing a complete documentation build. +In addition, the xmlto commands used to build the HTML and print +part of the documentation automatically include a validation step +with xmllint. It turns out that xmllint is more sensitive than onsgmls +to DocBook XML errors. On the other hand, onsgmls handles any +errors it finds with ease while xmllint tends to segfault when there +is a validation error. So use "make validate" +first to detect any obvious validation errors using onsgmls to avoid +situations where xmlto's call to xmllint will segfault. + Testing the documentation that has been built. ============================================== This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ai...@us...> - 2013-10-05 23:29:47
|
Revision: 12582 http://sourceforge.net/p/plplot/code/12582 Author: airwin Date: 2013-10-05 23:29:44 +0000 (Sat, 05 Oct 2013) Log Message: ----------- Update/simplify this documentation for developers who want to build our documentation. Modified Paths: -------------- trunk/doc/docbook/README.developers Modified: trunk/doc/docbook/README.developers =================================================================== --- trunk/doc/docbook/README.developers 2013-10-05 19:51:48 UTC (rev 12581) +++ trunk/doc/docbook/README.developers 2013-10-05 23:29:44 UTC (rev 12582) @@ -12,7 +12,7 @@ (README.developers) instructions for building the documentation from the DocBook source files in this directory. The documentation that is built includes man pages of the API as well as complete versions of the -documentation in HTML, dvi, PostScript, PDF, and info form. +documentation in info, HTML, and PDF forms. Configuring and Building ======================== @@ -24,12 +24,24 @@ Here is how. Simply add the cmake option -DBUILD_DOC=ON to your normal cmake command-line options for the PLplot build. The resulting cmake step looks for all the tools required for the documentation -build and turns off the documentation build and gives WARNING messages -if any of those required tools are missing. Furthermore, at run-time -xmlto (used below) checks for required backend tools. So cmake -messages with the -DBUILD_DOC=ON option _and_ run time messages from -xmlto should be sufficient for you to figure out what DocBook/XML -related tools you need to install in order to build the documentation. +build and generates a WARNING message and turns off all or some +component of the documentation build if any of those required tools +are missing. Currently, the tools searched for by our build system +are xmlto, dblatex, and xelatex. Furthermore, at run-time xmlto and +dblatex (used below) automatically check for required tools, and +dblatex checks for missing fonts when generating the pdf results. +(Those required fonts are chosen by +doc/docbook/source/dblatex_stylesheet.xsl and are currently FreeSans, +FreeSerif, and FreeMono). + +In sum, cmake WARNING messages with the -DBUILD_DOC=ON option _and_ +run time messages from xmlto and dblatex should be sufficient for you +to figure out what DocBook/XML related tools and fonts you need to +install in order to build the documentation. As far as we know +installation of the xmlto, dblatex, xelatex tools and the FreeSans, +FreeSerif, and FreeMono fonts should be sufficient, but if not, run-time +warnings should be generated. + N.B. As far as we know, the complete set of required tools is only available on Linux so you will need a Linux system to do a documentation build. @@ -60,103 +72,22 @@ db2x_xsltproc limitations. db2x_xsltproc and db2x_texixml are from the docbook2x package. -3. Our HTML and print(dvi, PostScript, and PDF) results are all generated -with xmlto using respectively no special options and the html subcommand, -the experimental --with-dblatex option and dvi subcommand, and -the experiemtnal --with-fop option and the ps and pdf subcommands. +3. Our HTML results are generated with xmlto and configured at run +time with a CSS stylesheet, see doc/docbook/src/stylesheet.css.xsl.in. +The xmlto application is actually a convenience script that uses +XML/XSL to generate the HTML results as opposed to the previous +SGML/DSSSL approach used to create the HTML results for plplot-5.9.9 +and previous. -N.B. for the dvi results to work as of this date (2013-08) it is -necessary to apply the dblatex patch given at -http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720624 +4. Our PDF results are generated with "dblatex --backend=xetex" using +a combination of XML/XSL and xelatex to generate the PDF results (in +contrast to the SGML/DSSL tools used for that job for plplot-5.9.9 and +previous, and the XML/XSL "xmlto --with-fop" method used with +PLplot-5.9.10 to do that job. -The backend tools that the xmlto convenience script selects are -all XML/XSL as opposed to the previous set of SGML/DSSSL backend -tools used to create the HTML and print results. For more information -see "Further notes on the backend tools" below. +5. Generation of dvi and PostScript forms of our documentation is +no longer available. - -Further notes on the backend tools -================================== - -Note from AWI on the project he just completed (as of 2013-08) to use -xmlto (a shell script that gives convenient access to a wide variety -of XML/XSL DocBook backend tools) as the DocBook backend generator for -HTML and print (dvi, PostScript, and PDF) forms of our documentation. -(The man and info forms of our documentation are already prepared -using XML/XSL DocBook backend tools.) - -One immediate advantage of xmlto is that it detects -(at run time) whether all the software components it needs are installed -so this substantantially reduces the testing for DocBook backend components -required of our build system. - -The use of the old/deprecated SGML/DSSSL backend tools for HTML and -print are still available (as of 2013-08) if the developer -specifies the PLplot cmake option -DDOCBOOK_XML_BACKEND=OFF along with --DBUILD_DOC=ON. However, the HTML results from that option are not -very good (the Greek characters in the table giving Roman-Greek -equivalents are gibberish) presumably because bit-rot has set in for -the SGML/DSSSL tools in the decade since there has been any upstream -development for those tools. So at the start of the next release -cycle the plan is to drop use of the SGML/DSSSL backend tools -altogether. - -The only limitation of the current xmlto backend results that I am -aware of is the representation of S̅(f̲r̲e̲q̲) is not done very well in -HTML (an empty string is used rather than S̅(f̲r̲e̲q̲)) or the print -results (S(freq) is used rather S̅(f̲r̲e̲q̲)). Note that overlining and -underlining do not work at all for modern PLplot device drivers such -as cairo and qt so a much higher priority should be given to fixing -those issues rather than fixing the issue of representing overlining -and underlining in the generation of the documentation! Furthermore, -instead of using special tricks for dealing with the representation of -overlining/underlining (as was done for the SGML/DSSSL backend tools), -the correct thing to do in the long term (i.e., after the use of -SGML/DSSSL backend tools is completely removed since SGML is not -compatible with UTF-8) is to make the tool chain used to convert our -DocBook documentation to various formats completely UTF-8 aware so -that, for example, UTF-8 glyphs for underlining overlining as well -as UTF-8 strings such as occur in our unicode examples -23, 24, and 26 could be included directly in the DocBook source of -our documentation. - -As if this date (2013-08) it appears to me the best UTF-8 way forward -for html is the current html method (which should be transparent -to UTF-8 strings although I haven't tested that in detail with -truly exotic UTF-8 strings). And the best UTF-8 way forward for -print results is the experimental --backend=xetex option for the -dblatex command. - -To demonstrate the UTF-8 power of xelatex try the xelatex command on -the example given at http://en.wikipedia.org/wiki/XeTeX. All those -non-Western glyphs _and_ scripts seem to come out fine in the -resulting pdf and conversion to an equivalent PostScript result with -pdf2ps seemed to preserve all those glyph and script results as well. -Furthermore, I recently tried - -dblatex --backend=xetex -o plplotdoc.xetex.pdf --pdf plplotdoc-print.xml - -and the resulting plplotdoc.xetex.pdf document looked good (both Greek -table and function API) with the default style. Although currently -unnecessary from my perspective, it looks like the dblatex -p option -is what you should use to style such results further if anyone feels -the need. (Note that the --backend=xetex dblatex option is not -accessible from the xmlto --with-dblatex command.) - -The only drawback of this xetex approach that I can determine at the -present time is you can only produce PDF with it. PostScript could -then be generated using pdf2ps, but there is absolutely no way to -produce dvi results using xelatex or the --backend=xetex option for -the dblatex command. So if we do start inserting general UTF-8 -strings into our DocBook source (say a table of Math symbols or -comments concerning our multilingual Peace flag example), we would -have to complete drop dvi, but I think that is an acceptable price to -pay for the huge range of glyphs that are available with UTF-8. So I -believe that dropping dvi and moving to the above command to generate -our PDF documentation is something we should consider for the near -future (when the possibility of using of the SGML backend tools is -completely removed from our build system). - Validation ========== @@ -187,12 +118,18 @@ Testing the documentation that has been built. ============================================== -All tests are performed in the doc/dockbook/src subdirectory _of the build -tree_. The given test commands are for the bash shell, and $version is -currently 5.9.0. There are no known DocBook back-end issues revealed by the -following tests. +All tests are performed in the doc/dockbook/src subdirectory _of the +build tree_. The given test commands are for the bash shell, and +$version is currently 5.9.10. For the man pages, look carefully at +the style of the results. For the rest, look carefully at the style +of the api chapter and the style/results near Table-3.4 in the +advanced chapter. In particular look at how the following examples +render: the overline-underline example just prior to Table-3.4, +Table-3.4 of Greek symbols, Table-3.5 of the "Peace" word expressed in +various languages, and the mathematical symbols occurring in the +paragraph just after Table-3.5. -1. man pages. +1. man pages. (for MANPAGE in *.3plplot; do nroff -man $MANPAGE ; done) |less @@ -202,25 +139,108 @@ 3. web pages. -Browse with your favorite browser the index.html file within the current src -directory. konqueror and mozilla/firefox/iceweasel give good looking -results including the Greek letters in Table 3-4. +Browse with your favorite browser the index.html file that is generated +by xmlto. -4. dvi file +4. pdf file -xdvi plplot-$version.dvi +Browse with your favorite browser the plplot-$version.pdf file that +is generated by dblatex. -5. PostScript file +UTF-8 limitations of the current set of backend tools +===================================================== -gv plplot-$version.ps.gz +The above set of DocBook backend tools has been chosen with the goal +of allowing essentially arbitrary UTF-8 strings into our DocBook +source. And the advanced.xml part of our DocBook source constitutes a +simple test of how close we have come to that goal by including the +"Peace" word in all the human languages expressed in example 24 and by +also including some UTF-8 forms of math symbols. Here are the current +results for how well those UTF-8 strings render for our various +backends. -6. pdf file +Man pages. -xpdf plplot-$version.pdf +These results are not affected since the man pages ignore the advanced +chapter, and the api.xml file currently contains only the ascii +subset of UTF-8. -Installing the generated documentation (and the rest of the -generated website) at plplot.sf.net -=========================================================== +Info files. +These results are reasonably good. All math glyphs and all but the +glyphs occurring in the Korean, Hindi, and Mandarin "Peace" words are +rendered correctly. That's exactly the same set of missing glyphs +that occurs when I use "less" on advanced.xml so it is possible some +configuration adjustment for the non-GUI component of my system will +fix the missing glyphs that occur both for the info form of our +documentation and when using "less". + +HTML results. + +These are outstanding results with no issues that we are aware of. +All math glyphs and all the glyphs occurring in the set of "Peace" +words render without issues including the CTL languages like Hebrew, +Arabic, and Hindi. + +PDF results. + +These results are reasonably good. All math glyphs and all but the +glyphs occurring in the Korean and Mandarin "Peace" words are present. +I attribute the missing glyph issues to missing Korean and Mandarin +glyphs in the chosen FreeSans, FreeSerif, and FreeMono fonts (more +about that choice below). The order of the glyphs in the Hindi Peace +word is not correct (last two glyphs switched) which is a common +complex text layout (CTL) issue when using unsophisticated software to +render Hindi. However, the the Peace word is laid out in the correct +(right-to-left) order for Arabic and Hebrew so there is some CTL +sophistication in the xelatex layout engine, and probably hope that +further layout issues such as the one for Hindi will be fixed. + +More on the reason for the missing PDF glyphs. + +It was a huge step forward in the tex world for the combination of +xelatex and the fontspec tex package to make a very large number of +UTF-8 glyphs potentially available in pdf results. So I think the +above method of using dblatex with the xetex backend (which uses +xelatex and fontspec internally) is the best we can do to generate the +pdf form of our documentation as free as possible from unicode issues. +For example, the situation is much improved over the previous xmlto +method which severely limited the glyphs in the PDF form of our +results. + +However, the fontspec package still has a fundamental limitation which +is you must use a specific rather than generic font for the sans, +serif, and mono cases. Specific fonts are never a good way to go for +documents containing different languages (such as the table of "Peace" +words I recently introduced into advanced.xml) since no single font +contains all needed glyphs for a multilanguage document. The most +comprehensive fonts I am aware of in this regard are FreeSans, +FreeSerif, and FreeMono fonts so those are what I have configured (in +doc/docbook/src/dblatex_stylesheet.xsl) as the specific fonts to use +for the PDF form of our documentation. Of course, these specific +fonts are not completely comprehensive so the (inevitable) result is +missing glyphs in the PDF results for the Korean and Mandarin cases. + +The proper way to solve this issue (which would bring tex completely +into the modern unicode world) would be to modify fontspec so that +certain given font names are considered generic, (e.g., the +"sans-serif", "serif", and "mono-space" font names could be adopted +for this purpose to follow what is done in the SVG world). For those +generic font names, the fontspec package should simply hand off font +selection to fontconfig which does a very nice job of automatically +selecting the ideal sans, serif, or mono system font to render a +particular UTF-8 glyph. I have asked the fontspec maintainer about +this potential feature two days before the current writing, but so far +he has not replied. Therefore, it appears at this time there will be +no quick fixes to fontspec with regard to automatic selection of fonts +for the generic case, and we will be stuck for the foreseeable future +with the specific font approach. Until the lack of generic font +support in xelatex/fontspec is addressed there will inevitably be +missing glyphs in our pdf results. + + +Installing the generated documentation (and the rest of the generated website) at plplot.sf.net +=============================================================================================== + Follow the directions in README.Release_Manager_Cookbook. That file is located in the top-level source tree. This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ai...@us...> - 2013-10-06 18:58:31
|
Revision: 12584 http://sourceforge.net/p/plplot/code/12584 Author: airwin Date: 2013-10-06 18:58:29 +0000 (Sun, 06 Oct 2013) Log Message: ----------- Add a discussion concerning the compromise between comprehensiveness and quality forced on users by the specific font approach adopted by xelatex/fontspec (the tools we indirectly use to build the pdf form of our UTF-8 documentation.) Modified Paths: -------------- trunk/doc/docbook/README.developers Modified: trunk/doc/docbook/README.developers =================================================================== --- trunk/doc/docbook/README.developers 2013-10-06 18:36:27 UTC (rev 12583) +++ trunk/doc/docbook/README.developers 2013-10-06 18:58:29 UTC (rev 12584) @@ -212,33 +212,38 @@ is you must use a specific rather than generic font for the sans, serif, and mono cases. Specific fonts are never a good way to go for documents containing different languages (such as the table of "Peace" -words I recently introduced into advanced.xml) since no single font -contains all needed glyphs for a multilanguage document. The most -comprehensive fonts I am aware of in this regard are FreeSans, -FreeSerif, and FreeMono fonts so those are what I have configured (in -doc/docbook/src/dblatex_stylesheet.xsl) as the specific fonts to use -for the PDF form of our documentation. Of course, these specific -fonts are not completely comprehensive so the (inevitable) result is -missing glyphs in the PDF results for the Korean and Mandarin cases. +words I recently introduced into advanced.xml) since since the user is +forced to compromise between font quality and comprehensiveness. For +example, I have tried using the unifont font (which gives complete +coverage of glyphs for the basic multilingual plane), and the +resulting pdf form of our documentation has no missing glyphs. +However, that font is of extremely poor quality (scaled, +low-resolution bitmapped, monospaced fonts) which makes our +documentation look ugly so I am not going to use it. Instead, I have +chosen (via doc/docbook/src/dblatex_stylesheet.xsl) to use FreeSans, +FreeSerif, and FreeMono fonts which have reasonable quality but which +have some missing glyphs (notably CJK glyphs that leave our Korean and +Mandarin "peace" words empty in the documentation). The proper way to solve this issue (which would bring tex completely into the modern unicode world) would be to modify fontspec so that certain given font names are considered generic, (e.g., the "sans-serif", "serif", and "mono-space" font names could be adopted for this purpose to follow what is done in the SVG world). For those -generic font names, the fontspec package should simply hand off font -selection to fontconfig which does a very nice job of automatically -selecting the ideal sans, serif, or mono system font to render a -particular UTF-8 glyph. I have asked the fontspec maintainer about -this potential feature two days before the current writing, but so far -he has not replied. Therefore, it appears at this time there will be -no quick fixes to fontspec with regard to automatic selection of fonts -for the generic case, and we will be stuck for the foreseeable future -with the specific font approach. Until the lack of generic font -support in xelatex/fontspec is addressed there will inevitably be -missing glyphs in our pdf results. +generic font names, the idea is the fontspec package would simply hand +off font selection to fontconfig which does a very nice job of +automatically selecting the ideal sans, serif, or mono system font to +provide a particular UTF-8 glyph. I have asked the fontspec +maintainer about this potential feature several days before the +current writing, but so far he has not replied. Therefore, it appears +at this time there will be no quick fixes to xelatex/fontspec with +regard to automatic selection of fonts for the generic case, and we +will be stuck for the foreseeable future with the specific font +approach. That approach forces a compromise between complete glyph +coverage and reasonable quality. Thus, as a result of avoiding truly +ugly fonts in our generated pdf documentation there are missing CJK +glyphs in the results. - Installing the generated documentation (and the rest of the generated website) at plplot.sf.net =============================================================================================== This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |
From: <ai...@us...> - 2014-01-26 02:50:38
|
Revision: 12959 http://sourceforge.net/p/plplot/code/12959 Author: airwin Date: 2014-01-26 02:50:33 +0000 (Sun, 26 Jan 2014) Log Message: ----------- Add information concerning (good) rendering of UTF-8 symbols in api.xml by the "man" command. Modified Paths: -------------- trunk/doc/docbook/README.developers Modified: trunk/doc/docbook/README.developers =================================================================== --- trunk/doc/docbook/README.developers 2014-01-25 19:47:30 UTC (rev 12958) +++ trunk/doc/docbook/README.developers 2014-01-26 02:50:33 UTC (rev 12959) @@ -133,6 +133,14 @@ (for MANPAGE in *.3plplot; do nroff -man $MANPAGE ; done) |less +Two of our man pages (plot3dcl.3plplot and plsurf3dl.3plplot) +currently contain utf8 symbols (for the math symbols ≤ and ≥). Those +symbols do not render correctly using nroff -man (or any other +recommended nroff options such as -Tutf8). However, they display +without issues if viewed with man (by copying the files to a temporary +directory man/man3 and viewing them with, e.g., "man -M./man +plot3dcl"). + 2. info pages. info --file plplotdoc.info @@ -162,8 +170,13 @@ Man pages. These results are not affected since the man pages ignore the advanced -chapter, and the api.xml file currently contains only the ascii -subset of UTF-8. +chapter, but (see discussion above) the api.xml file currently +contains two functions whose documentation uses UTF-8 math symbols, +and for those man pages the man command renders those symbols without +issues. I assume what is going on here is the UTF-8 math symbols +are just being cleanly passed through to the man viewer ("less" in +this case) so with some exceptions (see comments on less below) good +rendering of arbitrary UTF-8 symbols will occur. Info files. @@ -191,7 +204,7 @@ about that choice below). The order of the glyphs in the Hindi Peace word is not correct (last two glyphs switched) which is a common complex text layout (CTL) issue when using unsophisticated software to -render Hindi. However, the the Peace word is laid out in the correct +render Hindi. However, the Peace word is laid out in the correct (right-to-left) order for Arabic and Hebrew so there is some CTL sophistication in the xelatex layout engine, and probably hope that further layout issues such as the one for Hindi will be fixed. @@ -212,7 +225,7 @@ is you must use a specific rather than generic font for the sans, serif, and mono cases. Specific fonts are never a good way to go for documents containing different languages (such as the table of "Peace" -words I recently introduced into advanced.xml) since since the user is +words I recently introduced into advanced.xml) since the user is forced to compromise between font quality and comprehensiveness. For example, I have tried using the unifont font (which gives complete coverage of glyphs for the basic multilingual plane), and the This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |