<div dir="ltr">Hi Paul and others, <div><br></div><div><div>> We may need, whatever option is followed, some sort of "safe" server, as all</div><div>> too often for commercial or other reasons, public "free" hosting options are </div><div>> withdrawn often with little or no warning. May be in this case the situation is safer?<br></div><div>That is a reasonable concern. I think that the risk is reduced, as open tools are being used</div><div>and it should be possible to replace them if required.</div><div>I also note that bookdown can be hosted outside of the <a href="http://github.com">github.com</a> environment, eg. on gitlab</div><div>which is described here:</div><div><a href="https://rlesur.gitlab.io/bookdown-gitlab-pages/">https://rlesur.gitlab.io/bookdown-gitlab-pages/</a><br></div><div><br></div><div>Thanks, </div><div>Henrik</div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 30 Apr 2021 at 09:40, Paul A Norman <<a href="mailto:paul.a.norman@gmail.com">paul.a.norman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks Henrik,</div><div><br></div><div>That is certainly very helpful.</div><div><br></div><div style="margin-left:40px">
<div>"A nice example is the bookdown R package, that makes it easy to suggest a change to a book through a github pull request.</div><div>You can see it in action here —<br></div><div><a href="https://bookdown.org/yihui/bookdown/" target="_blank">https://bookdown.org/yihui/bookdown/</a></div>

</div><div><br></div><div>I know that other LaTeX documentation is produced through intermediary formats, and this one is looking like a good approach.<br></div><div><br></div><div>We may need, whatever option is followed, some sort of "safe" server, as all too often for commercial or other reasons, public "free" hosting options are withdrawn often with little or no warning. May be in this case the situation is safer?<br></div><div><br></div><div>I am quite happy to just dive into any realistic option, and MarkDown as provided up by <i>Bookdown</i> is looking like a very viable option indeed. <br></div><div><br></div><div>I am looking into HTML: to core MD converters, to get our main TWscript API out from present and reusable as a foundation, the present help producer we are using HelpNDoc V7.2.0.306 - March 23, 2021 has an export to MD which I would check out <br>-- but for now I'm holding off for now in case anyone else has any thoughts on all of this?</div><div><br></div><div>Thanks again for the contribution Henrik much appreciated.</div><div><br></div><div>Paul<br></div><div>.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Apr 2021 at 18:34, Henrik Skov Midtiby <<a href="mailto:henrikmidtiby@gmail.com" target="_blank">henrikmidtiby@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dear Paul, <div><br></div><div><div>> Whatever, it would be nice that a wider range of people can feel comfortable</div><div>> to contribute over the years ahead, and that we have an accessible platform for that.</div></div><div>I completely agree. The easier it is to contribute the better.</div><div><br></div><div>A nice example is the bookdown R package, that makes it easy to suggest a change to a book through a github pull request.</div><div>You can see it in action here</div><div><a href="https://bookdown.org/yihui/bookdown/" target="_blank">https://bookdown.org/yihui/bookdown/</a><br></div><div><br></div><div>To suggest a change, click the "Edit" button in the top left corner.</div><div>Then an online editor will be opened with the current document, here you can make the change and send it in.</div><div>Behind the scenes, github will fork the project and send a pull request to the maintainer.</div><div><br></div><div>Best regards, </div><div>Henrik Skov Midtiby</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Apr 2021 at 13:51, Paul A Norman <<a href="mailto:paul.a.norman@gmail.com" target="_blank">paul.a.norman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div dir="ltr"><div>Thank you Dunncan,</div><div><br></div><div>Yes the Markup / Pandoc approach is really good.<br></div><div>And there are a number of Markup dialects available, quite a few in fact.<br><br></div><div>In FreePascal – Lazarus I am presently using </div><div><br></div>
"<b>Markdown Processor for FPC</b>" (license Apache 2.0) <br><div><div style="margin-left:40px">
<a href="https://github.com/mriscoc/fpc-markdown" target="_blank">https://github.com/mriscoc/fpc-markdown</a>

