[texworks] Help files for Scripting

[Henrik Skov Midtiby]

Hi Paul and others,

> 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?
That is a reasonable concern. I think that the risk is reduced, as open
tools are being used
and it should be possible to replace them if required.
I also note that bookdown can be hosted outside of the github.com
environment, eg. on gitlab
which is described here:
https://rlesur.gitlab.io/bookdown-gitlab-pages/

Thanks,
Henrik



On Fri, 30 Apr 2021 at 09:40, Paul A Norman <paul.a.norman at gmail.com> wrote:

> Thanks Henrik,
>
> That is certainly very helpful.
>
> "A nice example is the bookdown R package, that makes it easy to suggest a
> change to a book through a github pull request.
> You can see it in action here —
> https://bookdown.org/yihui/bookdown/
>
> I know that other LaTeX documentation is produced through intermediary
> formats, and this one is looking like a good approach.
>
> 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?
>
> I am quite happy to just dive into any realistic option, and MarkDown as
> provided up by *Bookdown* is looking like a very viable option indeed.
>
> 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
> -- but for now I'm holding off for now in case anyone else has any
> thoughts on all of this?
>
> Thanks again for the contribution Henrik much appreciated.
>
> Paul
> .
>
> On Wed, 28 Apr 2021 at 18:34, Henrik Skov Midtiby <henrikmidtiby at gmail.com>
> wrote:
>
>> Dear Paul,
>>
>> > Whatever, it would be nice that a wider range of people can feel
>> comfortable
>> > to contribute over the years ahead, and that we have an accessible
>> platform for that.
>> I completely agree. The easier it is to contribute the better.
>>
>> A nice example is the bookdown R package, that makes it easy to suggest a
>> change to a book through a github pull request.
>> You can see it in action here
>> https://bookdown.org/yihui/bookdown/
>>
>> To suggest a change, click the "Edit" button in the top left corner.
>> Then an online editor will be opened with the current document, here you
>> can make the change and send it in.
>> Behind the scenes, github will fork the project and send a pull request
>> to the maintainer.
>>
>> Best regards,
>> Henrik Skov Midtiby
>>
>> On Thu, 22 Apr 2021 at 13:51, Paul A Norman <paul.a.norman at gmail.com>
>> wrote:
>>
>>> Thank you Dunncan,
>>>
>>> Yes the Markup / Pandoc approach is really good.
>>> And there are a number of Markup dialects available, quite a few in fact.
>>>
>>> In FreePascal – Lazarus I am presently using
>>>
>>> "*Markdown Processor for FPC*" (license Apache 2.0)
>>> https://github.com/mriscoc/fpc-markdown
>>>
>>> "This is a Pascal (FPC) library that processes markdown to HTML.
>>> At present the following dialects of markdown are supported:
>>>
>>> * The Daring Fireball dialect
>>>  (see <https://daringfireball.net/projects/markdown/>)
>>>
>>> * Enhanced TxtMark dialect
>>>  (translated from <https://github.com/rjeschke/txtmark>)
>>>
>>> * Almost complete support for CommonMark dialect
>>>  (translated from <http://commonmark.org/>)
>>>
>>> (Wishlist: PEGDown - Github dialect).
>>>
>>> I have found that there has been a warm response to there being a CHM
>>> available,
>>> ironic considering this is a *TeX editor and perhaps often used for
>>> making pdfs.
>>>
>>> So far, I can't find a smooth simple path from say (lua)pdfLaTeX to CHM.
>>>
>>> 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.
>>>
>>> For full out of the box pdf to HTML5 support I have worked with
>>> pdf2htmlEX
>>>
>>> http://coolwanglu.github.io/pdf2htmlEX/
>>>
>>> pdf2htmlEX renders PDF files in HTML, utilizing modern Web technologies,
>>> aims to provide an accuracy rendering, while keeping optimized for Web
>>> display.
>>> Text, fonts and formats are natively preserved in HTML, math formulas,
>>> figures and images are also supported.
>>>
>>> pdf2htmlEX is also a publishing tool, almost 50 options make it flexible
>>> for many different use cases:
>>> PDF preview, book/magazine publishing, personal resume..
>>> But of course that is less than half of the road to a CHM,
>>> but makes picture perfect representations of the pdf in HTML
>>> and so is another way of producing beautiful *(La)TeX through to html..
>>>
>>> Or perhaps a closely controlled series of LaTeX packages that lend
>>> themselves to HTML out put as well as pdf?
>>>
>>> Whatever, it would be nice that a wider range of people can feel
>>> comfortable to contribute over the years ahead,
>>> and that we have an accessible platform for that.
>>>
>>> Having said that CHM has been popular in the past, I've just looked at
>>> the statistics for the downloads off the web site
>>> and they show that over 70% of the finished document downloads, by what
>>> appear to possibly be real people (not robots),
>>> have been of the .pdf since January this year. Then the .doc version
>>> comes in (minor though) well ahead of the chm.
>>> more than the .doc version.
>>>
>>> So although (just) personally I still like CHMs :-)  maybe we could move
>>> to a just .pdf. / html output?
>>>
>>> Kind regards,
>>> Paul
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, 22 Apr 2021 at 21:52, Duncan Murdoch <murdoch.duncan at gmail.com>
>>> wrote:
>>>
>>>> On 22/04/2021 2:44 a.m., Paul A Norman wrote:
>>>> > Hi all,
>>>> >
>>>> > Stefan And I have had intermittent discussions via direct email on
>>>> > updating/ upgrading the TeXworks Scripting help files.
>>>> >
>>>> > 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.
>>>>
>>>> There's a lot of support nowadays for Markdown variations for input,
>>>> with Pandoc involved in conversions to lots of output formats.
>>>> TeXworks
>>>> is unusual in that most people who'd be writing docs are likely to be
>>>> familiar with TeX/LaTeX input, but if you're willing to give up the
>>>> semantic markup, Markdown is definitely a lot easier to write.
>>>>
>>>> I was involved in development of the R help system, which uses a really
>>>> quite painful LaTeX-like language for input.  (TeX isn't involved, it
>>>> has its own parser, and is substantially different from actual LaTeX.)
>>>> Several years ago a preprocessor was written that uses Markdown input
>>>> instead, and it's very popular.
>>>>
>>>> Duncan Murdoch
>>>>
>>>> >
>>>> > 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.
>>>> >
>>>> > It produces html, chm, and a pdf file.
>>>> >
>>>> > 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,
>>>> >
>>>> > 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.
>>>> >
>>>> > Truly I personally am committed to no particular course of action and
>>>> > open to any ideas going forward.
>>>> > Other than thinking: it would be good to open it up, so that others
>>>> can
>>>> > contribute material on a public platform.
>>>> > I've just not yet been convinced by the documentation capability
>>>> sides
>>>> > of Git and like operations etc
>>>> >
>>>> > Current material ...
>>>> >
>>>> > https://twscript.paulanorman.com/docs/index.html
>>>> > <https://twscript.paulanorman.com/docs/index.html>
>>>> >
>>>> > Any way any suggestions appreciated please :-)
>>>> >
>>>> > Thanks,
>>>> > Paul
>>>> >
>>>> >
>>>> >
>>>
>>>
>>> On Thu, 22 Apr 2021 at 18:44, Paul A Norman <paul.a.norman at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Stefan And I have had intermittent discussions via direct email on
>>>> updating/ upgrading the TeXworks Scripting help files.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> It produces html, chm, and a pdf file.
>>>>
>>>> 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,
>>>>
>>>> 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.
>>>>
>>>> Truly I personally am committed to no particular course of action and
>>>> open to any ideas going forward.
>>>> Other than thinking: it would be good to open it up, so that others can
>>>> contribute material on a public platform.
>>>> I've just not yet been convinced by the documentation capability sides
>>>> of Git and like operations etc
>>>>
>>>> Current material ...
>>>>
>>>> https://twscript.paulanorman.com/docs/index.html
>>>>
>>>> Any way any suggestions appreciated please :-)
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texworks/attachments/20210502/1f9e4af9/attachment.html>