[Oorexx-devel] Documentation: ad "rr" and extracting svg from xhtml files with (docs\trunktools\RailRoadDiagrams\extract_svg_from_rr_xhtml.rex)

[Rony G. Flatscher]

The program "docs\trunktools\RailRoadDiagrams\extract_svg_from_rr_xhtml.rex" got changed in the past 
weeks a little bit:


 - 20240316: changed the svg name needle from 'Background: some of the xhtml files had Unix LF, some Windows CR-LF. Extracting the svg data causes 
svn problems at commit time, if the line-ends are mixed up (hence making sure that the extracted svg 
data ends with CR-LF).


Enhancing the program to allow supplying a directory (no argument defaults to '.', current 
directory) which will cause it and all its subdirectories to be searched for xhtml files and have 
all svg files extracted and saved in the directory where the xhtml file resides.


---

The xhtml files get created with the "Railroad-Diagram-Generator" which moved to: 
 (one can download a Java war-file and run it locally via a browser)". 
Just copy the content of the respective ooRexx ".ebnf" text file into the "Edit Grammar" tab, remove 
the check mark from "Inline literals" in the "Options" tab and then go to "View Diagram" to generate 
the syntax diagrams, then save the document as a single xhtml (attention: use the base name of the 
ebnf file for "exporting"/storing).


---rony

P.S.: For the rexxref book I recreated all svg-syntax diagrams from the xhtml 
files.

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation added to rexxref (Re: Ad debugging multithreaded programs, updated RFE # 825

[Rony G. Flatscher]

Writing up the documentation for the new TraceObject class and the new subchapter for debugging 
multithreaded programs has turned out to be quite a hefty piece of work despite having already the 
raw text available (and adhering to it).


In the end, the rexxref sections that play a role in tracing multithreaded programs are now 
interlinked (like REPLY, GUARD keyword statements) such that one should be able to get to the 
referenced parts just by clicking on the respective word.


Jenkins should produce a pdf-version in the next hours such that you can download rexxref.pdf from 
. Once you can get at the new 
version, here are the new (sub) chapters:


 * 5.4.25. *NEW* TraceObject Class
 * 15.4. *NEW* Debugging Multithreaded Programs

Not being a native English speaker I would appreciate any corrections and suggestions to improve the 
text.


Please also point out any errors or omissions that you find.

---rony
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build process amended

[Rony G. Flatscher]

On 01.01.2024 12:50, ooRexx wrote:

Forst of all I want to wish everybody a (late) happy new year and a good 
continuation of 2024!

Me too to everyone!
With the kind help of Gil the documentation build service on Jenkins have been amended to reflect 
the correct date & revision information for any book amended. If you want to know how it looks 
have a look at oorexxbuild.pdf, where I have started to document the current build system.

+1
I did not trigger a rebuild on any of the other books, so the change will only be reflected 
whenever a change is made to a specific book. Or should I trigger a rebuild of the complete 
documentation today, 1.1.2024? It's a nice date to remember :-)


Yes, this would be great as it would improve the documentation by correcting that little but 
important information!


---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation build process amended

[ooRexx]

Forst of all I want to wish everybody a (late) happy new year and a good 
continuation of 2024!

With the kind help of Gil the documentation build service on Jenkins have been 
amended to reflect the correct date & revision information for any book 
amended. If you want to know how it looks have a look at oorexxbuild.pdf, where 
I have started to document the current build system.

I did not trigger a rebuild on any of the other books, so the change will only 
be reflected whenever a change is made to a specific book. Or should I trigger 
a rebuild of the complete documentation today, 1.1.2024? It's a nice date to 
remember :-)

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[Erich Steinböck]

Fixed with revision [r12464]

On Mon, Jul 4, 2022 at 9:15 AM rvm--- via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Very minor point:
> orxncurses.pdf preface refers to the Sockets classes.
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation

[rvm--- via Oorexx-devel]

Very minor point:
orxncurses.pdf preface refers to the Sockets classes.


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: remove author list from front page ?

[P. O. Jonsson]

+1

Von meinem iPhone gesendet

> Am 03.07.2022 um 15:04 schrieb Rony G. Flatscher :
> 
> Currently the ooRexx documentation has an author list at the front page and 
> the same author list on the second page. How about removing the list of 
> authors from the front page as that does not really look too professional 
> (but keep the author list on the second page)?
> 
> ---rony
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation: remove author list from front page ?

[Rony G. Flatscher]

Currently the ooRexx documentation has an author list at the front page and the same author list on 
the second page. How about removing the list of authors from the front page as that does not really 
look too professional (but keep the author list on the second page)?


---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[P.O. Jonsson]

> Am 01.07.2022 um 14:11 schrieb Rick McGuire :
> 
> 
> Except this the files section, which is not under version control. If it's 
> deleted, it's gone. I think we need to keep a copy around, but in place where 
> it's obvious it's not the most current. 

I can move it to /docs/trunk/publican_obsolete so we do not loose it (I have 
local copies as well)___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[Rick McGuire]

On Fri, Jul 1, 2022 at 8:01 AM Rony G. Flatscher 
wrote:

> Hi P.O.,
> On 01.07.2022 11:53, P.O. Jonsson wrote:
>
>
> Am 28.06.2022 um 11:19 schrieb Rony G. Flatscher  >:
>
> Here the direct link:
> 
> 
>
>
>
> After initial tests I have moved to
>
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/
>
> +1
>
>
> And
>
> https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0html/
>
> +1
>
> The next time anyone work on a book it will be reflected here,
>
> I intend to create a „docbuildtools“ directory here as well and add the
> documents from the /docs/trunk/tools brach of the source code tree. Any
> objections?
>
> +1
>
> On the same subject: in the „Files“ part of the source forge site there is
> the subdir windows-build-tools
>  which
> does NOT contain build tools but actually the obsolete „Publican“
> documentation build tools. Can I move this content to an „obsolete“ section
> of the source tree? I hesitate to delete it. Feedback requested.
>
> As it is not relevant anymore, why not delete it. SourceForge as a version
> control system would keep it around such that one could "undelete" (revert)
> it later should interest or need arise.
>

Except this the files section, which is not under version control. If it's
deleted, it's gone. I think we need to keep a copy around, but in place
where it's obvious it's not the most current.

Rick

> ---rony
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[Rony G. Flatscher]

Hi P.O.,

On 01.07.2022 11:53, P.O. Jonsson wrote:



Am 28.06.2022 um 11:19 schrieb Rony G. Flatscher :

Here the direct 
link:





After initial tests I have moved to

https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/


+1



And

https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0html/


+1


The next time anyone work on a book it will be reflected here,

I intend to create a „docbuildtools“ directory here as well and add the documents from the 
/docs/trunk/tools brach of the source code tree. Any objections?


+1

On the same subject: in the „Files“ part of the source forge site there is the subdir 
windows-build-tools  which 
does NOT contain build tools but actually the obsolete „Publican“ documentation build tools. Can I 
move this content to an „obsolete“ section of the source tree? I hesitate to delete it. Feedback 
requested.


As it is not relevant anymore, why not delete it. SourceForge as a version control system would keep 
it around such that one could "undelete" (revert) it later should interest or need arise.


---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[P.O. Jonsson]

> Am 28.06.2022 um 11:19 schrieb Rony G. Flatscher :
> 
> Here the direct link: 
>  
> 

After initial tests I have moved to 

https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0beta/ 


And

https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0html/ 


The next time anyone work on a book it will be reflected here,

I intend to create a „docbuildtools“ directory here as well and add the 
documents from the /docs/trunk/tools brach of the source code tree. Any 
objections?

On the same subject: in the „Files“ part of the source forge site there is the 
subdir windows-build-tools 
 which does 
NOT contain build tools but actually the obsolete „Publican“ documentation 
build tools. Can I move this content to an „obsolete“ section of the source 
tree? I hesitate to delete it. Feedback requested.___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[P. O. Jonsson]

Hi Gil,

No complications at all the Win builds on Jenkins all use the include switch 
that Rick describes. The problem is/was that the doc build job have been 
idle/shut off due to the fact that it build all docs every time which was not 
accepted. Also we never uploaded anything for the same reason, the Winbuilds 
all used local copies. All that can be simplified now.

Von meinem iPhone gesendet

> Am 28.06.2022 um 19:57 schrieb Gilbert Barmwater :
> 
> 
> Thanks P.O., they look great!  Now one more issue to address.😉 As you know, 
> the Windows build includes the documentation and the user has the option of 
> installing it as part of installing ooRexx.  Currently, the PDFs in the 
> Windows builds are NOT the ones you generate.  I have never done an NSIS 
> build so I'm not sure how it finds the folder with the PDFs to include but it 
> should point to the ones you build.  Of course this also implies that the 
> documents need to be built BEFORE the Windows build is executed.  Sorry for 
> the extra complications🙁.
> 
> Gil
> 
> On 6/27/2022 1:44 PM, P.O. Jonsson wrote:
>> I have written a rexx script that taps into the existing build process and 
>> build only those documents that have been changed. I have done it on macOS 
>> but it should work also on Windows. I had to set today as a starting point 
>> (the documents will get todays date) but they will show the correct revision 
>> number (when they were last changed). I hope this is fine.
>> 
>> For the upload I have added a folder 5.0.0test for comparing to existing 
>> documents in 5.0.0beta. I can merge them later.
>> 
>> Please have a look and see if you can spot any visual differences, I have 
>> checked that the correct fonts are embedded but I have not checked if the 
>> visual appearance is different on Windows compared to macOS. If accepted I 
>> will set up a macOS VM for this task and retire the current doc-build on 
>> Windows.
>> 
>> For completeness I included also the documentation in html form, This might 
>> be possible to upload maybe to https://www.oorexx.org/ once we have an 
>> official version.
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[Gilbert Barmwater]

Thanks Rick!  I knew there was a way to tell the installer build where 
to get the PDFs but couldn't remember how.


Gil

On 6/28/2022 2:58 PM, Rick McGuire wrote:



On Tue, Jun 28, 2022 at 1:58 PM Gilbert Barmwater 
 wrote:


Thanks P.O., they look great!  Now one more issue to address.😉 As
you know, the Windows build includes the documentation and the
user has the option of installing it as part of installing
ooRexx.  Currently, the PDFs in the Windows builds are NOT the
ones you generate.  I have never done an NSIS build so I'm not
sure how it finds the folder with the PDFs to include but it
should point to the ones you build.  Of course this also implies
that the documents need to be built BEFORE the Windows build is
executed.  Sorry for the extra complications🙁.

There's a variable you can set on the initial CMake command for the 
build that identifies the location of the docs. It is necessary to 
download the files before doing the installer portion of the build.


Rick

Gil

On 6/27/2022 1:44 PM, P.O. Jonsson wrote:

I have written a rexx script that taps into the existing build
process and build only those documents that have been changed. I
have done it on macOS but it should work also on Windows. I had
to set today as a starting point (the documents will get todays
date) but they will show the correct revision number (when they
were last changed). I hope this is fine.

For the upload I have added a folder 5.0.0test for comparing to
existing documents in 5.0.0beta. I can merge them later.

Please have a look and see if you can spot any visual
differences, I have checked that the correct fonts are embedded
but I have not checked if the visual appearance is different on
Windows compared to macOS. If accepted I will set up a macOS VM
for this task and retire the current doc-build on Windows.

For completeness I included also the documentation in html form,
This might be possible to upload maybe to
https://www.oorexx.org/ once we have an official version.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se






___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[Rick McGuire]

