Anyone in need of a cross-platform StrongHelp viewer?

In my ongoing quest of reinventing the wheel, I did one of my “let’s see how far I get in a day” projects. Don’t ask why, I don’t even know how the idea started.

So I now have a rudimentary collection of Java classes (i.e. cross-platform as in “runs everywhere but not on RISC OS”) that allows you to

• read a StrongHelp file
• parse its inner structure into an object tree (files, dirs)
• convert StrongHelp data into HTML (which is of the HTML-not-exactly-3.2-that-Java-Swing-supports type)
• view that HTML in a Java Swing UI

Here’s a screenshot of the debug view, with 3 tabs for the HTML view, the HTML source and the StrongHelp source:

If you have ever researched that topic, you probably know that there are already two solutions for the problem “I want to view StrongHelp files on other platforms”:

• Vincent Sanders’ stronghelp-cgi: https://github.com/kyllikki/stronghelp-cgi
• Rick Murray’s StrawHelp: https://heyrick.eu/software/strawhelp/

My solution has the additional disadvantage of being even more incomplete, sporting a handwritten parser by someone who failed regularly in implementing them (i.e. me), with a TODO list that is probably longer than the lines of code of the whole project, including but not limited to:

• support all page commands (at the moment, mostly selected F commands, font styles and alignment, the rest is missing)
• external help linking
• a sensible UI to present a directory of help files
• support Sprite and Draw and Squashed files
• support TABs and Tables and Indentation
• support faked unordered lists
• support the !Configure stuff

As I am very good at starting such projects, but seldomly finish them, I ask here…does anyone have a usecase for such a utility? I could drop the code onto GitHub if anyone is interested.

Rick Murray’s StrawHelp: https://heyrick.eu/software/strawhelp/

Except it appears that the server hosting my site has decided that it wanted Friday off… ?

Let’s hope its just “something crashed” and not “done an OVH”! ;-)

BTW, StrawHelp uses the MSIE webview control. Does that even exist any more?

BTW, StrawHelp uses the MSIE webview control. Does that even exist any more?

A bunch of VisualBasic sourcecode, with some “interesting” external dependencies, and all you worry is about the HTML display :-)

I am sure that fancy .NET stuff will have a nice shiny Edge-based Chromium-inside WebView component.

and not “done an OVH”!

Well, it’s not on fire, but…

https://portal.freethought.uk/serverstatus.php

Well, it’s not on fire, but… https://portal.freethought.uk/serverstatus.php

Nearly one day of downtime…hopefully they don’t provide the usual 99.9% availability guarantee to their customers, or it could get expensive for them.

StrongHelp would be handy to use on a smartphone – Is there a way or running BASIC Progs on a smartphone?

Nearly one day of downtime…

What I’d like to know is how did a drive failure in a RAID trash the entire thing? Isn’t RAID supposed to stop that from happening?
[assuming they’re doing it correctly with redundancy]

StrongHelp would be handy to use on a smartphone

That’s what I was thinking when I noticed Steffen said it was written in Java. That’s halfway to an Android app, isn’t it?
I’ll add a +1, a little StrongHelp app would be useful. Plus, being Android, it can be sideloaded if the author doesn’t want the hassles of getting it into Play (the store).

Isn’t RAID supposed to stop that from happening?

RAID covers a range of options, from mirroring (100% redundancy) to JBOD (0% redundancy). In the middle are a number of configurations, such as striping with parity, so for example 5 discs where 4 carry the data and the 5th parity data. This can tolerate the loss of any one disc. Where it becomes problematic is if you don’t notice the loss of one disc. The second failure results in total loss of data.

JBOD covers a range too. One is what used to be called a volume set, where once one disc is full, data continues on the second. A failure here loses some, but not all data. Another version is a stripeset, where every file is essentially spread across all discs. A single disc failure here loses everything. It’s done for performance, because the load when reading and writing is spread across spindles.

