Other build formats/targets

[StevenClontz]

For 0.8:

• [x] slides
• [x] epub
• [x] kindle
• [x] braille
• [x] custom (just passes source with custom xsl to xsltproc)

In future:

• pretext build jupyter
• pretext build worksheets
• pretext build solution-manual

[StevenClontz]

Re: @rbeezer in #211

I'm reviewing the documentation, and would like to remove as much xsltproc as I can. Moving all the stringparams to the publication file is one line of attack.

The other would be to have some functionality exposed via the CLI. Rather than spam the issues here with multiple new issues, maybe this can be a meta-issue to track progress?

These are stylesheets which (mostly) are discussed in the Guide and then xsltproc is used to show how to use them. Better the CLI knew how to use them? Some are important (doctesting Sage), some are debatable (author-tools).

xsl/pretext-jupyter.xsl
xsl/pretext-litprog.xsl
xsl/pretext-revealjs.xsl
xsl/pretext-sage-doctest.xsl
xsl/pretext-solution-manual-latex.xsl
xsl/pretext-ww-problem-sets.xsl
utilities/author-report.xsl

[StevenClontz]

At this stage of the CLI's development and adoption as the "official" way to use PreTeXt, I think any new target needs to be tested against both our template book and article, and we should also wire up any relevant sample projects meant to particularly showcase such a build to use the CLI.

[oscarlevin]

We are about an hour and some discussion away from epub and kindle. Maybe braille?

We can push this back to 0.9, unless folks think it would be useful for the second workshop coming up.

[rbeezer]

unless folks think it would be useful for the second workshop coming up.

Proposal writing and the braille conversion should be my priorities for the next 2.5 weeks. So if something nice is packaged up shortly before July 18, that'd be great. But we can certainly use pretext/pretext with most of the developer types who are coming (I think!).

[arechnitzer]

+1 for slides

[oscarlevin]

I think we need to push epub/Kindle/braille back to at least 0.9. we need to either work on core to separate dependencies or think of some other way to be clever.

[StevenClontz]

And I'm pretty slammed, so I'm gonna take a swing at a custom build target (which would enable slide builds indirectly) and call this a version.

[arechnitzer]

Happy to test stuff n things if you'd like.

[StevenClontz]

Pushed in 8707fb8: pretext new slideshow && cd new-pretext-project && pretext view -b builds PreTeXt slides to RevealJs. Rather than implementing special behavior for slides, I took advantage of the fact that the slides conversion is pure XSL, so I implemented support for arbitrary XSL instead.

[oscarlevin]

Epub (and Kindle) now build, using 407b6421f91a26af4ad37f9377dc2d88a8527537.

A few things we need to do:

• [x] Update the "success" message to not suggest that pretext view epub does anything (you can't view the epub through a webserver).
• [ ] Add documentation to the guide
• [x] Decide what to do about the default project.ptx. Should this have an epub target? Or should that just be in the documentation?

[bnmnetp]

It would be nice to have runestone on that list.

I was just having to walk an author through everything yesterday to get her book prepared for academy.

copy the html target and change it to runestone, change the output path, copy the publisher file ... Would be so much nicer if that was already there.

[StevenClontz]

@bnmnetp you're suggesting changing the pretext new book project.ptx to look like https://github.com/PreTeXtBook/pretext-cli/commit/e192b557e25dd167f1edaa06fa9e8e0030e63e11 along with creating an appropriate publication/publication-runestone.ptx file? And I guess follow any other necessary steps at https://pretextbook.org/doc/guide/html/sec-publishing-to-runestone-academy.html so they're already done (or can be easily modified) in a fresh pretext new book?

[bnmnetp]

yes also for pretext init for existing books.

the <output-dir> should be published/document-id where the document-id is defined in the <docinfo>

[oscarlevin]

I have braille implemented, although I don't know if it works since it is tricky to get the external requirements set up nicely.

How about this as a design philosophy for the CLI: we have wrappers for every function that core pretext provides, done through the name of the format element in project.ptx, but put warnings on less common things as "experimental". I think the only additional one we would throw in at this point is webwork (for producing .pg and .def files of the embedded webwork). The idea is that someone who uses the CLI has at least as much access to core pretext features as someone using the pretext/pretext script.

[StevenClontz]

I had a thought the other day that it'd be nice to have pretext core-script ARGS where ARGS is fed directly into the core command line interface. Maybe that's feasible with a subprocess.run and copies of the core Python installed in the user directory. Then folks have full access to all features, but we don't have to be "responsible" for those features.

[StevenClontz]

closing this for now, will re-open core script idea