On Tue, Jun 28, 2022 at 1:58 PM Gilbert Barmwater 
wrote:

> Thanks P.O., they look great!  Now one more issue to address.😉 As you
> know, the Windows build includes the documentation and the user has the
> option of installing it as part of installing ooRexx.  Currently, the PDFs
> in the Windows builds are NOT the ones you generate.  I have never done an
> NSIS build so I'm not sure how it finds the folder with the PDFs to include
> but it should point to the ones you build.  Of course this also implies
> that the documents need to be built BEFORE the Windows build is executed.
> Sorry for the extra complications🙁.
>
There's a variable you can set on the initial CMake command for the build
that identifies the location of the docs. It is necessary to download the
files before doing the installer portion of the build.

Rick


> Gil
> On 6/27/2022 1:44 PM, P.O. Jonsson wrote:
>
> I have written a rexx script that taps into the existing build process and
> build only those documents that have been changed. I have done it on macOS
> but it should work also on Windows. I had to set today as a starting point
> (the documents will get todays date) but they will show the correct
> revision number (when they were last changed). I hope this is fine.
>
> For the upload I have added a folder 5.0.0test for comparing to existing
> documents in 5.0.0beta. I can merge them later.
>
> Please have a look and see if you can spot any visual differences, I have
> checked that the correct fonts are embedded but I have not checked if the
> visual appearance is different on Windows compared to macOS. If accepted I
> will set up a macOS VM for this task and retire the current doc-build on
> Windows.
>
> For completeness I included also the documentation in html form, This
> might be possible to upload maybe to https://www.oorexx.org/ once we have
> an official version.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
>
>
> ___
> Oorexx-devel mailing 
> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[Gilbert Barmwater]

Thanks P.O., they look great!  Now one more issue to address.😉 As you 
know, the Windows build includes the documentation and the user has the 
option of installing it as part of installing ooRexx.  Currently, the 
PDFs in the Windows builds are NOT the ones you generate.  I have never 
done an NSIS build so I'm not sure how it finds the folder with the PDFs 
to include but it should point to the ones you build.  Of course this 
also implies that the documents need to be built BEFORE the Windows 
build is executed.  Sorry for the extra complications🙁.


Gil

On 6/27/2022 1:44 PM, P.O. Jonsson wrote:
I have written a rexx script that taps into the existing build process 
and build only those documents that have been changed. I have done it 
on macOS but it should work also on Windows. I had to set today as a 
starting point (the documents will get todays date) but they will show 
the correct revision number (when they were last changed). I hope this 
is fine.


For the upload I have added a folder 5.0.0test for comparing to 
existing documents in 5.0.0beta. I can merge them later.


Please have a look and see if you can spot any visual differences, I 
have checked that the correct fonts are embedded but I have not 
checked if the visual appearance is different on Windows compared to 
macOS. If accepted I will set up a macOS VM for this task and retire 
the current doc-build on Windows.


For completeness I included also the documentation in html form, This 
might be possible to upload maybe to https://www.oorexx.org/ once we 
have an official version.


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se






___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation build

[Rony G. Flatscher]

Dear P.O.,

On 27.06.2022 19:44, P.O. Jonsson wrote:
I have written a rexx script that taps into the existing build process and build only those 
documents that have been changed. I have done it on macOS but it should work also on Windows. I 
had to set today as a starting point (the documents will get todays date) but they will show the 
correct revision number (when they were last changed). I hope this is fine.

This is *super*!
For the upload I have added a folder 5.0.0test for comparing to existing documents in 5.0.0beta. I 
can merge them later.


Here the direct link: 


Please have a look and see if you can spot any visual differences, I have checked that the correct 
fonts are embedded but I have not checked if the visual appearance is different on Windows 
compared to macOS. If accepted I will set up a macOS VM for this task and retire the current 
doc-build on Windows.


This has been long overdue, thank you for your efforts! Finally the downloadable documentation 
matches trunk (like the downloadable versions of ooRexx 5.0).


For completeness I included also the documentation in html form, This might be possible to upload 
maybe to https://www.oorexx.org/ once we have an official version.


These look *great* too!

Here the direct link: 


---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation build

[P.O. Jonsson]

I have written a rexx script that taps into the existing build process and 
build only those documents that have been changed. I have done it on macOS but 
it should work also on Windows. I had to set today as a starting point (the 
documents will get todays date) but they will show the correct revision number 
(when they were last changed). I hope this is fine.

For the upload I have added a folder 5.0.0test for comparing to existing 
documents in 5.0.0beta. I can merge them later.

Please have a look and see if you can spot any visual differences, I have 
checked that the correct fonts are embedded but I have not checked if the 
visual appearance is different on Windows compared to macOS. If accepted I will 
set up a macOS VM for this task and retire the current doc-build on Windows.

For completeness I included also the documentation in html form, This might be 
possible to upload maybe to https://www.oorexx.org/  
once we have an official version.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Gil Barmwater]