That’s why when I recently bought a NAS I bought an unpopulated one and two discs. It wasn’t clear in the advertising whether a “4TB NAS” has 2 × 2TB discs as a JBOD, or 2 × 4TB discs mirrored. I set up the latter, or rather the NAS did all by itself as it was the default option. I then enabled email notifications, so I will get told of problems.

That’s what I was thinking when I noticed Steffen said it was written in Java. That’s halfway to an Android app, isn’t it?

Depends on the Java Runtime that Android uses/provides, of which I know nothing. When I last wanted to look into Android, the then-current version was 2.3.

It’s not that the Java SE runtime is used extensively by my code – I do such projects mostly “bare-bone” to be able to convert it into any different programming language should the need arise.

I’ll add a +1, a little StrongHelp app would be useful. Plus, being Android, it can be sideloaded if the author doesn’t want the hassles of getting it into Play (the store).

In this day and age of “always on”, it would probably be easier to set up a Java Application Server somewhere that just serves the converted HTML pages. Or even just a webserver using Vincent Sanders’ stronghelp-cgi. The limitations he has documented are very similar to those of my implementation, although I currently work to resolve the “Squash” and “Sprite” limitations.

Could someone build and try Vincent’s cgi solution? This should be even possible with WebJames I guess – if you can get Vincent’s code to compile on RISC OS of course.

Well, it’s not on fire, but…

There’s a holding page now ¹ that says sites will be restored in order to popularity. I guess I’m way down that list. :-)

¹ Only http works at the moment, if your browser tries https first, it’ll fail.

I guess I’m way down that list. :-)

It’s OK Rick, we still love you :)

Being motivated by the dim and distant future possibility of having this StrongHelpViewer as an Android app, I have done a bit of more work today on that project:

• external links (URLs) now supported
• alignment and percentage width for “line” now work
• more font and style support, including the “simple” syntax for bold/italic/underline
• all character escaping and entity replacement now done correctly (hopefully!)
• simple lists now supported
• fake TABs with HTML tables (not complete yet, but good enough for the Assembler manual)

The most important thing missing for good visual representation is the support for the table command. E.g. the OS manual uses that extensively. But this also needs support for the prefix/postfix commands, which is also not there yet.

Has someone ever produced an “example manual” with all the features? Tiled sprites as a page background – not seen that anywhere…

“table” support hacked in (would have needed some parser reworking, but I decided to ruin maintainability instead), as well as prefix/postfix, so that the OS manual more-or-less works now.

Next on the list: “Include” and “Subpage”. And I am not sure how to implement the Tab semantics (which is a table in my created HTML) specified in the ref manual: “Paragraphs without TAB’s in them will not be influenced.”. I’ll have to experiment with StrongHelp to see what it really does. Maybe a column span, but this would need knowledge of the full result table to even know the number of columns. And we hear the concept of the single-pass top-down no-backtracking parser dying…or not? Too tired now, and the switch to DST is approaching fast.

And we hear the concept of the single-pass top-down no-backtracking parser dying…or not?

Like many before, I have been down that road and turned back.

My attempt to convert StrongHelp to HTML, Shinto, was in BASIC, but never completed.

There are vestiges of the output at:

This has tables, include, subpages and prefix.

Edit: Actually, I think it was the BASIC string length that really stopped me. That was before I developed a good way to overcome that.

Actually, I think it was the BASIC string length that really stopped me. That was before I developed a good way to overcome that.

So, you developed a fix for a stumbling block but forgot about one of the items you’d encountered the stumbling block on?

Been there. All those bits you never quite get back to.
There’s some stuff needs doing at work. Probably take about 10-15 minutes to implement and about 4-5 weeks¹ to plan/document to a level that will get approved.

¹ Assuming no interruptions or diversions into JFDI jobs.

You could always try BBC BASIC for Windows, which has removed the 256 byte string length limitation.

My attempt to convert StrongHelp to HTML, Shinto, was in BASIC, but never completed.

