588 karma · joined April 3, 2013
- Citypath.eu — City travel app. Job work for a client. - Popol.li — Popularity poll voting app. Our own side project.
If you want to learn more, do get in touch over Twitter: @sewdn or @rhythmvs
[¹] https://github.com/rhythmus/markdown-resources [²] https://github.com/rhythmus/markdown-resources/blob/master/m...
How would you compare your approach to e.g. markdown-js¹, mdown-parse-pegjs², or text.js³ (which are based on PEG parsing)?
I would like to elaborate a bit on the specific differences/benefits between the many MD parsers. (I’m maintaining an inventory of Markdown resources in a repo on Github.⁴)
[¹] https://github.com/evilstreak/markdown-js [²] https://github.com/shamansir/mdown-parse-pegjs [³] https://github.com/sheremetyev/texts.js [⁴] https://github.com/rhythmus/markdown-resources
What if Github is going for an Office (or at least a Word) replacement? Author your blog, thesis, paper, novel, whatever, in a single polyvalent multiplatform editor, with the auto-versioned source stored in the cloud (Github’s), then use it as a feed for your blog, newspaper production flow, or other automated publishing environment…
Hope the fine people at the likes of Draftin.com, Etherpad.org, Penflip.com, Prose.io, et many alii, will survive this. The much acclaimed Editorially.com closed its doors already. Maybe the visionary folks at Substance.io might consider to start negotiating an acquihire.
I feel both exhilarated and a bit jealous: I know for sure I’ll need to put another side-project of mine down.
Bounty hunts.
Say, I am an activist, a revolutionary, or simply someone who wants the competition to go out of business. I want this website down, set up a cryptocontract that implements my bounty. People can join in and assign some more wealth to the contract’s escrow. The bounty will be transferred to whomever publishes his identifying key on the domain I want to see go down. Maybe I’ll include a clause that specifies an expiry date. Or I set a clause that such and such content should be published on the target domain. And so forth. Crowdfunded hacking attacks can become very soon very cheaply accessible, and consequently disrupt some very real-life existing social contracts…
As for structured vs informal writing, there’s an interesting experiment by a copywriter who set up a “framework“¹ (on Github) for writing copy (like those press releases, landing page taglines, etc.).
I wonder how the idea of “forkable” templates for pieces of written content could be developed further.
When we were kids (in the early 1990s), together we made websites: he did the difficult stuff, I did the graphics (Corel Photopaint back then). When I went to college and ran a philosophical magazine, I had my brother make me two websites, in “dynamic html”, then in Flash — it was the late 1990s, and those were cutting-edge, especially in the arts department. While in college, my brother got hooked on php, while the official curriculum taught Java and mocked at “website scripting“. Meanwhile, I picked up html and css, and kept reading: TUGBoat, Techcrunch, Wikipedia. I became quite knowledgeable about the newer stuff: Javascript MVCs, NoSQL — but, as with TeX, everything purely theoretical.
Two years ago we decided to work together again, with this new stack of Mongo/Meteor/Sass: he still on the back-end, I on the front, although the difference between the two is fading away, especially with Meteor. One learns a lot, mutually, in a common “full stack”…
Most of what we can, is from self-learning. I can imagine my brother’s formal training in CS sets a background for self-learning, but his insights in code organization and architecture is from hands-on experience. Without the help of my experienced bro, I’d have a very hard time while teaching myself to code. I keep being a scholar, read about Lisp, Turing completeness, try to figure out data structures, helping myself out with Wikipedia. I’m amazed how all that fascinating theoretical stuff seems to have been merely noteworthy in the CS classes my brother took. I studied art history and philosophy: formal logic was the nearest thing to algebra I had in years. I can safely say, I guess, for both of us, our education has very little to do with the software we write, love and live today.
Our father claims to have written software, while he did his PhD in biomechanics in the late 1970s. It’s hard for us to believe that: as an old-school mechanical engineer he’s got this habit of looking down a bit on making websites and apps. What really helped us to love computers and learn to program, I guess, is that when we were still in primary school, our father bought a PC, got an early internet connection, and let us play with those, freely and without any restriction.
Nice project, and tastefully executed! Plus I can definitely see the usefulness of anonymous one-off publishing, with all the benefits of Markdown formatting…
http://www.notehub.org/2013/12/28/put-notehub-to-the-test?he...
Any particular reason why you picked Pagedown.js for Markdown parsing (it supports plain Markdown only, hence no support for tables)? Maybe have a look at some alternatives? — https://github.com/rhythmus/markdown-resources/blob/master/m...
Best of luck with the project!
Also see discussion https://news.ycombinator.com/item?id=6969897
https://github.com/rhythmus/markdown-resources/wiki/Nota-ben...
If there were only that much support for YAML (as regards parsers, stylesheets, and integration in e.g. Github), as there is for MD…
IMO, Markdown is for text (i.e. continuous reading), while YAML is for structured data (not sequentially read, but randomly accessed/queried).
I’m maintaining a repo¹ with a collection of Markdown resources, listing the abundances of 𝗠⬇ dialects, parsers, editors², stylesheets, … Please feel free to commit!
[¹] https://github.com/rhythmus/markdown-resources [²] https://github.com/rhythmus/markdown-resources/blob/master/m...
// Sass
[data-UI-component="textfield"] {
& > label:only-of-type,
& > label:first-of-type {}
& > input {}
& > label:last-of-type {}
}
/* css output */
[data-UI-component="textfield"] {}
[data-UI-component="textfield"] > label:only-of-type,
[data-UI-component="textfield"] > label:first-of-type {}
[data-UI-component="textfield"] > input {}
[data-UI-component="textfield"] > label:last-of-type {}
Sure your component’s html/handlebars/whatever template must be kept in sync with its css, and adding elements could totally mess-up things. But I think that’s okay, since changing a component’s template should require a revisit of its stylesheet. What do you think?
So I don’t believe that innovation in web and search technologies is keyed around what consumers want. Rather, it’s the other way around: more demanding use cases drive innovation, some of it can be repurposed and then gets fine-tuned thanks to the bigger R&D budgets that come with mass market application.
But the seed of innovation lays in the niches.
Looks great!
Any chance any of these could be applied to legal corpora? (Cfr above: https://news.ycombinator.com/item?id=6731714 )
The Watson computer is good at playing Jeopardy, but it’s just fact collecting. Inferring a rule set from a corpus of documents, reasoning, and drawing solid conclusions, is a different game. We would be better off with a technology that would go over any given corpus of unstructured plain text, parse, tokenize, normalize, structurize, iterate, and dump the graph in a queryable data store. Natural language processing with a semantic reasoner. Legal documents are indeed a great use case.
I went to see my lawyer yesterday. Over the last three years I paid (i.e. was extorted) about $30k in legal fees. That’s lot of money for thin air. Withal, most of the research and paperwork I did myself: my lawyer copy/pasting and putting his court-accredited sign under it. To the legal scribes I’m but a layman, and may not speak on my own behalf in court (unless I want to jeopardize my cause). Despite the fact that I am particularly good at parsing texts, studied linguistics, did a post-doc in natural language processing, and know how to read laws (that are assumed to be known to and understood by all citizens, in the first place, are they not?). Fact is: lawyers, judges and clerks form a self-sustaining caste that benefits of the de facto (and de jure) monopoly of interpreting the law. They have a lucrative interest in laws and bills that are poorly written, are contradictory, full of ambiguity and logical flaws. They share that interest with retarded lawmakers who produce all that ill-conceived cruft.
Suppose we had our laws written in a formal language, with a well defined regular grammar; suppose we had unit testing for new bills — machines could administer justice, and they would be much better at it than the dunces who went to law school.
There’s simply too little stakes in developing semantic technologies that would do away with human corruption, underdeveloped intelligence, sentiment, and subjective interpretations. Or rather: some industries (especially those which are controlled by the powers that be) have too big a stake in preserving backward human knowledge parsing. If big law firms have an interest in using such technologies, they only have so, as long as they gain a competitive advantage from it (vis-à-vis those which don’t have/use such technologies). Legal corpora, neatly marked-up by hand (or semi-automated, no difference), are certainly a valuable asset, that you wouldn’t want everyone to have cheap access to, not your competitors, and especially not your litigant clients.
If we had instead semantic technologies that would cheaply produce queryable knowledge systems from large, impervious document collections (like our codes and jurisprudence), then, very likely, lots of sectors in our so called “knowledge society” would be disrupted, leaving lots of overpaid “knowledge workers” unemployed, overnight. That’s a threat to the very industries which are supposed to support research and development of such technologies, as potential customers.
That’s different with IBM’s customers, I guess: they do have an interest in disrupting their industries (or rather the industries in which they are newcomers), using tech. And they may do so, only because there’s no monopoly guaranteed by a selfish legal system. Maybe also because present day’s state-of-the-art in semantic technologies and AI offers good enough technologies for these use cases, which are less complicated applications than those that would be needed for use cases wherein more difficult knowledge parsing is required, _and_ are bound by a legal/economic anathema?
Anyhow, I will support any startup that would create such tech with the intention to run the human legalese interpreters out of business. And that’s an exhilarating thought, because if such technology would be produced, it will be equally good at solving problems in all branches of science.
In the sample pdf, only the regular font gets messed up by affected pdf renderers (pdf.js in FF, …). That font is TeXGyreTermes-Regular, and it’s the only CID (composite) font. In the source, that font was an OpenType font (.otf), which, during pdf-creation, got converted into a CID double-byte font, resulting in messed-up Identity-H encoding. (CID double-byte fonts are really meant for huge Asian charset fonts, only.) Likely, the pdf engine used, wrongly assumes that all Unicode encoded fonts (.otf) contain huge Asian charsets, and thus converts them into CID.
I guess most newer pdf renderers know to handle the issue, while the renderer used in FF e.a. doesn’t. The quick fix, at pdf creation, is to avoid fonts being converted into CID at all.
Likely a clean, general public friendly GUI (web app) can leverage RinohType’s back-end power, and thus it’s adoption. Maybe monetize that as a hosted service.
A set of professionally designed stylesheets/document templates would give wider adoption a head start.
From your roadmap, I’d be glad to help you achieve some goals (if you would want me to be of any assistance):
- Provide a number of standard document/page/font styles
- Include font definitions for freely available fonts
Fake small capitals for fonts that do not provide any
- Advanced typesetting features such as Knuth-Plass … and microtypography
I originally planned to release RinohType into wild only after I had finished a full review, refactoring and documenting of the code. I also wanted to write some API documentation and a small tutorial, all in the spirit of making a good first impression. Turns out all this takes a huge amount of time! So I’ve decided to dump the code in its current state onto GitHub, write a blog article about it and await some valuable feedback while I resume my refactoring and documenting chore.
If you decide to play around with the code, please bear in mind that this is just a preview; your experience might not be as smooth as I intend it to be eventually.[1] http://en.wikipedia.org/wiki/List_of_typographic_features [2] Check nodebox.github.io/opentype.js/ (https://news.ycombinator.com/item?id=6459778)