In spite of the lack of posts on this subject recently, P.O., Rony and I 
have been working diligently to make this work (building the docs w/o 
requiring access to the 'net). I can now report that we have finally 
succeeded! And the results are nothing short of spectacular! In addition 
to using the DTD and style sheet files that have been installed on the 
local system, we have moved to the most recent version of the style 
sheets - 1.79.2 - which is now located on GitHub (DocBook has moved 
their repository from SourceForge). As soon as I update the package 
documentation, I will commit the changes to SVN.


So how good is the new version of the package? To quote P.O. on his 
results on Jenkins: "First version used one hour for the PDF generation 
and 1.5 hours for the HTML. Already this was better than Publican, and 
MUCH more reliable!


Today PDF generation take 10 minutes (!) and HTML 27 minutes, a complete 
build, including also the �Buildmachine� in less than 40 minutes."


P.O. and Rony have also been working on adapting the package for use on 
the Mac! I will let them describe where that effort stands but it is 
interesting to note that some of the tools needed by the package come 
already installed on the Mac and some flavors of *ix. So it is not 
impossible to believe that we could eventually produce our books on most 
any platform!


Gil B.

On 4/27/2020 12:48 PM, Gil Barmwater wrote:
I, too, have been researching how to do a "local" build of the 
documentation, i.e. not requiring Internet access during the process. 
I believe I have determined what is required and am in the process of 
developing modifications to the package which I will then test. I will 
post again with the results.


Gil

On 4/27/2020 10:00 AM, Rony G. Flatscher wrote:

On 27.04.2020 15:49, P.O. Jonsson wrote:
Thanks Rony for the information, I have been to most of these places 
already :-( but indeed you are right, I am entirely in the dark 
since I do not really understand the logics behind these things.


That said - I will give it a few more tries, but you raise a 
question that should maybe be explored: How much work would it be to 
remap the build process to Linux? On Jenkins server (running Ubuntu 
18.04) there is plenty of processing power available, also when 
running Jenkins server.
The step from xml to fo with xsltproc could work out of the box (just 
checked on my Ubuntu machine,
it has docbook 4.5 support in /etc/xml and the files in 
/usr/share/xml/docbook). The step from fo to
pdf needs Java and Gil's findings could be used to get it running on 
Ubuntu as well.



Did you compare the output quality on your build with Cygwin?

Yes, skimmed through the pdfs and they look as before.
� I remember that for the Publican build the quality of the output 
was inferior to builds on Windows
This has been strange, probably (pure speculation) the quality of the 
output was inferior because

the quality of the bitmaps got tampered with.

---

Will try out the xml->fo step on Ubuntu and report back ASAP.

---

Just a word ad Gil's incredible effort to get that going on Windows: 
just witnessing how difficult
it has been (not yet solved) to get it up and running on Windows and 
still getting locally available
dtd/xsl to be honored, it is just incredible how much effort and 
patience Gil must have thrown at
this beast! Allowing creating the docs in the end after a frustratign 
period where this ability was
not there anymore or at least waning due to outdated tools that got 
more and more problems on Windows!


Even if the documentation could be created on Linux it still would be 
very important to get the
Windows build take locally available dtd/xsl files to speed it up as 
not everybody has Linux available!


---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel



--
Gil Barmwater



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Gil Barmwater]

I, too, have been researching how to do a "local" build of the 
documentation, i.e. not requiring Internet access during the process. I 
believe I have determined what is required and am in the process of 
developing modifications to the package which I will then test. I will 
post again with the results.


Gil

On 4/27/2020 10:00 AM, Rony G. Flatscher wrote:

On 27.04.2020 15:49, P.O. Jonsson wrote:

Thanks Rony for the information, I have been to most of these places already 
:-( but indeed you are right, I am entirely in the dark since I do not really 
understand the logics behind these things.

That said - I will give it a few more tries, but you raise a question that 
should maybe be explored: How much work would it be to remap the build process 
to Linux? On Jenkins server (running Ubuntu 18.04) there is plenty of 
processing power available, also when running Jenkins server.

The step from xml to fo with xsltproc could work out of the box (just checked 
on my Ubuntu machine,
it has docbook 4.5 support in /etc/xml and the files in 
/usr/share/xml/docbook). The step from fo to
pdf needs Java and Gil's findings could be used to get it running on Ubuntu as 
well.


Did you compare the output quality on your build with Cygwin?

Yes, skimmed through the pdfs and they look as before.

  I remember that for the Publican build the quality of the output was inferior 
to builds on Windows

This has been strange, probably (pure speculation) the quality of the output 
was inferior because
the quality of the bitmaps got tampered with.

---

Will try out the xml->fo step on Ubuntu and report back ASAP.

---

Just a word ad Gil's incredible effort to get that going on Windows: just 
witnessing how difficult
it has been (not yet solved) to get it up and running on Windows and still 
getting locally available
dtd/xsl to be honored, it is just incredible how much effort and patience Gil 
must have thrown at
this beast! Allowing creating the docs in the end after a frustratign period 
where this ability was
not there anymore or at least waning due to outdated tools that got more and 
more problems on Windows!

Even if the documentation could be created on Linux it still would be very 
important to get the
Windows build take locally available dtd/xsl files to speed it up as not 
everybody has Linux available!

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
Gil Barmwater



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Rony G. Flatscher]

On 27.04.2020 15:49, P.O. Jonsson wrote:
> Thanks Rony for the information, I have been to most of these places already 
> :-( but indeed you are right, I am entirely in the dark since I do not really 
> understand the logics behind these things.
>
> That said - I will give it a few more tries, but you raise a question that 
> should maybe be explored: How much work would it be to remap the build 
> process to Linux? On Jenkins server (running Ubuntu 18.04) there is plenty of 
> processing power available, also when running Jenkins server.

The step from xml to fo with xsltproc could work out of the box (just checked 
on my Ubuntu machine,
it has docbook 4.5 support in /etc/xml and the files in 
/usr/share/xml/docbook). The step from fo to
pdf needs Java and Gil's findings could be used to get it running on Ubuntu as 
well.

> Did you compare the output quality on your build with Cygwin?
Yes, skimmed through the pdfs and they look as before.
>  I remember that for the Publican build the quality of the output was 
> inferior to builds on Windows

This has been strange, probably (pure speculation) the quality of the output 
was inferior because
the quality of the bitmaps got tampered with.

---

Will try out the xml->fo step on Ubuntu and report back ASAP.

---

Just a word ad Gil's incredible effort to get that going on Windows: just 
witnessing how difficult
it has been (not yet solved) to get it up and running on Windows and still 
getting locally available
dtd/xsl to be honored, it is just incredible how much effort and patience Gil 
must have thrown at
this beast! Allowing creating the docs in the end after a frustratign period 
where this ability was
not there anymore or at least waning due to outdated tools that got more and 
more problems on Windows!

Even if the documentation could be created on Linux it still would be very 
important to get the
Windows build take locally available dtd/xsl files to speed it up as not 
everybody has Linux available!

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[P.O. Jonsson]

Thanks Rony for the information, I have been to most of these places already 
:-( but indeed you are right, I am entirely in the dark since I do not really 
understand the logics behind these things.

That said - I will give it a few more tries, but you raise a question that 
should maybe be explored: How much work would it be to remap the build process 
to Linux? On Jenkins server (running Ubuntu 18.04) there is plenty of 
processing power available, also when running Jenkins server.

Did you compare the output quality on your build with Cygwin? I remember that 
for the Publican build the quality of the output was inferior to builds on 
Windows



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Rony G. Flatscher]

On 26.04.2020 17:56, P.O. Jonsson wrote:
> Phew! I have been trying to replicate your steps in vain for the past two 
> days, I did not want to
> bother you with my failures. I also found out that making to many failing 
> attempts I „broke“ JAVA
> so everything after these failures the error messages were completely 
> unpredictable.

Sorry for that!

> On Jenkins everything run smooth so it is only when you mistreat xsltproc 
> that things start go bad.
>
> This is what I found out so far:
>
> Adding the option *—catalogs* (minus-minus-catalogs, the spell checker messes 
> with my text), the
> DTD should be taken from what SGML_CATALOG_FILES points to. I have tried a 
> number of things but
> nothing really worked.
>
> All these did NOT work (and some others also not):
>
> set 
> SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/docbook.dtd/"
> set 
> SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/docbookx.dtd/"
> set 
> SGML_CATALOG_FILES="C:\Users\po\workspace\ooRexx-docs-build_V2\docbook-xml-4.5\docbookx.dtd"
> set 
> SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/"
> set 
> SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/„
>
> What I did notice is that the zipped archive you pointed to does not contain 
> a file *docbook.dtd*
> but a file *docbookx.dtd*
>
> I am also not sure if the —catalogs wants a single file, or a number of 
> files, as in
> docbook-xml-4.5/ (or docbook-xml-4.5) directory, I am not

 has a few 
information on catalogs. It
seems that the utility xmlcatalog.exe can be used to indicate the location and 
xml/xsl files
available locally, such that they need not be fetched from the net.

More on catalog files:  and 
about the book:
. Here the HTML-version of that 
book:
.

> I also read somewhere that you could enter the path to the dtd directly as 
> the first command on
> the commandline, but I never tried it.
>
> The debugging  process is very slow since you need to erase all files between 
> runs and wait 3-4
> minutes for the quickest files. And indeed if you have a fo file existing and 
> the xsltprocess
> breaks the fo2pdf will just use the existing fo file, this takes a few 
> seconds only.

>From the above HTML version a brief overview about xslt processors (xsltproc, 
>saxon, Apache
Xerxces/Xalan), how to install  and how to invoke them for docbook processing:
.

---

Looks like one of those things where the ones in the know think everything they 
know goes without
saying/is obvious and therefore not giving enough information for people who 
use this infrastructure
rarely or for the first time. It may boil down to the questions: where to store 
the dtd/xsl files,
how to define a catalog.xml file to point to them, how to get xsltproc (and its 
companion tools) to
find and honor the catalog file. (On Unix it seems the dtd/xsl files get stored 
to /etc/xml).

Ad Unix on Windows using "Cygwin": Cygwin is a utiltiy set of Unix programs for 
Windows
(http://cygwin.com/) with a library that allows to compile Unix programs for 
Windows. It also uses
the Unix file system conventions for its tools like forward slashes and the 
like. Cygwin remaps its
installation location to Unix style locations such that e.g. "/etc", "/bin" 
directories are
available for it. 

One can install Cygwin's xsltproc and docbook, and using a cygwin shell there 
is a "/etc/xml"
directory with two files, one called "catalog" one "docbook".  It is possible 
to install docbook 4.5
support and then out of the box creating the fo files (step doc2fo) worked:

Here are the Unix-style commands (in a Cygwin session on Windows) with their 
timings to produce the
fo files for rexxpg and rexxref:

Administrator@T450sRGF /cygdrive/g/oorexx.tmp/gilDocs/orxbldoc-2.0.1/cygwin
$ time xsltproc --xinclude --output rexxpg.fo --stringparam use.extensions 
0 pdf.xsl /cygdrive/f/work/svn/oorexx/docs/trunk/rexxpg/en-US/rexxpg.xml
Making portrait pages on A4 paper (210mmx297mm)

real0m2,669s
user0m2,421s
sys 0m0,156s

Administrator@T450sRGF /cygdrive/g/oorexx.tmp/gilDocs/orxbldoc-2.0.1/cygwin
$ time xsltproc --xinclude --output rexxref.fo --stringparam use.extensions 
0 pdf.xsl /cygdrive/f/work/svn/oorexx/docs/trunk/rexxref/en-US/rexxref.xml
Making portrait pages on A4 paper (210mmx297mm)

real0m33,451s
user0m33,062s
sys 0m0,233s

Administrator@T450sRGF /cygdrive/g/oorexx.tmp/gilDocs/orxbldoc-2.0.1/cygwin
$ ls -al *fo
-rw-r--r-- 1 Administrator None  1674990 27. Apr 15:18 rexxpg.fo
-rw-r--r-- 1 Administrator None 11505845 27. Apr 15:18 rexxref.fo

   

Re: [Oorexx-devel] Documentation on Jenkins

[P.O. Jonsson]

Phew! I have been trying to replicate your steps in vain for the past two days, 
I did not want to bother you with my failures. I also found out that making to 
many failing attempts I „broke“ JAVA so everything after these failures the 
error messages were completely unpredictable.

On Jenkins everything run smooth so it is only when you mistreat xsltproc that 
things start go bad.

This is what I found out so far:

Adding the option —catalogs (minus-minus-catalogs, the spell checker messes 
with my text), the DTD should be taken from what SGML_CATALOG_FILES points to. 
I have tried a number of things but nothing really worked.

All these did NOT work (and some others also not):

set 
SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/docbook.dtd/"
set 
SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/docbookx.dtd/"
set 
SGML_CATALOG_FILES="C:\Users\po\workspace\ooRexx-docs-build_V2\docbook-xml-4.5\docbookx.dtd"
set 
SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/"
set 
SGML_CATALOG_FILES="///C:/Users/po/workspace/ooRexx-docs-build_V2/docbook-xml-4.5/„

What I did notice is that the zipped archive you pointed to does not contain a 
file docbook.dtd but a file docbookx.dtd

I am also not sure if the —catalogs wants a single file, or a number of files, 
as in docbook-xml-4.5/ (or docbook-xml-4.5) directory, I am not

I also read somewhere that you could enter the path to the dtd directly as the 
first command on the commandline, but I never tried it.

The debugging  process is very slow since you need to erase all files between 
runs and wait 3-4 minutes for the quickest files. And indeed if you have a fo 
file existing and the xsltprocess breaks the fo2pdf will just use the existing 
fo file, this takes a few seconds only.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 26.04.2020 um 15:58 schrieb Rony G. Flatscher :
> 
> Well, after returning and setting up the environment according to my own 
> directions it turns out that they are *not* doing what I thought they were! :(
> 
> So please ignore this post.
> 
> ---rony
> 
> P.S.: Not sure what has happened, in the meantime I think it to be possible 
> that the step doc2fo was skipped and an existing fo file got processed, but 
> not sure (as a result I added statements to delete the output files before 
> creating the new ones to the local batch files).
> 
> P.P.S.: Still, I think the solution would be to get xsltproc to pick the dtd 
> and xls files from the local file system and not from the net. Just adding 
> "--nonet" will show which files cannot be loaded from the net. 
> 
> On 24.04.2020 16:19, Rony G. Flatscher wrote:
>> Looked into it and tested a possible solution, here the steps:
>> 
>> download the DocBook 4.5 DTDs from 
>>  
>> , unzip them, e.g. to 
>> "F:\work\svn\oorexx\docs\trunk\tools\tmp\docbook4.5\docbook.dtd"
>> 
>> define a new environment variable for xsltproc to point to the directory 
>> that contains the unzipped document type definitions, but watch out for the 
>> format on Windows: start out with three slashes and turn all backward 
>> slashes in the path to forward slashes, also note the trailing slash: 
>> set 
>> SGML_CATALOG_FILES=///F:/work/svn/oorexx/docs/trunk/tools/tmp/docbook4.5/docbook.dtd/"
>> Create the docs. 
>> E.g. "rexxref.pdf" now needs appr. 20 seconds to be created compared to more 
>> than 10 minutes without the local DTDs!
>> 
>> ---rony
>> 
>> 
>> On 23.04.2020 19:53, Gil Barmwater wrote:
>>> I suspect the slow performance might be due to the (repeated) fetching of 
>>> the DTDs/stylesheets by the xsltproc/transform step. My internet connection 
>>> is intermittently bad and I would sometimes get "failures" due to the 
>>> inability of the program to get one of the files it needed. I'd suggest 
>>> someone look into making the files "local" so that they need not be 
>>> downloaded multiple times per "book". These files are "ancient" so there is 
>>> no need to worry about not getting the latest version.
>>> 
>>> Gil
>>> On 4/23/2020 1:07 PM, René Jansen wrote:
 good work!
 
 Amazingly slow performance though - needs more memory?
 
 René
 
> On 23 Apr 2020, at 19:04, P.O. Jonsson  > wrote:
> 
> This is just to say that we now also have a bild of the HTML 
> documentation on Jenkins. It takes 1h30 to build the PDF and 1h50 to 
> build the HTML and I have set it to build@midnight, PDF first and HTML 
> thereafter. This can be changed if needed. All documents seems to build 
> just fine.
> 
> There is currently no upload of documentation to Sourceforge -> Erich?
> 
> To get hold of the documentation log in to Jenkins 
>  and select ooRexx-docs-build (PDF) or 
> ooRexx-docs-build2

Re: [Oorexx-devel] Documentation on Jenkins

[Rony G. Flatscher]

Well, after returning and setting up the environment according to my own 
directions it turns out
that they are *not* doing what I thought they were! :(

So please ignore this post.

---rony

P.S.: Not sure what has happened, in the meantime I think it to be possible 
that the step doc2fo was
skipped and an existing fo file got processed, but not sure (as a result I 
added statements to
delete the output files before creating the new ones to the local batch files).

P.P.S.: Still, I think the solution would be to get xsltproc to pick the dtd 
and xls files from the
local file system and not from the net. Just adding "--nonet" will show which 
files cannot be loaded
from the net.


On 24.04.2020 16:19, Rony G. Flatscher wrote:
>
> Looked into it and tested a possible solution, here the steps:
>
>   * download the DocBook 4.5 DTDs from 
> , unzip them,
> e.g. to "F:\work\svn\oorexx\docs\trunk\tools\tmp\docbook4.5\docbook.dtd"
>
>   * define a new environment variable for xsltproc to point to the directory 
> that contains the
> unzipped document type definitions, but watch out for the format on 
> Windows: start out with
> three slashes and turn all backward slashes in the path to forward 
> slashes, also note the
> trailing slash:
> set 
> SGML_CATALOG_FILES=///F:/work/svn/oorexx/docs/trunk/tools/tmp/docbook4.5/docbook.dtd/"
>
> Create the docs.
>
> E.g. "rexxref.pdf" now needs appr. 20 seconds to be created compared to more 
> than 10 minutes
> without the local DTDs!
>
> ---rony
>
>
> On 23.04.2020 19:53, Gil Barmwater wrote:
>>
>> I suspect the slow performance might be due to the (repeated) fetching of 
>> the DTDs/stylesheets by
>> the xsltproc/transform step. My internet connection is intermittently bad 
>> and I would sometimes
>> get "failures" due to the inability of the program to get one of the files 
>> it needed. I'd suggest
>> someone look into making the files "local" so that they need not be 
>> downloaded multiple times per
>> "book". These files are "ancient" so there is no need to worry about not 
>> getting the latest version.
>>
>> Gil
>>
>> On 4/23/2020 1:07 PM, René Jansen wrote:
>>> good work!
>>>
>>> Amazingly slow performance though - needs more memory?
>>>
>>> René
>>>
 On 23 Apr 2020, at 19:04, P.O. Jonsson >>> > wrote:

 This is just to say that we now also have a bild of the HTML documentation 
 on Jenkins. It takes
 1h30 to build the PDF and 1h50 to build the HTML and I have set it to 
 build@midnight, PDF first
 and HTML thereafter. This can be changed if needed. All documents seems to 
 build just fine.

 There is currently no upload of documentation to Sourceforge -> Erich?

 To get hold of the documentation log in to Jenkins 
  and
 select ooRexx-docs-build (PDF) or ooRexx-docs-build2 (HTML) and then use 
 the link Last
 Successful Artifacts

 Due to the way Jenkins create new workspaces ooRexx-docs-build 
 ooRexx-docs-build2 are identical
 parallel folders with the same latest build tools from Gil, with some 
 minor changes to fit it
 into Jenkins environment.

 Hälsningar/Regards/Grüsse,
 P.O. Jonsson
 oor...@jonases.se 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Ruurd Idenburg]

Thanks Rene, got logged in now.

Also I'll be at the same location for the time being, so perhaps my 
Jenkins slave could be re-established if needed, I'm running Linux Mint 
19.3 (which is based on Ubuntu 18.04). Tell me what to do if that build 
would be welcomed.


Ruurd

On 4/24/20 3:15 PM, René Jansen wrote:

Hi Ruurd,

please try now.

René

On 24 Apr 2020, at 14:33, Ruurd Idenburg > wrote:


If I login to Jenkins I get:


  Access Denied

rji is missing the Overall/Read permission

So what's going on?

Ruurd

On 4/23/20 7:04 PM, P.O. Jonsson wrote:
This is just to say that we now also have a bild of the HTML 
documentation on Jenkins. It takes 1h30 to build the PDF and 1h50 to 
build the HTML and I have set it to build@midnight, PDF first and 
HTML thereafter. This can be changed if needed. All documents seems 
to build just fine.


There is currently no upload of documentation to Sourceforge -> Erich?

To get hold of the documentation log in to Jenkins 
 and select ooRexx-docs-build (PDF) 
or ooRexx-docs-build2 (HTML) and then use the link Last Successful 
Artifacts


Due to the way Jenkins create new workspaces ooRexx-docs-build 
ooRexx-docs-build2 are identical parallel folders with the same 
latest build tools from Gil, with some minor changes to fit it into 
Jenkins environment.


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se 





___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net 


https://lists.sourceforge.net/lists/listinfo/oorexx-devel




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[René Jansen]

Hi Rony,

well done! That is a step in the right direction.

René.


> On 24 Apr 2020, at 16:19, Rony G. Flatscher  wrote:
> 
> Looked into it and tested a possible solution, here the steps:
> 
> download the DocBook 4.5 DTDs from 
>  
> , unzip them, e.g. to 
> "F:\work\svn\oorexx\docs\trunk\tools\tmp\docbook4.5\docbook.dtd"
> 
> define a new environment variable for xsltproc to point to the directory that 
> contains the unzipped document type definitions, but watch out for the format 
> on Windows: start out with three slashes and turn all backward slashes in the 
> path to forward slashes, also note the trailing slash: 
> set 
> SGML_CATALOG_FILES=///F:/work/svn/oorexx/docs/trunk/tools/tmp/docbook4.5/docbook.dtd/"
> Create the docs. 
> 
> E.g. "rexxref.pdf" now needs appr. 20 seconds to be created compared to more 
> than 10 minutes without the local DTDs!
> 
> ---rony
> 
> 
> 
> On 23.04.2020 19:53, Gil Barmwater wrote:
>> I suspect the slow performance might be due to the (repeated) fetching of 
>> the DTDs/stylesheets by the xsltproc/transform step. My internet connection 
>> is intermittently bad and I would sometimes get "failures" due to the 
>> inability of the program to get one of the files it needed. I'd suggest 
>> someone look into making the files "local" so that they need not be 
>> downloaded multiple times per "book". These files are "ancient" so there is 
>> no need to worry about not getting the latest version.
>> 
>> Gil
>> 
>> On 4/23/2020 1:07 PM, René Jansen wrote:
>>> good work!
>>> 
>>> Amazingly slow performance though - needs more memory?
>>> 
>>> René
>>> 
 On 23 Apr 2020, at 19:04, P.O. Jonsson >>> > wrote:
 
 This is just to say that we now also have a bild of the HTML documentation 
 on Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and 
 I have set it to build@midnight, PDF first and HTML thereafter. This can 
 be changed if needed. All documents seems to build just fine.
 
 There is currently no upload of documentation to Sourceforge -> Erich?
 
 To get hold of the documentation log in to Jenkins 
  and select ooRexx-docs-build (PDF) or 
 ooRexx-docs-build2 (HTML) and then use the link Last Successful Artifacts
 
 Due to the way Jenkins create new workspaces ooRexx-docs-build 
 ooRexx-docs-build2 are identical parallel folders with the same latest 
 build tools from Gil, with some minor changes to fit it into Jenkins 
 environment.
 
 Hälsningar/Regards/Grüsse,
 P.O. Jonsson
 oor...@jonases.se 
 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Rony G. Flatscher]

Looked into it and tested a possible solution, here the steps:

  * download the DocBook 4.5 DTDs from 
, unzip them,
e.g. to "F:\work\svn\oorexx\docs\trunk\tools\tmp\docbook4.5\docbook.dtd"

  * define a new environment variable for xsltproc to point to the directory 
that contains the
unzipped document type definitions, but watch out for the format on 
Windows: start out with
three slashes and turn all backward slashes in the path to forward slashes, 
also note the
trailing slash:
set 
SGML_CATALOG_FILES=///F:/work/svn/oorexx/docs/trunk/tools/tmp/docbook4.5/docbook.dtd/"

Create the docs.

E.g. "rexxref.pdf" now needs appr. 20 seconds to be created compared to more 
than 10 minutes without
the local DTDs!

---rony


On 23.04.2020 19:53, Gil Barmwater wrote:
>
> I suspect the slow performance might be due to the (repeated) fetching of the 
> DTDs/stylesheets by
> the xsltproc/transform step. My internet connection is intermittently bad and 
> I would sometimes
> get "failures" due to the inability of the program to get one of the files it 
> needed. I'd suggest
> someone look into making the files "local" so that they need not be 
> downloaded multiple times per
> "book". These files are "ancient" so there is no need to worry about not 
> getting the latest version.
>
> Gil
>
> On 4/23/2020 1:07 PM, René Jansen wrote:
>> good work!
>>
>> Amazingly slow performance though - needs more memory?
>>
>> René
>>
>>> On 23 Apr 2020, at 19:04, P.O. Jonsson >> > wrote:
>>>
>>> This is just to say that we now also have a bild of the HTML documentation 
>>> on Jenkins. It takes
>>> 1h30 to build the PDF and 1h50 to build the HTML and I have set it to 
>>> build@midnight, PDF first
>>> and HTML thereafter. This can be changed if needed. All documents seems to 
>>> build just fine.
>>>
>>> There is currently no upload of documentation to Sourceforge -> Erich?
>>>
>>> To get hold of the documentation log in to Jenkins 
>>>  and
>>> select ooRexx-docs-build (PDF) or ooRexx-docs-build2 (HTML) and then use 
>>> the link Last
>>> Successful Artifacts
>>>
>>> Due to the way Jenkins create new workspaces ooRexx-docs-build 
>>> ooRexx-docs-build2 are identical
>>> parallel folders with the same latest build tools from Gil, with some minor 
>>> changes to fit it
>>> into Jenkins environment.
>>>
>>> Hälsningar/Regards/Grüsse,
>>> P.O. Jonsson
>>> oor...@jonases.se 
>>>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[René Jansen]

Hi Ruurd,

please try now.

René

> On 24 Apr 2020, at 14:33, Ruurd Idenburg  wrote:
> 
> If I login to Jenkins I get:
> 
> Access Denied
> 
> rji is missing the Overall/Read permission
> 
> So what's going on?
> 
> Ruurd
> 
> On 4/23/20 7:04 PM, P.O. Jonsson wrote:
>> This is just to say that we now also have a bild of the HTML documentation 
>> on Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and I 
>> have set it to build@midnight, PDF first and HTML thereafter. This can be 
>> changed if needed. All documents seems to build just fine.
>> 
>> There is currently no upload of documentation to Sourceforge -> Erich?
>> 
>> To get hold of the documentation log in to Jenkins 
>>  and select ooRexx-docs-build (PDF) or 
>> ooRexx-docs-build2 (HTML) and then use the link Last Successful Artifacts
>> 
>> Due to the way Jenkins create new workspaces ooRexx-docs-build 
>> ooRexx-docs-build2 are identical parallel folders with the same latest build 
>> tools from Gil, with some minor changes to fit it into Jenkins environment.
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
>> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Ruurd Idenburg]

If I login to Jenkins I get:


 Access Denied

rji is missing the Overall/Read permission

So what's going on?

Ruurd

On 4/23/20 7:04 PM, P.O. Jonsson wrote:
This is just to say that we now also have a bild of the HTML 
documentation on Jenkins. It takes 1h30 to build the PDF and 1h50 to 
build the HTML and I have set it to build@midnight, PDF first and HTML 
thereafter. This can be changed if needed. All documents seems to 
build just fine.


There is currently no upload of documentation to Sourceforge -> Erich?

To get hold of the documentation log in to Jenkins 
 and select ooRexx-docs-build (PDF) 
or ooRexx-docs-build2 (HTML) and then use the link Last Successful 
Artifacts


Due to the way Jenkins create new workspaces ooRexx-docs-build 
ooRexx-docs-build2 are identical parallel folders with the same latest 
build tools from Gil, with some minor changes to fit it into Jenkins 
environment.


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se 





___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[P. O. Jonsson]

No memory problem and not a CPU problem. The machine is virtually idling while 
building. It takes the same time on a 50 times faster machine. I suspect a http 
problem as Gil points to. This was the same with publican. 

Von meinem iPhone gesendet

> Am 23.04.2020 um 19:07 schrieb René Jansen :
> 
> good work!
> 
> Amazingly slow performance though - needs more memory?
> 
> René
> 
>> On 23 Apr 2020, at 19:04, P.O. Jonsson  wrote:
>> 
>> This is just to say that we now also have a bild of the HTML documentation 
>> on Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and I 
>> have set it to build@midnight, PDF first and HTML thereafter. This can be 
>> changed if needed. All documents seems to build just fine.
>> 
>> There is currently no upload of documentation to Sourceforge -> Erich?
>> 
>> To get hold of the documentation log in to Jenkins and select 
>> ooRexx-docs-build (PDF) or ooRexx-docs-build2 (HTML) and then use the link 
>> Last Successful Artifacts
>> 
>> Due to the way Jenkins create new workspaces ooRexx-docs-build 
>> ooRexx-docs-build2 are identical parallel folders with the same latest build 
>> tools from Gil, with some minor changes to fit it into Jenkins environment.
>> 
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>> 
>> 
>> 
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[Gil Barmwater]

I suspect the slow performance might be due to the (repeated) fetching 
of the DTDs/stylesheets by the xsltproc/transform step. My internet 
connection is intermittently bad and I would sometimes get "failures" 
due to the inability of the program to get one of the files it needed. 
I'd suggest someone look into making the files "local" so that they need 
not be downloaded multiple times per "book". These files are "ancient" 
so there is no need to worry about not getting the latest version.


Gil

On 4/23/2020 1:07 PM, René Jansen wrote:

good work!

Amazingly slow performance though - needs more memory?

René

On 23 Apr 2020, at 19:04, P.O. Jonsson > wrote:


This is just to say that we now also have a bild of the HTML 
documentation on Jenkins. It takes 1h30 to build the PDF and 1h50 to 
build the HTML and I have set it to build@midnight, PDF first and 
HTML thereafter. This can be changed if needed. All documents seems 
to build just fine.


There is currently no upload of documentation to Sourceforge -> Erich?

To get hold of the documentation log in to Jenkins 
 and select ooRexx-docs-build (PDF) 
or ooRexx-docs-build2 (HTML) and then use the link Last Successful 
Artifacts


Due to the way Jenkins create new workspaces ooRexx-docs-build 
ooRexx-docs-build2 are identical parallel folders with the same 
latest build tools from Gil, with some minor changes to fit it into 
Jenkins environment.


Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se 



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net 


https://lists.sourceforge.net/lists/listinfo/oorexx-devel




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
Gil Barmwater

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation on Jenkins

[René Jansen]

good work!

Amazingly slow performance though - needs more memory?

René

> On 23 Apr 2020, at 19:04, P.O. Jonsson  wrote:
> 
> This is just to say that we now also have a bild of the HTML documentation on 
> Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and I have 
> set it to build@midnight, PDF first and HTML thereafter. This can be changed 
> if needed. All documents seems to build just fine.
> 
> There is currently no upload of documentation to Sourceforge -> Erich?
> 
> To get hold of the documentation log in to Jenkins  
> and select ooRexx-docs-build (PDF) or ooRexx-docs-build2 (HTML) and then use 
> the link Last Successful Artifacts
> 
> Due to the way Jenkins create new workspaces ooRexx-docs-build 
> ooRexx-docs-build2 are identical parallel folders with the same latest build 
> tools from Gil, with some minor changes to fit it into Jenkins environment.
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation on Jenkins

[P.O. Jonsson]

This is just to say that we now also have a bild of the HTML documentation on 
Jenkins. It takes 1h30 to build the PDF and 1h50 to build the HTML and I have 
set it to build@midnight, PDF first and HTML thereafter. This can be changed if 
needed. All documents seems to build just fine.

There is currently no upload of documentation to Sourceforge -> Erich?

To get hold of the documentation log in to Jenkins  
and select ooRexx-docs-build (PDF) or ooRexx-docs-build2 (HTML) and then use 
the link Last Successful Artifacts

Due to the way Jenkins create new workspaces ooRexx-docs-build 
ooRexx-docs-build2 are identical parallel folders with the same latest build 
tools from Gil, with some minor changes to fit it into Jenkins environment.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Rick McGuire]

I have multiple objections to this being included as is:

1) Wrong license
2) No ooRexx copyright statement
3) We don't put change logs in commentary. Source control is what manages
change logs.
4) We don't identify specific authors in any of our source files. Once
contributed, it is community owned.
5) I have the same objection to the name. If this is going to be part of
the project files, than it should not have the rgf_* name.
6) The scope of this goes beyond the need for the doc tooling. It would be
better if the relevant bits are just moved into createClassHierarchy.rex