Thanks for the example. Interesting approach for the “everything is a table” technique that I also thought about, probably relying on the browser to fix up the “illegal colspan” you have used (side note: is 99 really enough :-)). Or is this actually documented? The HTML3.2 standard I am currently looking at does not mention what happens, so probably “implementation defined”.

Firefox seems to get confused about the “table inside unordered list without list items” approach, rendering a strange character for a bullet.

You could always try BBC BASIC for Windows, which has removed the 256 byte string length limitation.

In general yes, but for a StrongHelp-to-HTML converter it is a lot easier to run on RISC OS, because it saves you from interpreting the actual image structure and makes it easier to convert squashed content, sprites and drawfiles.

Interesting approach for the “everything is a table” technique

All SH pages start with an implicit #tab so it seemed logical.

a strange character for a bullet

Indeed. It was one of the many problems still to be fixed.

All SH pages start with an implicit #tab so it seemed logical.

I thought the same, but a bit too late :-)

Somehow, it feels very wrong to use a “one column table” for pages that don’t have any tab characters inside. Maybe this could be checked at the preprocessing step when handling the global sysvar replacement and the #Include command.

On the other hand, I guess the only chance to implement #Indent is also via tables, so scanning for tabs might not be sufficient. Maybe fake Indent with blockquote? Are nested blockquotes supported in browsers?

And what happens to a tab in a #table line? When reading the StrongHelp Reference Manual, all kind of weird border cases come to my mind…and what exactly is the meaning of "one should be careful with “{}” commands" when dealing with the #table command…

it feels very wrong to use a “one column table” for pages that don’t have any tab characters inside

Yes, but KISS. ;-)

I tried to get inside Guttorm’s head and elucidate the structure he had in mind. I did look at the source, and despite its complication it is relatively easy to follow for assembler.

what happens to a tab in a #table line?

Lots of ??? IIRC. But that should show up in the manual before it is converted.

one should be careful with “{}” commands" when dealing with the #table command

Likewise, I think. You cannot change fonts inside a table I have found.

Note that it is 9 years since I touched this and my code was specifically oriented to the way I write my manuals.

Okay, I’m back. Whee! But mobile view is broken and there are no pictures, because the new server is running php 7 and php is notoriously crap at backwards compatibility.
I’m not yet able to log into the server. When that part is working, I’ll fiddle around with the script to see what it is sulking about. The pictures I know, if you view source in Firefox, you’ll see it whinging about eregi which has been replaced by something else. Should be a few dumb things like that to fix up…

Still, the words are there (good help you if you choose to read them), we’re just missing the pretty pictures. :-)

I tried to get inside Guttorm’s head and elucidate the structure he had in mind.

In its way, it is more flexible than what originally was HTML. Easy to write, and quite nicely suited for the job at hand.

It’s just that some things don’t really lend themselves to being converted to HTML, such as tabbed tables. It’s something I fudged/skipped when writing StrawHelp.

Hmm, did I ever publish the source to that? It’s VB5, if anybody is interested. Just a basic “translate this into HTML” with some hacks for various special cases. If I remember correctly, the prefix thing could be a little interesting when it came to working out what the user wanted when they clicked a link.

Edit: yes, I did, it’s EUPL… http://heyrick.eu/software/strawhelp/download.html

Are nested blockquotes supported in browsers?

I seem to remember having seen them demonstrated on this forum in NetSurf.

Like many before, I have been down that road and turned back.

I have been looking back at my files. One thing I have is an Obey file to convert using SHtoHTML, which was once in the Utilities directory in StrongHelp and was one of Chris Morrison’s, I think. It is not there now and I cannot find it.

it was the BASIC string length that really stopped me.

I find that I did go on to change Shinto to use Basalt after I developed the long strings, but I cannot remember if it all worked as well. Is it worth trying to pull it all together again? It is quite nicely structured. ;-)