</div><div style="margin-left:40px"><br></div><div style="margin-left:40px">"This is a Pascal (FPC) library that processes markdown to HTML.<br>At present the following dialects of markdown are supported:<br><br>* The Daring Fireball dialect<br> (see <<a href="https://daringfireball.net/projects/markdown/" target="_blank">https://daringfireball.net/projects/markdown/</a>>)<br><br>* Enhanced TxtMark dialect<br> (translated from <<a href="https://github.com/rjeschke/txtmark" target="_blank">https://github.com/rjeschke/txtmark</a>>)<br><br>* Almost complete support for CommonMark dialect<br> (translated from <<a href="http://commonmark.org/" target="_blank">http://commonmark.org/</a>>)<br><br>(Wishlist: PEGDown - Github dialect).<br></div><div><br></div><div>I have found that there has been a warm response to there being a CHM available,<br></div><div>ironic considering this is a *TeX editor and perhaps often used for making pdfs.</div><div><br></div><div>So far, I can't find a smooth simple path from say (lua)pdfLaTeX to CHM.</div><div><br></div><div>Of course you can go from html to CHM, but HelpNDoc might have made me lazy on this as it does it all out of the box.</div><div><br></div><div>For full out of the box pdf to HTML5 support I have worked with <br></div><div style="margin-left:40px">
</div><h2><font size="2">pdf2htmlEX</font></h2><div style="margin-left:40px">

<p>
<a href="http://coolwanglu.github.io/pdf2htmlEX/" target="_blank">http://coolwanglu.github.io/pdf2htmlEX/</a> <br></p><p>pdf2htmlEX renders PDF files in HTML, utilizing modern Web 
technologies, <br>aims to provide an accuracy rendering, while keeping 
optimized for Web display.
<br>Text, fonts and formats are natively preserved in HTML, math formulas, 
figures and images are also supported.</p>