createClassHierarchy.rex also has problems 1-4.

Rick

On Tue, Mar 24, 2020 at 2:31 PM Erich Steinböck 
wrote:

> ooRexx only accepts Common Public License v1.0
> You are providing your rgf_util2.rex under ASF 2.0
>
> On Mon, Mar 23, 2020 at 7:14 PM Rony G. Flatscher 
> wrote:
>
>> Hi Erich,
>>
>> On 22.03.2020 11:56, Erich Steinböck wrote:
>> > I agree with Gil.  Let's stay with our current coding/tagging style and
>> the typographic conventions.
>> I concur as well, see my follow-up to Gil's mail.
>> > Also, rgf_util2.rex is unacceptable for inclusion in our svn.  Please
>> fix the copyright or remove
>> > it from the svn, and please also do so for any other of your current or
>> future commits.
>>
>> What is the problem (I really do not understand)? What constitutes a
>> "fix"?
>>
>> ---rony
>>
>> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Erich Steinböck]

ooRexx only accepts Common Public License v1.0
You are providing your rgf_util2.rex under ASF 2.0

On Mon, Mar 23, 2020 at 7:14 PM Rony G. Flatscher 
wrote:

> Hi Erich,
>
> On 22.03.2020 11:56, Erich Steinböck wrote:
> > I agree with Gil.  Let's stay with our current coding/tagging style and
> the typographic conventions.
> I concur as well, see my follow-up to Gil's mail.
> > Also, rgf_util2.rex is unacceptable for inclusion in our svn.  Please
> fix the copyright or remove
> > it from the svn, and please also do so for any other of your current or
> future commits.
>
> What is the problem (I really do not understand)? What constitutes a "fix"?
>
> ---rony
>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Erich Steinböck]

