[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Regarding HTML rendering

From: Steve Izma
Subject: Re: [Groff] Regarding HTML rendering
Date: Fri, 18 Aug 2017 00:02:01 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Fri, Aug 18, 2017 at 12:33:12AM +0200, Ingo Schwarze wrote:
> Subject: Re: [Groff] Regarding HTML rendering
> Steve Izma wrote on Thu, Aug 17, 2017 at 04:52:56PM -0400:
> > A relatively simple notation like Markdown would also work,
> I agree with all you are saying except this.
> The OP is certainly better off writing his documents in proper
> roff(7) or groff_mom(7) and living with slighly quirky HTML output
> than writing his documents in markdown and getting crappy output
> quality in *all* output formats.  Converting markdown into acceptable
> roff input is just not feasible - not only because there is no tool
> to do it, but also because markdown is just not powerful enough,
> even if you were willing to write a new program to do that.

Hi Ingo,

Thanks for the comments. But I feel like I've sprung a page trap
that sent me into an entirely different document by merely using
the word "Markdown". You've misunderstood me, since I referred to
a "simple notation *like* Markdown [emphasis added]" for which
one should use a script to create input for groff. I wasn't at
all suggesting using Markdown or anything like it for creating
groff source documents because I don't know of any generally
available tool that does this.

> Besides, i hate the myth being re-iterated that markdown would be
> easy to use.  It is an extremely hostile, hard-to-use language
> because it doesn't have any kind of consistent syntax, but instead
> three strongly conflicting ones, so the rules for what any given
> input means are usually extremely complicated and counter-intuitive,
> and besides, there is almost no markdown document that is portable
> because the details of all three syntaxes differ from one implementation
> to the other, and there is no lack of conflicting implementations.
> For details why you should never use or recommend markdown as a
> source language for any documents, see

It seems to me this argument implies a desire for a
general-purpose markup language for creating typeset documents,
which I think is an impossible goal. I'm interested in a simple
markup notation for writing texts that I will later convert to
probably an XML document for long-term archiving and use, and
from that to various output formats. If the target is a part of a
book, I would need to do it differently than I would if it were a
journal article. If it were a poster or some other short,
layout-intensive item, I wouldn't bother with markup.

Any ascii-based notation like Markdown or MediaWiki can be used
or adapted; their backends are irrelevant to this. And many of
the complaints you have don't make any difference to me: in
forty-five years of typesetting I've never needed to use
bold-italic-bold; definition lists are a weird deviation from
typographical style -- I would never reproduce in print what the
HTML definition list displays in a browser; there are all sorts
of ways of handling what you call mixing block and flow (I would
call them block-level elements and in-line elements) in
converting to groff code with or without a parser. I think what
you're saying about line spaces at EOL (an admittedly bizarre
notation) that affect list parsing might be relevant to the main
problem I have with these types of notations: they insist on list
elements being exactly one line long, which is just the result of
a syntax inadequate or too lazy for designating the beginning and
the end of a list. I would simply add opening and closing list
markers to my conversion script (which could be awk, sed, python,

Anyway, simple Markdown and MediaWiki types of notation are
important in the area of publishing where I work because we need
a text-based system of inputting that can replace the widespread
use of word processors. This is obviously an uphill battle, but
I've seen the appeal of things like Markdown (probably
MultiMarkdown and AsciiDoc) at workshops and seminars, where it
has clearly not been difficult to use. LaTeX and groff are not
markup languages for structured documents; obviously, they're for
presentation. You can fake structure by using high-level macro
requests, but then you end up with something like XML without the
angle brackets. And the current command set in LaTeX is too
verbose and intrusive in a writing context. I think MOM has much
more concisely named requests that are meant for semantic clarity.

You may be perfectly correct in completely dismissing poor
implementations of a tool, but given the need for a simple markup
language I think it's a good idea to compare different approaches
that have potential to aid writing and that separate content
structure from presentation.

        -- Steve

Steve Izma                                address@hidden
    Home:  35 Locust St., Kitchener ON        519-745-1313 
           Canada, N2H 1W6              cell: 519-998-2684 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]