Quote:
Originally Posted by jandrew
Not sure what you mean here, markdown always supported atx style headings like:
# level one heading
## level two heading (and so on)
or am I missing your point in this grepping matter?
|
FWIW, the Markdown used by Teamworks is the # method; the markdown used by Desk (owned by Salesforce) uses textually-indicated headings, e.g., .h3, .h4, etc. Just for clarity about what I was bitching about.
Quote:
If your system existed in isolation that would be fine, but shouldn’t readers of this thread who might be unfamiliar with text based writing systems be able to read comments about how your system compares to existing solutions?
There is nothing particularly wrong with your solution per se, but the fact is that your dthtm.exe/dunyazad system is basically a very limited, but syntactically differing, version of a pandoc/markdown system. You have not offered any advantages that I can see, over just using a minimal subset of markdown.
On the other hand, what pandoc/markdown offers (beyond additional markup extensions) is:
- it has been widely used and tested for years
- it is actively maintained/developed
- there are many text editors providing markdown support (like syntax highlighting and preview modes) for win/mac/linux/ios/android platforms
- multiple format conversion including: html, pdf, epub2/3 and more
So, even if people just want to stick with headings, pararaphs, and italics, if they go with pandoc/markdown they have the above advantages. If their writing later requires footnotes, tables, citations, lists, code blocks, images, or such, they can add to their knowledge of pandoc/markdown as needed.
Certainly I get that you aren’t trying to be everything for everybody, and your system works for you and that is fine, and you are, of course, already invested in your system. I am not trying to attack your system for not being something else. But others might appreciate some context before investing.
cheers, andrew
|
This is sort of my gripe; I mean, firstly, arguing about which "plain text system" is best actually begs the question. The assumption (the "begging the question") is, that a plain text system is preferable, and thus, we should debate whether RobertDDL's system is
better than Pandoc or better than Markdown, yadda.
I'm simply saying that while it's a nice intellectual exercise, it's not one in which I, personally, can invest time, because I do think it's wheel-spinning. RobertDDL has his system in place. It's what he's going to use, and he's happy with it. Quite honestly, despite his multiple explanations, I'm damned if I understand WHY, because the entire choice seems to be about the idea that the NCX is superfluous, and the OPF unnecessary, and that it's "needlessly complicated," which is great if you're dealing with a one-page long book, but once you're past 270KB, you have other choices to make, that absolutely require nav aids like the NCX (or landmarks), a spine, etc. Nonetheless...
I think that anyone who's making books for themselves should be able to do whatever they want. It's moot. Once you migrate into making books for others, you have to fall in line with what the reading systems support. {shrug}. That's the boat I'm in, and honestly, I find ePUB to be a fairly smooth, sleek, reading system. If you use Sigil, the heavy lifting of the OPF and NCX are done for you, assuming that you have a brain and use headings for structure, which is what they are for. Moreover, using those same heading styles, a human-viewable nav system can be built as well, in addition to the (also human-viewable) NCX. I certainly don't see how that's slower than grepping markdown headings--and certainly not slower than having to TYPE the markdown in the first place, plus the regex/grep, plus...
Like I said: it's a nice intellectual exercise, but I think I'll bow out, and leave it to you geeksters for a nice heated debate about which will work better in the long run.
As far as machine-readability, @skreutzer, were that true, we'd be using XML and XSLT. We're not. That should tell us all something, I'd think. However, if that were the goal, I'd argue for XML, simply because it's already well-established and in large document-archival systems, already in place (like medical records, etc.).
My $.02, and worth less than that.
Hitch