-
>
> have classnames, literals and the like marked up with the methodname tag
> in title elements to see its effect on the TOC formatting?
> Is it o.k. to use the methodname tag for marking up keywords, subkeywords
> and directives?

- I totally disagree with intentional mis-tagging.
-
- Only tag as much as it makes things more clear while still keeping the
document readable.
-
- And please never tag in a heading.
-
-

On Mon, Mar 23, 2020 at 7:11 PM Rony G. Flatscher 
wrote:

> Hi Gil,
> On 20.03.2020 19:07, Gil Barmwater wrote:
>
> I finally have had an opportunity to look into this issue. I downloaded
> your version of rexxpg and opened it next to the one that comes with the
> ooRexx build which is "pre-split" so it has none of the changes that you
> have made. One thing I noticed was that you have added tags "inside" the
> examples which I had not seen before. My understanding of the
>  tag was that it was supposed to show code examples or
> snippets "as-is" with the possible exception of syntax highlighting, a
> separate issue. Now, as you have demonstrated, you CAN "tag" parts of a
>  or  section but I don't see the benefit of doing so.
>
> You assume too much, there was no intention to mark-up text in
> programlisting elements! :)
>
> After splitting the book I noticed that the programmer's guide had much
> text that was not marked up. As with marking up the EventSemaphore or
> MutexSemaphore class I looked around those xml files to see what tags would
> be used to mark up the text and used it myself short of knowing the DocBook
> tags and when and where to apply them.
>
> Similarly, tagging words in the section titles causes the TOC (which is
> automatically generated) to display them accordingly. So, if it were me
> doing the work, I would only use the tags in the paragraphs where they draw
> the distinction between the prose and the "names" of important things.
>
> That is exactly what I have been trying to do as it is a *lot* of work to
> read and look through the text and marking up the text accordingly (this
> has not been work of a few hours but of a few days by now!).
>
> Ad TOC: I was under impression, after skimming through the css files, that
> the boldness in TOCs would be removed, cf. "css/common.css", lines 743-746:
>
> /* no bold in toc */
> .toc * {
>   font-weight: inherit;
> }
>
>
> Thought that the HTML formatting would follow the DocBook rendering, hence
> asking for a means to remove or at least reducing the boldness in the TOC.
>
> The overhauled version currently applies the mark-up to all the respective
> text, e.g. all class names in titles get marked up with the "classname"
> tag. However, they show as bold as do literals like .environment and .local
> which looks quite distracting for me.
>
> As this boldness in the TOC seems to be quite disturbing my original
> question about a possibility to remove/reduce the boldness from/in the TOC.
>
> Text that denotes classnames, literals and such IMHO should be
> distinguishable in its type from regular text in titles as well. One way to
> achieve that - which I know now - would be to mark-up such text with the
> methodname tag, which gets formatted to monospaced-normal according to the
> Conventions explanation.
>
> Would that be something everyone could agree upon in theory?
>
> If so I would change that title markup accordingly to render a new version
> of rexxpg for assessment and comparison to finally decide upon it. (I just
> would like to save me the work if everyone thinks it is not worth to test.)
>
> Again, just my opinion. Our documents have always only used the three
> types of typographic conventions described in the the Preface of each book.
> Deviating from that "standard" needs a whole lot more discussion and
> consideration IMHO.
>
> I agree.
>
> While analyzing and overhauling the markup in the past days I created a
> "test" book that includes the markup that the ooRexx books use, which are
> by far not all the elements that DocBook defines as I have found out (cf.
> 
> ).
>
> The directory "oorexx/en_US" seems to have all the files from some DocBook
> distribution. Its Conventions.xml demonstrates many more elements, such
> that I have included them in the aforementioned "test" book just to see -
> after formatting the test book - which elements render how and whether
> there are elements that we do not use but might be useful.
>
> There could be much more said after all that work and research, but maybe
> at another occasion.
>
> After almost finishing the overhaul, there is another markup that may need
> agreement: marking up keywords (and subkeywords) and directives. I have
> applied the methodname tag (monospaced-normal) for them, short of better
> matching tag names, thinking that they ought to be set the same as method
> names.
>
> Please take a look at that and please give feedback ASAP whether that is
> o.k.?
>
> 

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[P.O. Jonsson]

Dear Rony,

I have collected the 12003 doc build from Jenkins and put it in my dropbox 
, 
where you can collect them. Rexxpg is r12001 still.

It is quite easy to get them from Jenkins, just log in to Jenkins, select the 
job ooRexx-docs-build -> Workspace -> PDF_files

