Re: [PLUG] My Holy Quest for a WYSIWYG HTML Word Processor

[JP Vossen via plug <plug@lists.phillylinux.org>]

We've drifted quite a way from the OP "WYSIWYG HTML Word Processor" question, and I still maintain that FrontPage, DreamWeaver, etc. are the closest answer to *that* question.  (Yes, the HTML is horrible, yes, yes, all the other objections.  But those are neither the question nor the answer.)

We've drifted to something like "how to write 'simple' plain text and render it into complicated formats like HTML or PDF," which omits the WYSIWYG part, renders the choice of editor moot, and is focusing more on process and tool-chain.


On 1/28/23 04:30 AM, Steve Litt via plug wrote:
> > Yeah, Markdown was originally conceived to be easy enough to parse
> > visually and write that you don't really need WYSIWYG. But it's easily
> > rendered to HTML+CSS. So if you need something with more formatting
> > than plain text, but easier to read/write than raw HTML+CSS or
> > XML+XSLT, Markdown hits that sweet spot.
>
> Welllll, sort of. Markdown is easily converted to HTML+CSS, but AFAIK
> *onlY* for the few styles supported by Markdown. However:
>
> 1) You can include HTML within a Markdown document.
> 2) You can make your own tokens which, after conversion to HTML, can be
>     converted to HTML.
>
> IMHO #2 is the real key to productive authoring, if the author is
> willing to live with the insertion of a few tags within his Markdown
> document. I've been trying to make something like this for the better
> part of a decade. When I finally do it, I'm going to do it in Python
> because Python is the language most likely to complete a started
> project. If anyone wants to help me either on the specs or the coding,
> please let me know.

Markdown keeps coming up, I assume mostly because Github has made it the most ubiquitous markup notation.  But I've written two books for O'Reilly in Asciidoc [1], and that is a much more powerful alternative.  Of course, as in anything else in IT, power and flexibility has a cost.  I find the back-end tool-chain much more complex, but I'm also trying to locally come close to what the O'Reilly tool-chain does so I can proof before I commit [2].

Asciidoc, is much newer than the originals (troff, LaTeX) but well worth a look before writing yet another one-off tool-chain.  Asciidoctor is newer yet and if you don't mind Ruby it has a more complete and simpler tool-chain by default.  I personally find Asciidoc(tor) kind of a pain to get going, but there are lots of widely supported tools and once you sort out your tools of choice and configs you can totally automate it and product great results.

Or if all you want is HTML, especially for a static web site or wiki, you can go with one of the hundreds [3] of "markup to static HTML (& CSS)" generators like Hugo.

Later,
JP

[1] https://en.wikipedia.org/wiki/AsciiDoc
[2] O'Reilly really uses the Ruby Asciidoctor flavor to convert to DocBook, and then the vast collection of DocBook tools to validate schemas and produce PDFs, ebooks, HTML, etc.  It's awesome, and automatic from my perspective...IF my *.asc. files don't break it.
[3] https://www.staticgen.com/ has 300+ Open-Source Static Site Generators

--  -------------------------------------------------------------------
JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug