Thanks to all for the kind words.
When I began working on this, my objective was to find a replacement set
of tools and a procedure for the broken and unsupported Publican package
that we have been using until now to build the ooRexx documentation. I
was hoping to be able to create books that had the same look as those we
have been generating with Publican without making massive changes to the
source files. I believe I have accomplished that to a large degree but
there are, unfortunately, some changes to the source files that are
necessary. This is due to several factors - some caused by the way
Publican does things "under the covers" and some due to errors we have
made that Publican does not catch. Before I automate the process to
build a document, I'd like some feedback on how to handle those changes.
For each change that is needed or is at least desirable, I can have the
process dynamically make the change to the working copy of the files
before starting the document build. Or I can open a series of document
bug reports with patch files to fix them and we can wait until they are
committed to the trunk and have the document build process assume they
are present. Some of the changes involve only a few files while others
will be small changes to almost every file :-(. I guess I will start
documenting the process and the issues and ask for direction on each one
as I do. Note that having the process dynamically make the source
changes will allow us to more quickly be able to build and, hopefully,
release 5.0.0. Committing the source changes, however, is the right long
term solution but may delay getting a releasable doc package for 5.0.0.
Any thoughts are greatly appreciated.
Gil
On 12/16/2019 4:01 PM, Jon Wolfers wrote:
I would like to add my voice to the chorus of approval. Great work Gil!
Jon
On Mon, 16 Dec 2019 at 19:13, Rony G. Flatscher
<[email protected] <mailto:[email protected]>> wrote:
Gil:
that is really a *great* achievement, thank you very much for all
of your efforts! This is really great for the ooRexx project!
Whenever you want "nit-picking" feedback, please let us know, the
overall documentation is looking very professional and attractive
already!
Also, whenever you are ready to share how you did this and what we
need to do to do that also, I will try to create the documenation
as well. This will allow us to try to help with the documentation
as we would become able to test whether our changes would lead to
successful creation and attractive documentation, relieving Rick
and Erich in that corner a bit!
Best regards,
---rony
On 16.12.2019 16:40, Gil Barmwater wrote:
As a result of Jon's request, I have now done the RxMath PDF as
well. Doing another document helped me formalize the process so
that I can automate it and it identified another small issue
which I thought had been corrected. You can download the PDF here
<https://www.dropbox.com/s/82yxqei5ucvub9e/rxmath.pdf?dl=0> for
comparison to the rxmath.pdf that is in the docs folder of your
5.0.0 ooRexx installation or the Files section on SourceForge.
The differences I found are 1) the Copyright dates on the second
page now show -2019, and 2) the flow of the text in some sections
is slightly different due to extra blank lines in the code
examples. This issue was identified and fixed by Erich with a
preprocess Rexx program when building our docs using Publican so
it can be adapted to my process if I am unable to find the cause
and change it. His program also needed to fix blank lines in the
Index area but that looked OK to me in my build. Comments welcome.
Gil
_______________________________________________
Oorexx-devel mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