If you want to make a new build of the complete documentation make sure that 
Win32 or Win64 is not building at the same time, I have not tested this in 
parallel on the same machine (yet).

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 24.03.2020 um 14:18 schrieb Rony G. Flatscher :
> 
> Forgot to check in my changes that have led to yesterday's rendering of the 
> rexxpg book, checked in with r12003.
> 
> ---rony
> On 23.03.2020 19:09, Rony G. Flatscher wrote:
>> Hi Gil,
>> On 20.03.2020 19:07, Gil Barmwater wrote:
>>> I finally have had an opportunity to look into this issue. I downloaded 
>>> your version of rexxpg and opened it next to the one that comes with the 
>>> ooRexx build which is "pre-split" so it has none of the changes that you 
>>> have made. One thing I noticed was that you have added tags "inside" the 
>>> examples which I had not seen before. My understanding of the 
>>>  tag was that it was supposed to show code examples or 
>>> snippets "as-is" with the possible exception of syntax highlighting, a 
>>> separate issue. Now, as you have demonstrated, you CAN "tag" parts of a 
>>>  or  section but I don't see the benefit of doing so.
>> You assume too much, there was no intention to mark-up text in 
>> programlisting elements! :)
>> 
>> After splitting the book I noticed that the programmer's guide had much text 
>> that was not marked up. As with marking up the EventSemaphore or 
>> MutexSemaphore class I looked around those xml files to see what tags would 
>> be used to mark up the text and used it myself short of knowing the DocBook 
>> tags and when and where to apply them.
>>> Similarly, tagging words in the section titles causes the TOC (which is 
>>> automatically generated) to display them accordingly. So, if it were me 
>>> doing the work, I would only use the tags in the paragraphs where they draw 
>>> the distinction between the prose and the "names" of important things.
>> That is exactly what I have been trying to do as it is a *lot* of work to 
>> read and look through the text and marking up the text accordingly (this has 
>> not been work of a few hours but of a few days by now!). 
>> 
>> Ad TOC: I was under impression, after skimming through the css files, that 
>> the boldness in TOCs would be removed, cf. "css/common.css", lines 743-746:
>> /* no bold in toc */
>> .toc * {
>>  font-weight: inherit;
>> }
>> 
>> Thought that the HTML formatting would follow the DocBook rendering, hence 
>> asking for a means to remove or at least reducing the boldness in the TOC.
>> 
>> The overhauled version currently applies the mark-up to all the respective 
>> text, e.g. all class names in titles get marked up with the "classname" tag. 
>> However, they show as bold as do literals like .environment and .local which 
>> looks quite distracting for me.
>> 
>> As this boldness in the TOC seems to be quite disturbing my original 
>> question about a possibility to remove/reduce the boldness from/in the TOC.
>> 
>> Text that denotes classnames, literals and such IMHO should be 
>> distinguishable in its type from regular text in titles as well. One way to 
>> achieve that - which I know now - would be to mark-up such text with the 
>> methodname tag, which gets formatted to monospaced-normal according to the 
>> Conventions explanation. 
>> Would that be something everyone could agree upon in theory? 
>> If so I would change that title markup accordingly to render a new version 
>> of rexxpg for assessment and comparison to finally decide upon it. (I just 
>> would like to save me the work if everyone thinks it is not worth to test.)
>>> Again, just my opinion. Our documents have always only used the three types 
>>> of typographic conventions described in the the Preface of each book. 
>>> Deviating from that "standard" needs a whole lot more discussion and 
>>> consideration IMHO. 
>> I agree.
>> 
>> While analyzing and overhauling the markup in the past days I created a 
>> "test" book that includes the markup that the ooRexx books use, which are by 
>> far not all the elements that DocBook defines as I have found out (cf. 
>>  
>> ). 
>> The directory "oorexx/en_US" seems to have all the files from some DocBook 
>> distribution. Its Conventions.xml demonstrates many more elements, such that 
>> I have included them in the aforementioned "test" book just to see - after 
>> formatting the test book - which elements render how and whether there are 
>> elements that we do not use but might be useful. 
>> There could be much more said a

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Chip Davis]

Gosh, Gil.  Don't say _that_.  These days you're better off saying, 
"My hemorrhoids are flaring up and I can't sit at the computer" than 
let people speculate that you've come down with SARS-CoV2 ... :-X


On 3/24/2020 10:57 AM, Gil Barmwater wrote:


FYI - my "silence" on this thread is not due to lack of interest or 
having no comment but rather to being a bit "under the weather" at 
the moment. As soon as I am able, I will offer my thoughts.




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Gil Barmwater]

FYI - my "silence" on this thread is not due to lack of interest or 
having no comment but rather to being a bit "under the weather" at the 
moment. As soon as I am able, I will offer my thoughts.


Gil

On 3/24/2020 9:18 AM, Rony G. Flatscher wrote:


Forgot to check in my changes that have led to yesterday's rendering 
of the rexxpg book, checked in with r12003.


---rony

On 23.03.2020 19:09, Rony G. Flatscher wrote:


Hi Gil,

On 20.03.2020 19:07, Gil Barmwater wrote:
I finally have had an opportunity to look into this issue. I 
downloaded your version of rexxpg and opened it next to the one that 
comes with the ooRexx build which is "pre-split" so it has none of 
the changes that you have made. One thing I noticed was that you 
have added tags "inside" the examples which I had not seen before. 
My understanding of the  tag was that it was 
supposed to show code examples or snippets "as-is" with the possible 
exception of syntax highlighting, a separate issue. Now, as you have 
demonstrated, you CAN "tag" parts of a  or  
section but I don't see the benefit of doing so. 


You assume too much, there was no intention to mark-up text in 
programlisting elements! :)


After splitting the book I noticed that the programmer's guide had 
much text that was not marked up. As with marking up the 
EventSemaphore or MutexSemaphore class I looked around those xml 
files to see what tags would be used to mark up the text and used it 
myself short of knowing the DocBook tags and when and where to apply 
them.


Similarly, tagging words in the section titles causes the TOC (which 
is automatically generated) to display them accordingly. So, if it 
were me doing the work, I would only use the tags in the paragraphs 
where they draw the distinction between the prose and the "names" of 
important things. 


That is exactly what I have been trying to do as it is a *lot* of 
work to read and look through the text and marking up the text 
accordingly (this has not been work of a few hours but of a few days 
by now!).


Ad TOC: I was under impression, after skimming through the css files, 
that the boldness in TOCs would be removed, cf. "css/common.css", 
lines 743-746:


/* no bold in toc */
.toc * {
font-weight: inherit;
}

Thought that the HTML formatting would follow the DocBook rendering, 
hence asking for a means to remove or at least reducing the boldness 
in the TOC.


The overhauled version currently applies the mark-up to all the 
respective text, e.g. all class names in titles get marked up with 
the "classname" tag. However, they show as bold as do literals like 
.environment and .local which looks quite distracting for me.


As this boldness in the TOC seems to be quite disturbing my original 
question about a possibility to remove/reduce the boldness from/in 
the TOC.


Text that denotes classnames, literals and such IMHO should be 
distinguishable in its type from regular text in titles as well. One 
way to achieve that - which I know now - would be to mark-up such 
text with the methodname tag, which gets formatted to 
monospaced-normal according to the Conventions explanation.


Would that be something everyone could agree upon in theory?

If so I would change that title markup accordingly to render a new 
version of rexxpg for assessment and comparison to finally decide 
upon it. (I just would like to save me the work if everyone thinks it 
is not worth to test.)


Again, just my opinion. Our documents have always only used the 
three types of typographic conventions described in the the Preface 
of each book. Deviating from that "standard" needs a whole lot more 
discussion and consideration IMHO.


I agree.

While analyzing and overhauling the markup in the past days I created 
a "test" book that includes the markup that the ooRexx books use, 
which are by far not all the elements that DocBook defines as I have 
found out (cf. ).


The directory "oorexx/en_US" seems to have all the files from some 
DocBook distribution. Its Conventions.xml demonstrates many more 
elements, such that I have included them in the aforementioned "test" 
book just to see - after formatting the test book - which elements 
render how and whether there are elements that we do not use but 
might be useful.


There could be much more said after all that work and research, but 
maybe at another occasion.


After almost finishing the overhaul, there is another markup that may 
need agreement: marking up keywords (and subkeywords) and directives. 
I have applied the methodname tag (monospaced-normal) for them, short 
of better matching tag names, thinking that they ought to be set the 
same as method names.


Please take a look at that and please give feedback ASAP whether that 
is o.k.?


If it is o.k. the "Document Conventions" need to be changed 
accordingly as well.




On 3/20/2020 9:15 AM, Rony G. Flatscher wrote:

On 19.03.2020 14:31, Gil Barmwater wrote:
Having 

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[P.O. Jonsson]

Dear Rony,

The build of documentation on Jenkins has not run since the 20th, the revision 
for rexxpg is 11998.

I am rebuilding the documentation now, in an hour I can see if it built ok.

(The Win slave had rebooted without reconnecting, this happens every now & 
then. MS.)

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 24.03.2020 um 14:18 schrieb Rony G. Flatscher :
> 
> Forgot to check in my changes that have led to yesterday's rendering of the 
> rexxpg book, checked in with r12003.
> 
> ---rony
> On 23.03.2020 19:09, Rony G. Flatscher wrote:
>> Hi Gil,
>> On 20.03.2020 19:07, Gil Barmwater wrote:
>>> I finally have had an opportunity to look into this issue. I downloaded 
>>> your version of rexxpg and opened it next to the one that comes with the 
>>> ooRexx build which is "pre-split" so it has none of the changes that you 
>>> have made. One thing I noticed was that you have added tags "inside" the 
>>> examples which I had not seen before. My understanding of the 
>>>  tag was that it was supposed to show code examples or 
>>> snippets "as-is" with the possible exception of syntax highlighting, a 
>>> separate issue. Now, as you have demonstrated, you CAN "tag" parts of a 
>>>  or  section but I don't see the benefit of doing so.
>> You assume too much, there was no intention to mark-up text in 
>> programlisting elements! :)
>> 
>> After splitting the book I noticed that the programmer's guide had much text 
>> that was not marked up. As with marking up the EventSemaphore or 
>> MutexSemaphore class I looked around those xml files to see what tags would 
>> be used to mark up the text and used it myself short of knowing the DocBook 
>> tags and when and where to apply them.
>>> Similarly, tagging words in the section titles causes the TOC (which is 
>>> automatically generated) to display them accordingly. So, if it were me 
>>> doing the work, I would only use the tags in the paragraphs where they draw 
>>> the distinction between the prose and the "names" of important things.
>> That is exactly what I have been trying to do as it is a *lot* of work to 
>> read and look through the text and marking up the text accordingly (this has 
>> not been work of a few hours but of a few days by now!). 
>> 
>> Ad TOC: I was under impression, after skimming through the css files, that 
>> the boldness in TOCs would be removed, cf. "css/common.css", lines 743-746:
>> /* no bold in toc */
>> .toc * {
>>  font-weight: inherit;
>> }
>> 
>> Thought that the HTML formatting would follow the DocBook rendering, hence 
>> asking for a means to remove or at least reducing the boldness in the TOC.
>> 
>> The overhauled version currently applies the mark-up to all the respective 
>> text, e.g. all class names in titles get marked up with the "classname" tag. 
>> However, they show as bold as do literals like .environment and .local which 
>> looks quite distracting for me.
>> 
>> As this boldness in the TOC seems to be quite disturbing my original 
>> question about a possibility to remove/reduce the boldness from/in the TOC.
>> 
>> Text that denotes classnames, literals and such IMHO should be 
>> distinguishable in its type from regular text in titles as well. One way to 
>> achieve that - which I know now - would be to mark-up such text with the 
>> methodname tag, which gets formatted to monospaced-normal according to the 
>> Conventions explanation. 
>> Would that be something everyone could agree upon in theory? 
>> If so I would change that title markup accordingly to render a new version 
>> of rexxpg for assessment and comparison to finally decide upon it. (I just 
>> would like to save me the work if everyone thinks it is not worth to test.)
>>> Again, just my opinion. Our documents have always only used the three types 
>>> of typographic conventions described in the the Preface of each book. 
>>> Deviating from that "standard" needs a whole lot more discussion and 
>>> consideration IMHO. 
>> I agree.
>> 
>> While analyzing and overhauling the markup in the past days I created a 
>> "test" book that includes the markup that the ooRexx books use, which are by 
>> far not all the elements that DocBook defines as I have found out (cf. 
>>  
>> ). 
>> The directory "oorexx/en_US" seems to have all the files from some DocBook 
>> distribution. Its Conventions.xml demonstrates many more elements, such that 
>> I have included them in the aforementioned "test" book just to see - after 
>> formatting the test book - which elements render how and whether there are 
>> elements that we do not use but might be useful. 
>> There could be much more said after all that work and research, but maybe at 
>> another occasion. 
>> After almost finishing the overhaul, there is another markup that may need 
>> agreement: marking up keywords (and subkeywords) and directives. I have 
>> applied the methodname tag (mono

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Rony G. Flatscher]