<p>pdf2htmlEX is also a publishing tool, almost 50 options make it 
flexible for many different use cases: <br>PDF preview, book/magazine 
publishing, personal resume..</p></div><div>But of course that is less than half of the road to a CHM, <br>but makes picture perfect representations of the pdf in HTML <br>and so is another way of producing beautiful *(La)TeX through to html..</div><div><br></div><div>Or perhaps a closely controlled series of LaTeX packages that lend themselves to HTML out put as well as pdf?</div><div><br></div><div>Whatever, it would be nice that a wider range of people can feel comfortable to contribute over the years ahead,<br></div><div>and that we have an accessible platform for that.</div><div><br></div><div>Having said that CHM has been popular in the past, I've just looked at the statistics for the downloads off the web site <br>and they show that over 70% of the finished document downloads, by what appear to possibly be real people (not robots), <br></div><div>have been of the .pdf since January this year. Then the .doc version comes in (minor though) well ahead of the chm.<br>more than the .doc version.<br></div><div><br></div><div>So although (just) personally I still like CHMs :-)  maybe we could move to a just .pdf. / html output?<br><br></div><div>Kind regards,</div><div>Paul<div><div id="gmail-m_4915151178588745647gmail-m_-4650726067239467929gmail-m_5812332431833520543gmail-:wx"><img src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><div><br></div></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Apr 2021 at 21:52, Duncan Murdoch <<a href="mailto:murdoch.duncan@gmail.com" target="_blank">murdoch.duncan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/04/2021 2:44 a.m., Paul A Norman wrote:<br>
> Hi all,<br>
> <br>
> Stefan And I have had intermittent discussions via direct email on <br>
> updating/ upgrading the TeXworks Scripting help files.<br>
> <br>
> I just wanted to inquire if any one generally has thoughts on a good <br>
> system to produce those on  *Tex related or absolutely anything else at <br>
> all really.<br>
<br>
There's a lot of support nowadays for Markdown variations for input, <br>
with Pandoc involved in conversions to lots of output formats.  TeXworks <br>
is unusual in that most people who'd be writing docs are likely to be <br>
familiar with TeX/LaTeX input, but if you're willing to give up the <br>
semantic markup, Markdown is definitely a lot easier to write.<br>
<br>
I was involved in development of the R help system, which uses a really <br>
quite painful LaTeX-like language for input.  (TeX isn't involved, it <br>
has its own parser, and is substantially different from actual LaTeX.)<br>
Several years ago a preprocessor was written that uses Markdown input <br>
instead, and it's very popular.<br>
<br>
Duncan Murdoch<br>
<br>
> <br>
> At present HelpNDoc is used, years ago they kindly gave us permission as <br>
> an OpenSource not for profit project, to use their help system <br>
> production application.<br>
> <br>
> It produces html, chm, and a pdf file.<br>
> <br>
> I have been thinking to remove all extraneous material and focus upon <br>
> the TeXworks scripting API particualrly, with perhaps some general <br>
> information on how to incorporate shims for the JavaScript side to help <br>
> people use the more advanced feature of modern JavaScript,<br>
> <br>
> Thinking that as the underlying Qt engine is not going to be updated by <br>
> QT for ever more frequent releases of  general JavaScript, this would <br>
> give an effective ability to maintain progress with EMCA's progress <br>
> indirectly through shims.<br>
> <br>
> Truly I personally am committed to no particular course of action and <br>
> open to any ideas going forward.<br>
> Other than thinking: it would be good to open it up, so that others can <br>
> contribute material on a public platform.<br>
> I've just not yet been convinced by the documentation capability sides <br>
> of Git and like operations etc<br>
> <br>
> Current material ...<br>
> <br>
> <a href="https://twscript.paulanorman.com/docs/index.html" rel="noreferrer" target="_blank">https://twscript.paulanorman.com/docs/index.html</a> <br>
> <<a href="https://twscript.paulanorman.com/docs/index.html" rel="noreferrer" target="_blank">https://twscript.paulanorman.com/docs/index.html</a>><br>
> <br>
> Any way any suggestions appreciated please :-)<br>
> <br>
> Thanks,<br>
> Paul<br>
> <br>
> <br>
> </blockquote></div></div></div>

</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Apr 2021 at 18:44, Paul A Norman <<a href="mailto:paul.a.norman@gmail.com" target="_blank">paul.a.norman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Stefan And I have had intermittent discussions via direct email on updating/ upgrading the TeXworks Scripting help files.</div><div><br></div><div>I just wanted to inquire if any one generally has thoughts on a good system to produce those on  *Tex related or absolutely anything else at all really.</div><div><br></div><div>At present HelpNDoc is used, years ago they kindly gave us permission as an OpenSource not for profit project, to use their help system production application.</div><div><br></div><div>It produces html, chm, and a pdf file.</div><div><br></div><div>I have been thinking to remove all extraneous material and focus upon the TeXworks scripting API particualrly, with perhaps some general information on how to incorporate shims for the JavaScript side to help people use the more advanced feature of modern JavaScript,</div><div><br></div><div>Thinking that as the underlying Qt engine is not going to be updated by QT for ever more frequent releases of  general JavaScript, this would give an effective ability to maintain progress with EMCA's progress indirectly through shims.<br></div><div><br></div><div>Truly I personally am committed to no particular course of action and open to any ideas going forward.</div><div>Other than thinking: it would be good to open it up, so that others can contribute material on a public platform. <br></div><div>I've just not yet been convinced by the documentation capability sides of Git and like operations etc</div><div><br></div><div>Current material ...</div><div><br></div><div style="margin-left:40px"><a href="https://twscript.paulanorman.com/docs/index.html" target="_blank">https://twscript.paulanorman.com/docs/index.html</a></div><div><br></div><div>Any way any suggestions appreciated please :-)</div><div><br></div><div>Thanks,</div><div>Paul<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>