Thanks a lot! We’re working on the input issue you mention.
588 karma · joined April 3, 2013
But there’s some fierce objection against the merger of IDPF into the W3C [1][2], the key (?) argument being formulated as:
> “The W3C is focused on promoting the Web, but eBooks are not websites. When the IDPF is gone, who will advocate for readers?”
Maybe a fair point, but I don’t think I can agree. While it is true indeed that reading long-form content like books requires enduring focus, and that having to read them in a browser where linkbait always is luring to have you click away into a never ending feed of distraction, the problem is not the underlying technology.
[1] http://www.publishersweekly.com/pw/by-topic/digital/content-...
— Sure, if we’d not only consider machine architecture, language design and compile times, but add social factors to the equation, like ecosystems, business models, and network effects, well okay, then maybe a single, apprentice developer might do the work of a 100k MSc programmers, and at least as much as he `require`s modules. :-p
Could you be more specific on the problem you’re facing with placing images? Is it that there are like hundreds of them, for which you would want to have created the references (and ) automatically, because typing out the file paths manually is too tedious? That is doable, although it would be more of a drag-and-drop feature to be implemented by a dedicated Markdown editor, or an ST plugin.
Or would you like to have more fine-grained control over floats, sizing and placement of the images relative to their place in the text narrative? For which a WYSIWYG interface is indeed more well suited, re: many document author’s gripe with TeX’s figure placement.
Just look at the list of “feature requests” on the CommonMark forum.¹ Pandoc’s Markdown supports lots of extra features from Github Flavored Markdown (GFM), MultiMarkdown and MarkdownExtra. John MacFarlane, Pandoc’s author, is also the author of the CommonMark spec. And while, eventually, the goal is to extend the CommonMark syntax with a sufficiently broad vocabulary of content element types, the focus now is on getting the basics right, speccing the edge cases, and defining standard parser behavior.
Meanwhile, there is AsciiDoc (which is a port of DocBook xml to lightweight markup), for more demanding use cases. And then there is also reStructuredText, and org-mode, etc. But the markdownish-style of syntactical sugar won the race, and while doing so, it will be the basis for a future lightweight markup language that will do indeed support not-dumbed down written content, with the full variety of nuance that offer the likes of TEI, DocBook, TeX, and will be fit to reproduce the akme of complex documents and typesetting, such as critical editions and technical manuals.
Until we reach that point, I bet on dumbed-down Markdown, and while doing so, can always add-in raw html ad libitum. The bulk of most written content, after all, is just headings and plain text, with a few emphasized phrases here and there, a link, an image. That covers a lot of use cases already.
- Setext (Ian Feldman, 1992) - AFT (Todd Coram, 1999) - Grutatxt (Ángel Ortega, 2000) - atx (Aaron Swartz, 2002) - AsciiDoc (Stuart Rackham, 2002) - MediaWiki (Magnus Manske & Lee Daniel Crocker, 2002) - reStructuredText (David Goodger, 2002) - Org-mode (Carsten Dominik, 2003) - Textile (Dean Allen, 2004) - Markdown (John Gruber & Aaron Swartz, 2004)
The wide margins are due to typography best practices, which dictates between ~50 and 70 characters on a line. One could of course blow up font-size, as is in fashion, since Medium. But then there are too few lines above the fold.
But you’re entirely correct as regards marginal notes. Unfortunately, they’re not trivially implemented, since you’d need to swap end-notes to side-notes relative to the viewport, cq. media query breakpoint, but while that involves DOM manipulation, it cannot be done with CSS alone. Let alone dealing with collision detection for stacking longer footnotes vertically…
[Sustainable Authorship in Plain Text using Pandoc and Markdown](http://programminghistorian.org/lessons/sustainable-authorsh...)
Anyone familiar with command line tools and a corresponding aversion for bloated WYSIWYG apps will second the underlying idea that MS Word (and the likes) “should die” in favor of plain text workflows.
Yet, with the help of Pandoc (which does the heavy lifting in these boilerplates), nothing prevents you to keep using Word as a front-end and plug it in this exact same workflow. Word may not be the best-of-bread typesetting engine or layouting tool, but to many it still is useful as a quite decent word processor.
For those interested, I did a (long-read) write-up on how one could go from Word over Markdown to even InDesign (as an alternative templating/typesetting engine, instead of LaTeX/XeTeX): http://rhythmus.be/md2indd/
$ wget https://butterproject.org
--2015-10-23 22:10:49-- https://butterproject.org/
Resolving butterproject.org... 184.168.221.24
Connecting to butterproject.org|184.168.221.24|:443... failed: Connection refused.Send the link with the hash using your gmail account, stay tuned at the corresponding page on http://ephemeralp2p.durazo.us, watch “Currently viewing” pop to "2" immediately after you sent the mail. Obviously, the Google borg is slurping up each and every address on the Web it is fed.
I did a similar project¹, with strong focus on editing math, inline, and “real time” wysiwyg. It failed. The problem is that most such approaches treat Markdown as _code_ instead of _text_, and inevitably mistake syntax highlighting for semantic, text-driven styling (as if one would style nouns, verbs, adjectives, instead of <h1>, <p>, <em>, etc.). Thus they use a code editor such as CodeMirror (like this one does, too). And then you must style `.cm-` syntax markers instead of the eventual (html) nodes that would be the output of a real Markdown parser. Which makes it impossible to just throw in any arbitrary html5 css-stylesheet. Which is imho the whole point of wysiwyg Markdown editing.
What you’d really want instead is true Markdown parsing, which normalizes the user’s input into a parse tree, then renders to clean html. But syncing input and output over an AST is quite impossible as long as Shadow DOM is not available in browsers. Cfr interesting discussion, over at Github (re: Quill editor).²
As for Markdown parsers: there’s many of them. The OP’s project uses @chjj’s marked.js³: wouldn’t harm to mention that on the homepage or in the README, since behavior (markdown interpretation) is very different from parser to parser. (I used to maintain a repo which lists all available Markdown parsers, apps, etc.)⁴
Meanwhile there’s CommonMark⁵, of course, which has already some really fast implementations in JavaScript. (Plus, they’re “Standard” ;-)⁶ Would be nice to see one of the CommonMark reference implementations incorporated into a WYSIWYG editor like this one.
¹ https://github.com/rhythmus/mathdown ² https://github.com/quilljs/quill/issues/74#issuecomment-4294... ³ https://github.com/chjj/marked ⁴ https://github.com/rhythmus/markdown-resources ⁵ http://commonmark.org ⁶ https://news.ycombinator.com/item?id=8264733
Especially when they accept that the argument must exclusively be about a discipline’s alleged usefulness to the economy. Last week the Belgian vice-president said Latin should be replaced as a high school subject with programming classes, because they are more useful. It’s been picked up, even by prominent intellectuals: http://woutersoudan.be/20150405/
Then there’s FontForge², which is by far the most evolved, feature-heavy project, but until recently had bad UX/UI and was a pain to install and run on OSX. It seems, that’s changed, though.
FontLab³ still is the type design “industry”’s de facto standard font editor, but development lags behind, and it’s quite expensive for a hobby project.
There are a few other proprietary offerings, notably the DTL FontMaster⁴ tool suite. But Glyphs⁵ seems to be going the winner, steadily taking over market share from FontLab.
If you like scripting your designs (esp. in Python) you should definitely try RoboFont⁶.
When you’re looking for volunteers/collaborators on your project, then do check in at Typophile⁷. For over a decade, it’s the principal outlet for all things type and type design: on the fora you’ll meet some very knowledgable experts always willing to help.
Since you mentioned punctuation, I suppose you’re familiar already with the _Shady Characters_⁸ project (and its companion book⁹). As for a detailed history, I can highly recommend Malcolm B. Parkes† authoritative monograph on the subject, too.
¹ http://en.wikipedia.org/wiki/Metafont ² http://fontforge.github.io ³ http://www.fontlab.com/font-editor/fontlab-studio ⁴ http://www.fontmaster.nl ⁵ http://www.glyphsapp.com ⁶ http://doc.robofont.com ⁷ http://typophile.com ⁸ http://www.shadycharacters.co.uk ⁹ Keith Houston, Shady Characters: The Secret Life of Punctuation, Symbols, and Other Typographical Marks. W. W. Norton, 2013. † Malcolm B. Parkes, Pause and Effect: Punctuation in the West. University of California Press, 1993.
Both Common Mark and Pandoc serve different purposes: the first is an initiative to counter fragmentation/balkanization of the Markdown ecosystem and in being so has to reckon with backward compatibility, consensus and adoption. The latter is a document conversion library, which, by design, needs to reckon with interchangeability between formats and may hence be hampered by the lowest common denominator as regards feature support. Internally, Pandoc keeps an Abstract Syntax Tree (accessible in json format), and defaults on its own flavour of Pandoc Markdown (featuring a Markdown superset of content element types).
Both the Common Mark community and John MacFarlane have made it clear their first and foremost focus is on standardization, not so much on extending the feature set. Yet, scholars and technical writers are in dire need for something more heavy-weight than the rather small set of features offered by Common Mark implementations or Pandoc Markdown. Hence the Scholarly Markdown initiative and the scholdoc reference implementation (Pandoc fork).
More on how Scholarly Markdown came about, can be read on the blog of one of it’s pacemakers, Martin Fenner; e.g. http://blog.martinfenner.org/2013/11/17/the-grammar-of-schol..., http://blogs.plos.org/mfenner/2012/12/18/additional-markdown...
Which flavour of Markdown are you supporting? Do you plan to support _full_ Common Mark?
What are you using under the hood as your typesetting engine and stylesheet syntax? Pandoc, (La)TeX, CSS w/ Prince XML?