Forgot to check in my changes that have led to yesterday's rendering of the 
rexxpg book, checked in
with r12003.

---rony

On 23.03.2020 19:09, Rony G. Flatscher wrote:
>
> Hi Gil,
>
> On 20.03.2020 19:07, Gil Barmwater wrote:
>> I finally have had an opportunity to look into this issue. I downloaded your 
>> version of rexxpg
>> and opened it next to the one that comes with the ooRexx build which is 
>> "pre-split" so it has
>> none of the changes that you have made. One thing I noticed was that you 
>> have added tags "inside"
>> the examples which I had not seen before. My understanding of the 
>>  tag was that
>> it was supposed to show code examples or snippets "as-is" with the possible 
>> exception of syntax
>> highlighting, a separate issue. Now, as you have demonstrated, you CAN "tag" 
>> parts of a  or
>>  section but I don't see the benefit of doing so. 
>
> You assume too much, there was no intention to mark-up text in programlisting 
> elements! :)
>
> After splitting the book I noticed that the programmer's guide had much text 
> that was not marked
> up. As with marking up the EventSemaphore or MutexSemaphore class I looked 
> around those xml files
> to see what tags would be used to mark up the text and used it myself short 
> of knowing the DocBook
> tags and when and where to apply them.
>
>> Similarly, tagging words in the section titles causes the TOC (which is 
>> automatically generated)
>> to display them accordingly. So, if it were me doing the work, I would only 
>> use the tags in the
>> paragraphs where they draw the distinction between the prose and the "names" 
>> of important things. 
>
> That is exactly what I have been trying to do as it is a *lot* of work to 
> read and look through
> the text and marking up the text accordingly (this has not been work of a few 
> hours but of a few
> days by now!). 
>
> Ad TOC: I was under impression, after skimming through the css files, that 
> the boldness in TOCs
> would be removed, cf. "css/common.css", lines 743-746:
>
> /* no bold in toc */
> .toc * {
>   font-weight: inherit;
> }
>
> Thought that the HTML formatting would follow the DocBook rendering, hence 
> asking for a means to
> remove or at least reducing the boldness in the TOC.
>
> The overhauled version currently applies the mark-up to all the respective 
> text, e.g. all class
> names in titles get marked up with the "classname" tag. However, they show as 
> bold as do literals
> like .environment and .local which looks quite distracting for me.
>
> As this boldness in the TOC seems to be quite disturbing my original question 
> about a possibility
> to remove/reduce the boldness from/in the TOC.
>
> Text that denotes classnames, literals and such IMHO should be 
> distinguishable in its type from
> regular text in titles as well. One way to achieve that - which I know now - 
> would be to mark-up
> such text with the methodname tag, which gets formatted to monospaced-normal 
> according to the
> Conventions explanation.
>
> Would that be something everyone could agree upon in theory?
>
> If so I would change that title markup accordingly to render a new version of 
> rexxpg for
> assessment and comparison to finally decide upon it. (I just would like to 
> save me the work if
> everyone thinks it is not worth to test.)
>
>> Again, just my opinion. Our documents have always only used the three types 
>> of typographic
>> conventions described in the the Preface of each book. Deviating from that 
>> "standard" needs a
>> whole lot more discussion and consideration IMHO.
>
> I agree.
>
> While analyzing and overhauling the markup in the past days I created a 
> "test" book that includes
> the markup that the ooRexx books use, which are by far not all the elements 
> that DocBook defines
> as I have found out (cf. ).
>
> The directory "oorexx/en_US" seems to have all the files from some DocBook 
> distribution. Its
> Conventions.xml demonstrates many more elements, such that I have included 
> them in the
> aforementioned "test" book just to see - after formatting the test book - 
> which elements render
> how and whether there are elements that we do not use but might be useful.
>
> There could be much more said after all that work and research, but maybe at 
> another occasion.
>
> After almost finishing the overhaul, there is another markup that may need 
> agreement: marking up
> keywords (and subkeywords) and directives. I have applied the methodname tag 
> (monospaced-normal)
> for them, short of better matching tag names, thinking that they ought to be 
> set the same as
> method names.
>
> Please take a look at that and please give feedback ASAP whether that is o.k.?
>
> If it is o.k. the "Document Conventions" need to be changed accordingly as 
> well.
>
>>
>> On 3/20/2020 9:15 AM, Rony G. Flatscher wrote:
>>> On 19.03.2020 14:31, Gil Barmwater wrote:
 Having spent some time looking at the documentati

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Rony G. Flatscher]

Hi Erich,

On 22.03.2020 11:56, Erich Steinböck wrote:
> I agree with Gil.  Let's stay with our current coding/tagging style and the 
> typographic conventions.
I concur as well, see my follow-up to Gil's mail.
> Also, rgf_util2.rex is unacceptable for inclusion in our svn.  Please fix the 
> copyright or remove
> it from the svn, and please also do so for any other of your current or 
> future commits.

What is the problem (I really do not understand)? What constitutes a "fix"?

---rony






___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Rony G. Flatscher]

Hi Gil,

On 20.03.2020 19:07, Gil Barmwater wrote:
> I finally have had an opportunity to look into this issue. I downloaded your 
> version of rexxpg and
> opened it next to the one that comes with the ooRexx build which is 
> "pre-split" so it has none of
> the changes that you have made. One thing I noticed was that you have added 
> tags "inside" the
> examples which I had not seen before. My understanding of the 
>  tag was that it was
> supposed to show code examples or snippets "as-is" with the possible 
> exception of syntax
> highlighting, a separate issue. Now, as you have demonstrated, you CAN "tag" 
> parts of a  or
>  section but I don't see the benefit of doing so. 

You assume too much, there was no intention to mark-up text in programlisting 
elements! :)

After splitting the book I noticed that the programmer's guide had much text 
that was not marked up.
As with marking up the EventSemaphore or MutexSemaphore class I looked around 
those xml files to see
what tags would be used to mark up the text and used it myself short of knowing 
the DocBook tags and
when and where to apply them.

> Similarly, tagging words in the section titles causes the TOC (which is 
> automatically generated)
> to display them accordingly. So, if it were me doing the work, I would only 
> use the tags in the
> paragraphs where they draw the distinction between the prose and the "names" 
> of important things. 

That is exactly what I have been trying to do as it is a *lot* of work to read 
and look through the
text and marking up the text accordingly (this has not been work of a few hours 
but of a few days by
now!). 

Ad TOC: I was under impression, after skimming through the css files, that the 
boldness in TOCs
would be removed, cf. "css/common.css", lines 743-746:

/* no bold in toc */
.toc * {
font-weight: inherit;
}

Thought that the HTML formatting would follow the DocBook rendering, hence 
asking for a means to
remove or at least reducing the boldness in the TOC.

The overhauled version currently applies the mark-up to all the respective 
text, e.g. all class
names in titles get marked up with the "classname" tag. However, they show as 
bold as do literals
like .environment and .local which looks quite distracting for me.

As this boldness in the TOC seems to be quite disturbing my original question 
about a possibility to
remove/reduce the boldness from/in the TOC.

Text that denotes classnames, literals and such IMHO should be distinguishable 
in its type from
regular text in titles as well. One way to achieve that - which I know now - 
would be to mark-up
such text with the methodname tag, which gets formatted to monospaced-normal 
according to the
Conventions explanation.

Would that be something everyone could agree upon in theory?

If so I would change that title markup accordingly to render a new version of 
rexxpg for assessment
and comparison to finally decide upon it. (I just would like to save me the 
work if everyone thinks
it is not worth to test.)

> Again, just my opinion. Our documents have always only used the three types 
> of typographic
> conventions described in the the Preface of each book. Deviating from that 
> "standard" needs a
> whole lot more discussion and consideration IMHO.

I agree.

While analyzing and overhauling the markup in the past days I created a "test" 
book that includes
the markup that the ooRexx books use, which are by far not all the elements 
that DocBook defines as
I have found out (cf. ).

The directory "oorexx/en_US" seems to have all the files from some DocBook 
distribution. Its
Conventions.xml demonstrates many more elements, such that I have included them 
in the
aforementioned "test" book just to see - after formatting the test book - which 
elements render how
and whether there are elements that we do not use but might be useful.

There could be much more said after all that work and research, but maybe at 
another occasion.

After almost finishing the overhaul, there is another markup that may need 
agreement: marking up
keywords (and subkeywords) and directives. I have applied the methodname tag 
(monospaced-normal) for
them, short of better matching tag names, thinking that they ought to be set 
the same as method names.

Please take a look at that and please give feedback ASAP whether that is o.k.?

If it is o.k. the "Document Conventions" need to be changed accordingly as well.

>
> On 3/20/2020 9:15 AM, Rony G. Flatscher wrote:
>> On 19.03.2020 14:31, Gil Barmwater wrote:
>>> Having spent some time looking at the documentation while developing the 
>>> system to build the
>>> books, I found that we actually have a set of conventions on how things are 
>>> displayed. This is
>>> part of every document, under the title "Typographic Conventions", right 
>>> near the beginning of the
>>> book. So this proposal seems rather extreme to me as it could have a major 
>>> impact on all our
>>

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Erich Steinböck]

Rony,
I agree with Gil.  Let's stay with our current coding/tagging style and the
typographic conventions.

Also, rgf_util2.rex is unacceptable for inclusion in our svn.  Please fix
the copyright or remove it from the svn, and please also do so for any
other of your current or future commits.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Gil Barmwater]

Hi Rony,

I finally have had an opportunity to look into this issue. I downloaded 
your version of rexxpg and opened it next to the one that comes with the 
ooRexx build which is "pre-split" so it has none of the changes that you 
have made. One thing I noticed was that you have added tags "inside" the 
examples which I had not seen before. My understanding of the 
 tag was that it was supposed to show code examples or 
snippets "as-is" with the possible exception of syntax highlighting, a 
separate issue. Now, as you have demonstrated, you CAN "tag" parts of a 
 or  section but I don't see the benefit of doing 
so. Similarly, tagging words in the section titles causes the TOC (which 
is automatically generated) to display them accordingly. So, if it were 
me doing the work, I would only use the tags in the paragraphs where 
they draw the distinction between the prose and the "names" of important 
things. Again, just my opinion. Our documents have always only used the 
three types of typographic conventions described in the the Preface of 
each book. Deviating from that "standard" needs a whole lot more 
discussion and consideration IMHO.


Gil

On 3/20/2020 9:15 AM, Rony G. Flatscher wrote:

On 19.03.2020 14:31, Gil Barmwater wrote:

Having spent some time looking at the documentation while developing the system 
to build the
books, I found that we actually have a set of conventions on how things are 
displayed. This is
part of every document, under the title "Typographic Conventions", right near 
the beginning of the
book. So this proposal seems rather extreme to me as it could have a major 
impact on all our
documents. Just my opinion.


Gil, of course there is no intention to have any negative impact on the 
documentation!

The current boldness is quite strong and looking at the rexxpg book (also in 
the TOC!) the bolded,
monotype text stands out prominently. Hence wondering whether removing the 
boldness (but leaving it)
to semi-bold would be possible at all. And if it was possible it still needs to 
be assessed whether
it negatively impacts the overall look-and feel of the books.

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
Gil Barmwater



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Rony G. Flatscher]

