TeX4ht with make4ht ended up being the best option I could find for converting the MATPOWER User's Manual to HTML:
https://tug.org/tex4ht/ I remember trying something based on MathJax or KaTeX, but the page load times were too slow. Having all of the symbols converted into hundreds of SVGs helped, but it doesn't look as good. This was all before I realized that I could just hyperlink to specific sections of the PDF. I didn't want to throw away what I'd done so I just added the option to switch between HTML and PDF or remove the links altogether. Richard On Wed, 2 Nov 2022 at 16:00, Ray Daniel Zimmerman <r...@cornell.edu> wrote: > Thanks, Richard. > > Btw, I’m still impressed with https://matpower.app and the technology > that make it possible. > > By the way, I notice you also have an HTML version of the MATPOWER User’s > Manual on your site. Just wondering what you used to convert the LaTeX to > HTML? FWIW, I’m moving future versions of the manual(s) to use Sphinx > <https://www.sphinx-doc.org/>, so I can generate both HTML and PDF (via > LaTeX) from the same source. > > Ray > > > On Nov 1, 2022, at 4:39 AM, Richard Lincoln <r.w.linc...@gmail.com> wrote: > > Until recently I was stuck with GNU Octave 4.4 when compiling to > WebAssembly for https://matpower.app. However, I can now compile Octave > 7.2 with the latest version of Emscripten (3.1.24). I typically use Ubuntu > 20.04 LTS (focal) for development and Docker base images. It comes with > Octave 5.2. However, the latest LTS release is 22.04 (jammy) and it comes > with Octave 6.4: > > > https://packages.ubuntu.com/search?keywords=octave&searchon=names&suite=all§ion=all > > I my experience, Octave is very stable and there are many options > available (snaps, flatpak, PPAs) for installing the latest version. I vote > *A*, requiring Octave 6.2 or later. > > The MATLAB language has a particularly terse syntax. Other than perhaps > Perl, I can't think of a popular language that allows so much to be > expressed with so few characters. For this reason I think mp should be > the package name and vote *C*. The only naming conflicts that come to > mind might be something related to OpenMP or message passing or multiple > precision arithmetic. > > Richard > > On Mon, 31 Oct 2022 at 23:59, Ray Daniel Zimmerman <r...@cornell.edu> > wrote: > >> Hi MATPOWER Developers, >> >> I need your feedback on a quick question. >> >> I’m working on finalizing things for a beta release of what amounts to a >> nearly complete re-write of MATPOWER for version 8.0. More on that soon. >> >> Since this new version defines tons of new classes, I thought it would be >> nice to put them all inside a package, probably named mp or matpower, to >> avoid namespace pollution. For those who don’t know, a package is simply a >> folder whose name begins with a ‘+’, like ‘+mp’. If that folder is in >> your path, any class inside it, such as myclass.m can be accessed as >> mp.myclass. >> >> The issue is that, for Octave users, putting the new MATPOWER classes >> inside a package will require Octave 6.2.0 (released Feb 2021) or later, >> otherwise we could support Octave 5.2.0 (released Jan 2020) or later. >> >> *So the question for you MATPOWER/Octave users is …* >> >> *What is your preference?* >> A. Require Octave 6.2.0 or later and put the new classes in its own >> package. *OR* >> B. Support Octave 5.2.0 and leave all of the new classes in the main >> namespace. >> >> *And a secondary question, for anyone who has an opinion, is …* >> >> *Which is the better name for the package, should we choose to go that >> route?* >> C. mp - short and convenient to use *OR* >> D. matpower - longer, but better at avoiding name collisions >> >> This is a major update with massive changes and my goal is to introduce a >> framework that will provide a solid foundation for MATPOWER development for >> years/decades to come. >> >> Any feedback or comments are appreciated. Oh, and I’ll probably post this >> to the MATPOWER-L discussion group too, just to get a response from a >> larger audience if possible. So sorry for the duplicates for those on both >> lists. >> >> Thanks, >> >> Ray >> >> >