On 20.03.2020 14:23, René Jansen wrote:
> just want to correct one terminology issue: a monotype font is a font from a 
> specific foundry, a monospaced (or non-proportional) font is what you mean.

Ah, yes, thank you René, also: 
.

---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[René Jansen]

just want to correct one terminology issue: a monotype font is a font from a 
specific foundry, a monospaced (or non-proportional) font is what you mean.

> On 20 Mar 2020, at 14:15, Rony G. Flatscher  wrote:
> 
> On 19.03.2020 14:31, Gil Barmwater wrote:
>> 
>> Having spent some time looking at the documentation while developing the 
>> system to build the
>> books, I found that we actually have a set of conventions on how things are 
>> displayed. This is
>> part of every document, under the title "Typographic Conventions", right 
>> near the beginning of the
>> book. So this proposal seems rather extreme to me as it could have a major 
>> impact on all our
>> documents. Just my opinion.
>> 
> Gil, of course there is no intention to have any negative impact on the 
> documentation!
> 
> The current boldness is quite strong and looking at the rexxpg book (also in 
> the TOC!) the bolded,
> monotype text stands out prominently. Hence wondering whether removing the 
> boldness (but leaving it)
> to semi-bold would be possible at all. And if it was possible it still needs 
> to be assessed whether
> it negatively impacts the overall look-and feel of the books.
> 
> ---rony
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Rony G. Flatscher]

On 19.03.2020 14:31, Gil Barmwater wrote:
>
> Having spent some time looking at the documentation while developing the 
> system to build the
> books, I found that we actually have a set of conventions on how things are 
> displayed. This is
> part of every document, under the title "Typographic Conventions", right near 
> the beginning of the
> book. So this proposal seems rather extreme to me as it could have a major 
> impact on all our
> documents. Just my opinion.
>
Gil, of course there is no intention to have any negative impact on the 
documentation!

The current boldness is quite strong and looking at the rexxpg book (also in 
the TOC!) the bolded,
monotype text stands out prominently. Hence wondering whether removing the 
boldness (but leaving it)
to semi-bold would be possible at all. And if it was possible it still needs to 
be assessed whether
it negatively impacts the overall look-and feel of the books.

---rony




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation: using less bold font for some elements ?

[Gil Barmwater]

Having spent some time looking at the documentation while developing the 
system to build the books, I found that we actually have a set of 
conventions on how things are displayed. This is part of every document, 
under the title "Typographic Conventions", right near the beginning of 
the book. So this proposal seems rather extreme to me as it could have a 
major impact on all our documents. Just my opinion. Gil


On 3/19/2020 6:55 AM, Rony G. Flatscher wrote:


While working on the documentation I learned the following elements 
being typeset in monotype font, however all are using the boldest 
version of the font which in the case of rexxpg makes some elements 
stand out far too strong.


So the question would be whether it was possible to format the 
monotype elements like "code" to not be as bold (maybe semi-bold) or 
alternatively, not being bold at all but italicized instead?


These elements are typeset the same way (monotype and in the boldest 
possible font, it seems):


  * code
  * computeroutput
  * filename
  * literal

Just look up the rexxpg book where the boldness communicates an 
importness above all other text and is distracting (like in the table 
of context).


What do you think?

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


--
Gil Barmwater

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation: using less bold font for some elements ?

[Rony G. Flatscher]

While working on the documentation I learned the following elements being 
typeset in monotype font,
however all are using the boldest version of the font which in the case of 
rexxpg makes some
elements stand out far too strong.

So the question would be whether it was possible to format the monotype 
elements like "code" to not
be as bold (maybe semi-bold) or alternatively, not being bold at all but 
italicized instead?

These elements are typeset the same way (monotype and in the boldest possible 
font, it seems):

  * code
  * computeroutput
  * filename
  * literal

Just look up the rexxpg book where the boldness communicates an importness 
above all other text and
is distracting (like in the table of context).

What do you think?

---rony

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] documentation work in SourceForge Subversion repository

[René Jansen]

Seen the importance of the work on the documentation and its build chain I want 
to propose to have this captured in the ooRexx subversion repository instead of 
sending archives via Dropbox or other means. For this reason Gil, P.O. and Rony 
will be added as committers. (Gil as soon as his SourceForge ID has been made 
known).

Please try to cooperate as much as possible and communicate over the list first 
for major changes. In this case, to make the publications toolchain work again, 
and to add missing parts of the documentation, there is not much doubt about 
the necessity of the changes. In other cases, please use caution in every 
action (although we can revert any mishap) and make sure changes build on all 
supported platforms, for example by observing the Jenkins build machine closely 
after a change. Please observe that Rick and Erich have the final say in 
architecture issues regarding ooRexx and limit contributions to the 
documentation part at first.

best regards,

René.



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[Michael Lueck]

Greetings Ruurd,

Ruurd J. Idenburg wrote:
> There is a readme also explaining how to install on your own
> machine/webserver


I would think that the point of configuring a webserver would be to serve up 
the HTML docs.

The old IBM help files were sort of a mix between HTML website and PDF. They 
also were free-standing and not dependent on a client/server configuration.

One could full text search the help file, and a list of relevant help pages 
would pop up. Sort of like being able to access a help website with Google 
having cached the site, entering 
"site:oorexxhelpsite.org keyword" into the Google search bar.

PDF's at least you may full text search... but the PDF is one LONG document, 
not separate short pages.

For now I use the PDF's when I hit a brick wall syntactically that I cannot 
correct without assistance.

Aaaahhh... perhaps package up the PDF documentation into a package, create menu 
item launchers for each PDF. Then I could access the documentation via the 
Linux program menu rather than having to go 
to the download folder and open the correct PDF file.

... Just thinking out loud / brain storming...

I dare say the ooRexx team has no experience building Linux shortcuts within 
Linux packages, correct?

Blessings,

-- 
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[Ruurd J. Idenburg]

Michael,

The following is not exactly what you're asking for, but may be what 
your looking for?

http://www.idenburg.net/ooRexx/4.1.3/

The 4.1.3 is really an early version of the latest release, taken 
somewhere in the 2nd half last year.
The associated readme explains how to install on your own machine/webserver

I also use the following quite often to look for raising errors in my code:

http://www.idenburg.net/ooRexx/ooRexxMsgs/RexxErrorMessages.xml

There is a readme also explaining how to install on your own 
machine/webserver

hth,

Ruurd

Michael Lueck schreef op 25-2-2014 20:38:
> Greetings David,
>
> David Ashley wrote:
>> We can always bring them back if people want that.
>
> Maybe at least for the PDF's. That would save me the hassle of downloading 
> individual PDF's... one download verses many.
>
> On the documentation topic... I do miss the old Windows style help files. Has 
> anyone checked into equivalent book tools for Linux? Is there a help file 
> reader which is consistent among the main
> distros in use? I would probably use such rather than dealing with 
> interpreter error messages until finally I resort to opening the PDF and 
> finding the correct page.
>
> Blessings,
>


--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[Michael Lueck]

Greetings David,

David Ashley wrote:
> We can always bring them back if people want that.


Maybe at least for the PDF's. That would save me the hassle of downloading 
individual PDF's... one download verses many.

On the documentation topic... I do miss the old Windows style help files. Has 
anyone checked into equivalent book tools for Linux? Is there a help file 
reader which is consistent among the main 
distros in use? I would probably use such rather than dealing with interpreter 
error messages until finally I resort to opening the PDF and finding the 
correct page.

Blessings,

-- 
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[David Ashley]

Based on some feedback we have gotten in the past it appears that
individual files are preferred over a collection. So we dropped the zip
files. We can always bring them back if people want that.

David Ashley

On Tue, 2014-02-25 at 13:50 -0500, Michael Lueck wrote:
> David Ashley wrote:
> > http://sourceforge.net/projects/oorexx/files/oorexx-docs/4.2.0/
> 
> 
> Is there no longer a single zip file containing the various documents? In the 
> past I recalled a HTML zip, a PDF zip, and an ALL zip. I did not find in the 
> 4.2.0 directory what I remember downloading 
> before.
> 
> Blessings,
> 



--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[Michael Lueck]

David Ashley wrote:
> http://sourceforge.net/projects/oorexx/files/oorexx-docs/4.2.0/


Is there no longer a single zip file containing the various documents? In the 
past I recalled a HTML zip, a PDF zip, and an ALL zip. I did not find in the 
4.2.0 directory what I remember downloading 
before.

Blessings,

-- 
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation

[David Ashley]

http://sourceforge.net/projects/oorexx/files/oorexx-docs/4.2.0/

David Ashley

On Tue, 2014-02-25 at 07:47 +, r...@ntlworld.com wrote:
> Is there somewhere I can download the documentation in HTML format from?
> 
> --
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel



--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation

[rvm]

Is there somewhere I can download the documentation in HTML format from?

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Documentation (ooDialog to be specific)

[Rick McGuire]

On Wed, Feb 4, 2009 at 5:49 PM, Mark Miesfeld  wrote:
> All,
>
> While documenting changes I had previously implemented in ooDialog, I
> found that either:
>
> The change had been made before the new APIs were available and a
> better implementation could be done with the new APIs.
>
> or
>
> My first pass at using the new API wasn't quite what I wanted.
>
> In both cases this lead me to rework the code before documenting the
> code the way it was locked me into something I wasn't happy with.
>
> Now I'm at the point where I just about have the documentation caught
> up, except for 3 new class areas: Menus, DateTimePicker, and
> MonthCalendar.  Without even looking at that code, I know I want to
> redo it using the new APIs.
>
> Since that will take me a substantial amount of time, I'm thinking
> that these 3 class areas should be left out of this release. (The idea
> actually came from Jon.)
>
> 1.) Does that meet with everyone's approval?

Seems reasonable to me.

>
> 2.) Does anyone think it is sufficient to make sure nothing in these 3
> areas is in the documentation, or should I also back out the code
> itself?  I would like to say, anyone that uses undocumented code does
> so at there own risk. And leave the code in.  But, I'm not sure that
> is reasonable.  Well, I'm sure it is reasonable to me, I'm just not
> sure what others think. 

How hard is the backout process?  If difficult, perhaps you could just
remove the classes from the
.cls files so they're not usable.

If that turns out to be a big effort, I have the same attitude you do
about "use undocumented stuff at your own risk".

Rick

>
> --
> Mark Miesfeld
>
> --
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Documentation (ooDialog to be specific)

[Mark Miesfeld]

All,

While documenting changes I had previously implemented in ooDialog, I
found that either:

The change had been made before the new APIs were available and a
better implementation could be done with the new APIs.

or

My first pass at using the new API wasn't quite what I wanted.

In both cases this lead me to rework the code before documenting the
code the way it was locked me into something I wasn't happy with.

Now I'm at the point where I just about have the documentation caught
up, except for 3 new class areas: Menus, DateTimePicker, and
MonthCalendar.  Without even looking at that code, I know I want to
redo it using the new APIs.

Since that will take me a substantial amount of time, I'm thinking
that these 3 class areas should be left out of this release. (The idea
actually came from Jon.)

1.) Does that meet with everyone's approval?

2.) Does anyone think it is sufficient to make sure nothing in these 3
areas is in the documentation, or should I also back out the code
itself?  I would like to say, anyone that uses undocumented code does
so at there own risk. And leave the code in.  But, I'm not sure that
is reasonable.  Well, I'm sure it is reasonable to me, I'm just not
sure what others think. 

--
Mark Miesfeld

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel