Show HN: GitPrint.com – A site to easily print Markdown files on GitHub(gitprint.com)
gitprint.com
Show HN: GitPrint.com – A site to easily print Markdown files on GitHub
https://gitprint.com/jquery/jquery/blob/master/README.md
45 comments
What is doing the typesetting? I do not recognize:
Producer: Qt 4.8.4 (C) 2011 Nokia Corporation and/or its subsidiary(-ies)
$ pandoc -s -S -o gitprint.pdf FILE.mdAs a fun exercise, you should checkout the Gitit README[0], which is a cool VCS-managed wiki that renders everything via Pandoc, using this Gitprint service. Or not. I see you or someone else constantly retorting with "Why not Pandoc?" and I agree with you. I started to get interest in Haskell again just because Pandoc, and Gitit, and some other very impressive stuff, is written in Haskell and seems to do some stuff very powerfully.
However, a caveat. It is not mentioned in the documentation, but Gitit does not enable PDF export by default, when Pandoc is more than capable of doing so? Why? Because, in all fairness, it can add significant load. According to the conf file comments.
> pdf-export: yes
> # if yes, PDF will appear in export options. PDF will be created using
> # pdflatex, which must be installed and in the path. Note that PDF
> # exports create significant additional server load.
How much load, I am not sure. I would love to see a similar Happstack app like this program that runs gitit or the new fork gitit2, rewritten for Happstack updates now that the API has matured. This makes me think performance is an issue.
As an aside, I know ShareLatex opened up their code. I have not had time to check, but I was curious if they do use standard Latex for generating files and if they do, how they make it performant (I know they have a couple layers, I watched their old Node/JS London talk, I mean hear Latex in particular) so fast for potentially thousands of people at once.
[0] https://gitprint.com/jgm/gitit/blob/master/README.markdown
However, a caveat. It is not mentioned in the documentation, but Gitit does not enable PDF export by default, when Pandoc is more than capable of doing so? Why? Because, in all fairness, it can add significant load. According to the conf file comments.
> pdf-export: yes
> # if yes, PDF will appear in export options. PDF will be created using
> # pdflatex, which must be installed and in the path. Note that PDF
> # exports create significant additional server load.
How much load, I am not sure. I would love to see a similar Happstack app like this program that runs gitit or the new fork gitit2, rewritten for Happstack updates now that the API has matured. This makes me think performance is an issue.
As an aside, I know ShareLatex opened up their code. I have not had time to check, but I was curious if they do use standard Latex for generating files and if they do, how they make it performant (I know they have a couple layers, I watched their old Node/JS London talk, I mean hear Latex in particular) so fast for potentially thousands of people at once.
[0] https://gitprint.com/jgm/gitit/blob/master/README.markdown
The server load is due to using Latex for the typesetting. Is it surprising that publication quality typesetting takes more resources than the ragged right text that this puts out? No.
Is it surprising that processing inline TeX equations or Bibtex citations takes more resources? No.
Compare and Contrast:
Gitprint's pdf of README: https://gitprint.com/jgm/gitit/blob/master/README.markdown
Gitit's html export of README: http://gitit.net/README?printable
If I don't care about the quality of the text layout gitit's printable html page is equivalent to the gitprint pdf. Adding Merriweather to default.html is trivial. But as another commentator pointed out maybe using a new trendy font might not be the best choice if you want decent unicode coverage; just in case one of your users is among the "minority" of people who were unsatisfied by the basic ASCII charset.
Moreover comparing gitprint's markdown support to pandoc as if it is apples to apples is silly.
Is it surprising that processing inline TeX equations or Bibtex citations takes more resources? No.
Compare and Contrast:
Gitprint's pdf of README: https://gitprint.com/jgm/gitit/blob/master/README.markdown
Gitit's html export of README: http://gitit.net/README?printable
If I don't care about the quality of the text layout gitit's printable html page is equivalent to the gitprint pdf. Adding Merriweather to default.html is trivial. But as another commentator pointed out maybe using a new trendy font might not be the best choice if you want decent unicode coverage; just in case one of your users is among the "minority" of people who were unsatisfied by the basic ASCII charset.
Moreover comparing gitprint's markdown support to pandoc as if it is apples to apples is silly.
I definitely appreciate what you are saying but when I read the thread three separate response to comments were example incantations of Pandoc. Pandoc is amazing, this appears to a weekend project.
Is Latex requiring processing power to generate PDFs that become professional publishing house books surprising? Of course not. Latex is sick. I was a non-tech student in college, and when I discovered Latex in a CS class my mind was blow and loved it for a while, despite fucking up regularly with its learning curve. (Funny anecdote: I even had a terrible philosophy professor in my liberal arts college senior year who went to Stanford and noticed he used Latex for everything, unlike any professor at my tech-illiterate school; he used it because his friend was this guy Donald Knuth; I kissed that guy's ass for the rest of the semester after that tidbit just for stories about Knuth). My point was scaling Latex in a server environment would be difficult, and I was addressing a few people equating this whole thing to Pandoc, which I did not find fair. Running Latex concurrently for lots of people sounds rough to me, but then again I never implemeneted anything nearly as complicated as that.
Gitit does not just give you just a printable HTML page. If you notice, gitit uses the Pandoc backend to export many formats. It might not set them as printable, but to see gitit+pandoc in action, look at the export menu to the bottom left corner of the default them on the page you link. You do not see the PDF format export, because as I mentioned in my original comment, by default Pandoc Latex+PDF support is not enabled because of said performance load.
I was speculating writing an equivalent of this service with Pandoc and Haskell is doable, but solely generating PDFs would be a load that might make it difficult at scale. I do not know. ShareLatex, who arguably is way ahead beyond my speculation because they implemented a powerful web-based Latex editor, did some very unorthodox (as far as just reloading Latex in the shell every time) architecture to make it fast and resilient.
I am not sure how to respond to the comment re Gitit and Pandoc. Gitit is basically a wrapper around Pandoc, and it is merely a web interface to everything Pandoc does for different document formats, and hackage clearly lists it as a dependency with version 1.10+.[0] I know they are not apple to apple comparison. It was just a speculation. In the other post I was actually using Gitit and Pandoc interchangeably because the latter is the integral component of the former.
I feel there is a type checking joke lurking in my last line, but I am too tired to find it.
[0] http://hackage.haskell.org/package/gitit-0.10.3.1
Is Latex requiring processing power to generate PDFs that become professional publishing house books surprising? Of course not. Latex is sick. I was a non-tech student in college, and when I discovered Latex in a CS class my mind was blow and loved it for a while, despite fucking up regularly with its learning curve. (Funny anecdote: I even had a terrible philosophy professor in my liberal arts college senior year who went to Stanford and noticed he used Latex for everything, unlike any professor at my tech-illiterate school; he used it because his friend was this guy Donald Knuth; I kissed that guy's ass for the rest of the semester after that tidbit just for stories about Knuth). My point was scaling Latex in a server environment would be difficult, and I was addressing a few people equating this whole thing to Pandoc, which I did not find fair. Running Latex concurrently for lots of people sounds rough to me, but then again I never implemeneted anything nearly as complicated as that.
Gitit does not just give you just a printable HTML page. If you notice, gitit uses the Pandoc backend to export many formats. It might not set them as printable, but to see gitit+pandoc in action, look at the export menu to the bottom left corner of the default them on the page you link. You do not see the PDF format export, because as I mentioned in my original comment, by default Pandoc Latex+PDF support is not enabled because of said performance load.
I was speculating writing an equivalent of this service with Pandoc and Haskell is doable, but solely generating PDFs would be a load that might make it difficult at scale. I do not know. ShareLatex, who arguably is way ahead beyond my speculation because they implemented a powerful web-based Latex editor, did some very unorthodox (as far as just reloading Latex in the shell every time) architecture to make it fast and resilient.
I am not sure how to respond to the comment re Gitit and Pandoc. Gitit is basically a wrapper around Pandoc, and it is merely a web interface to everything Pandoc does for different document formats, and hackage clearly lists it as a dependency with version 1.10+.[0] I know they are not apple to apple comparison. It was just a speculation. In the other post I was actually using Gitit and Pandoc interchangeably because the latter is the integral component of the former.
I feel there is a type checking joke lurking in my last line, but I am too tired to find it.
[0] http://hackage.haskell.org/package/gitit-0.10.3.1
I totally agree: pandoc is amazing, this is just a weekend project that is a solution in search of a problem. I can just highlight github's markdown pretty print and tell iceweasel to print selection and select save as pdf instead of sending to cupsd queue.
To be clear this project:
The type checking joke is that I never compared gitit to pandoc. So don't worry about responding to any comment you think I made regarding gitit and pandoc.
[^1]: https://gitprint.com/jgm/pandoc/master/README = "Something went wrong! Couldn't process https://raw.github.com/jgm/pandoc/master/README/master/READM... = ROFLSATIRE
To be clear this project:
1. Converts a certain unknown basic markdown syntax to html
(iff the filename is something that it recognizes[^1])
2. adds css for Merriweather, Open Sans, Dejavu Mono and a silly iconfont
(I prefer pandoc's pygments syntax highlighting over goofy icon)
3. renders html->pdf using webkit by way of phantomjs.
$ pandoc -s -S -t html5 -o out.html README.md
$ wkhtmltopdf out.html out.pdf
$ pandoc -s -S -t html5 -o out.html README.md
$ phantomjs rasterize.js ./out.html out.pdf Letter
The type checking joke is that I never compared gitit to pandoc. So don't worry about responding to any comment you think I made regarding gitit and pandoc.
[^1]: https://gitprint.com/jgm/pandoc/master/README = "Something went wrong! Couldn't process https://raw.github.com/jgm/pandoc/master/README/master/READM... = ROFLSATIRE
The Gitprint error is cute. I did not have that when I tried. I guess more indication I will stick to my own tools. As for everything else, thanks for the clarification.
This is great. Would happily pay a few $$$ to be able to use on private repositories.
I haven't looked into private repos yet, but good idea: will add it to the todo list.
Private markdown files should be accessible from a tokenized raw.github.com link. So it'd be neat if https://gitprint.com/josh/secret/master/REAMDE.md?token=123 worked.
Great service, thank you! I've already used it to print out https://gitprint.com/hueniverse/hawk
Awesome. I had been using this bookmarklet:
javascript:(function(e,a,g,h,f,c,b,d)%7Bif(!(f=e.jQuery)%7C%7Cg>f.fn.jquery%7C%7Ch(f))%7Bc=a.createElement("script");c.type="text/javascript";c.src="http://ajax.googleapis.com/ajax/libs/jquery/"+g+"/jquery.min.js";c.onload=c.onreadystatechange=function()%7Bif(!b&&(!(d=this.readyState)%7C%7Cd=="loaded"%7C%7Cd=="complete"))%7Bh((f=e.jQuery).noConflict(1),b=1);f(c).remove()%7D%7D;a.documentElement.childNodes%5B0%5D.appendChild(c)%7D%7D)(window,document,"1.3.2",function($,L)%7B$('%23header, .pagehead, .breadcrumb, .commit, .meta, %23footer, %23footer-push, .wiki-actions, %23last-edit, .actions, .header,.site-footer,.repository-sidebar,.file-navigation').remove(); $('%23files, .file').css(%7B"background":"none", "border":"none"%7D); $('link').removeAttr('media');%7D);javascript:(function(e,a,g,h,f,c,b,d)%7Bif(!(f=e.jQuery)%7C%7Cg>f.fn.jquery%7C%7Ch(f))%7Bc=a.createElement("script");c.type="text/javascript";c.src="http://ajax.googleapis.com/ajax/libs/jquery/"+g+"/jquery.min.js";c.onload=c.onreadystatechange=function()%7Bif(!b&&(!(d=this.readyState)%7C%7Cd=="loaded"%7C%7Cd=="complete"))%7Bh((f=e.jQuery).noConflict(1),b=1);f(c).remove()%7D%7D;a.documentElement.childNodes%5B0%5D.appendChild(c)%7D%7D)(window,document,"1.3.2",function($,L)%7B$('%23header, .pagehead, .breadcrumb, .commit, .meta, %23footer, %23footer-push, .wiki-actions, %23last-edit, .actions, .header,.site-footer,.repository-sidebar,.file-navigation').remove(); $('%23files, .file').css(%7B"background":"none", "border":"none"%7D); $('link').removeAttr('media');%7D);I've been fighting with print css for a while this week. I guess they just render it server side and show a pdf?
I wish print css was more supported. I'll read blog articles describing my plight, but from 10 years ago. It makes me sad.
I wish print css was more supported. I'll read blog articles describing my plight, but from 10 years ago. It makes me sad.
so i've been taking a similar tack with my online portfolio, although i haven't followed through completely.
i really despise word processors, so i've been building out a jekyll/github pages site with each of my past jobs/projects as small markdown posts with the necessary metadata.
Then on the theme level I pull in the markdown files into a responsive site that degrades down all the way to mobile, and that has a print stylesheet that will generate a presentable resume from all this content.
I never really seem to get to the point of finishing the print stylesheet, because I seem to always find a job before I get to that point.
Still, at least now I can just update some small text files as I continue my career, and ultimately it just feels more sensible for me to manage that data than something like LinkedIn.
I was also thinking about adding some client side filtering of the past projects/jobs based on the technologies I tag them with, so I can generate a customized resume for each position. Maybe if I abstract it out into a separate project ...
i really despise word processors, so i've been building out a jekyll/github pages site with each of my past jobs/projects as small markdown posts with the necessary metadata.
Then on the theme level I pull in the markdown files into a responsive site that degrades down all the way to mobile, and that has a print stylesheet that will generate a presentable resume from all this content.
I never really seem to get to the point of finishing the print stylesheet, because I seem to always find a job before I get to that point.
Still, at least now I can just update some small text files as I continue my career, and ultimately it just feels more sensible for me to manage that data than something like LinkedIn.
I was also thinking about adding some client side filtering of the past projects/jobs based on the technologies I tag them with, so I can generate a customized resume for each position. Maybe if I abstract it out into a separate project ...
This looks so great. I just looked at the current print.css styles today on a README and they look really awful comparatively.
There might be some JS hacks that could be done on github.com itself to render a more stylized view when ⌘+P is pressed. Avoiding the need for a special "print this page" button.
There might be some JS hacks that could be done on github.com itself to render a more stylized view when ⌘+P is pressed. Avoiding the need for a special "print this page" button.
Bookmarklet to jump from github to gitprint
javascript:if (location.href.slice(0,18) == "https://github.com" && document.body.classList.contains('page-blob')) location.href = 'https://gitprint.com' + location.href.slice(18)Great service! I noticed however that it is unable to resolve image paths that use relative addresses.
Example: https://gitprint.com/chriscummins/pip-db Image tag: 
Example: https://gitprint.com/chriscummins/pip-db Image tag: 
Great point. Will see what I can do.
In Chromium this initiates an automatic download as soon as I open the URL. Yuck. Otherwise, cool service.
Doesn't appear to handle markdown GISTs on gist.github.com. Probably a fairly easy fix if you just create a gist.gitprint.com alias and rewrite the request URL to the slightly different pattern.
Otherwise excellent work.
Otherwise excellent work.
More cross-browser testing is in order.
In Chromium on Linux Mint, it wants to download the PDF file right away (doesn't wait for a button press). And it never actually loads, just keeps showing the loading icon.
In Chromium on Linux Mint, it wants to download the PDF file right away (doesn't wait for a button press). And it never actually loads, just keeps showing the loading icon.
Could you not have posted a link to the main home page for gitprint, rather than direct to a URL that invokes a print dialog? That's pretty nasty.
(Aprt from that, though, this looks like a handy service :))
(Aprt from that, though, this looks like a handy service :))
Yeah, I know. I did think about that too, but decided seeing it in action was the best way to express it's intent. I might update the submission title to warn people though.
that link is a _very_ bad idea. awful.
and i'm the person who told you last week that this service is a good idea. it is.
so change the link.
-bowerbird
and i'm the person who told you last week that this service is a good idea. it is.
so change the link.
-bowerbird
A bit strong, but have disabled the onload printing for now.
> A bit strong
no, actually, it was just right.
taking people to the print-set dialog when they have _clicked_a_link_ is not just confusing, it's unsettling.
especially when -- as is common here on hacker news -- someone has opened several different tabs and thus has no idea which caused this totally unexpected situation.
"unsettling" is quite deserving of the "awful" label.
(perhaps that word has an emotional connotation to you. but i'm using it the same way that i would describe, say, a "saturday night live" skit that was worse than usual.)
the "improvement" you have made is thus good... but...
...the current state is still unnecessarily confusing... clickers are shown a "jquery - new wave javascript" page. which is most definitely _not_ what they clicked to see.
you have a perfectly good home-page explaining the service, and how we can use it quite easily, with a button to click to summon up a canned example if we want that. excellent!
_that_ is where the h.n. link should go -- your home page.
welcome people at the front door, and _then_ give the tour.
don't just dump people into the middle of your canned demo, when some of them (certainly those who opened multiple tabs) will not even know exactly how they arrived there, or why.
it would have been a little bit better if your demo content was an explanatory page about gitprint itself. but even then, linking to the home-page is still a much smarter strategy...
maybe you'll think this is "strong" too.
it's not. i'm just telling you like it is.
i don't have any emotion invested. this is dispassionate.
i don't even care if you heed what i say or not.
it's no skin off my nose. i'm just trying to help you.
remember, i was the _only_ person who commented on this when you posted it last week. "good idea", i posted...
so instead of getting criticized this week, you _should_ have said "thank you", and then implemented my suggestion.
there's still time...
-bowerbird
no, actually, it was just right.
taking people to the print-set dialog when they have _clicked_a_link_ is not just confusing, it's unsettling.
especially when -- as is common here on hacker news -- someone has opened several different tabs and thus has no idea which caused this totally unexpected situation.
"unsettling" is quite deserving of the "awful" label.
(perhaps that word has an emotional connotation to you. but i'm using it the same way that i would describe, say, a "saturday night live" skit that was worse than usual.)
the "improvement" you have made is thus good... but...
...the current state is still unnecessarily confusing... clickers are shown a "jquery - new wave javascript" page. which is most definitely _not_ what they clicked to see.
you have a perfectly good home-page explaining the service, and how we can use it quite easily, with a button to click to summon up a canned example if we want that. excellent!
_that_ is where the h.n. link should go -- your home page.
welcome people at the front door, and _then_ give the tour.
don't just dump people into the middle of your canned demo, when some of them (certainly those who opened multiple tabs) will not even know exactly how they arrived there, or why.
it would have been a little bit better if your demo content was an explanatory page about gitprint itself. but even then, linking to the home-page is still a much smarter strategy...
maybe you'll think this is "strong" too.
it's not. i'm just telling you like it is.
i don't have any emotion invested. this is dispassionate.
i don't even care if you heed what i say or not.
it's no skin off my nose. i'm just trying to help you.
remember, i was the _only_ person who commented on this when you posted it last week. "good idea", i posted...
so instead of getting criticized this week, you _should_ have said "thank you", and then implemented my suggestion.
there's still time...
-bowerbird
[deleted]
This is great! In the past, I've had to write kudgy scripts to do this. Two features requests:
- Syntax highlighting on code blocks
- Ability to insert page breaks
Agreed, syntax highlighting for repos with a lot of example code blocks in their README.md would be great:
https://gitprint.com/thearn/stl_tools
https://gitprint.com/thearn/stl_tools
Are you expecting to print in B/W or colour?
B/W syntax printing poses a great design challenge ;) Should be fun
Great, it looks beautiful!
@see https://gitprint.com/reeze/tipi, but Chinese text didn't display correct :(
@see https://gitprint.com/reeze/tipi, but Chinese text didn't display correct :(
What are you using to generate the PDF? I've been looking for a good html to PDF converter for a project I'm working on.
It's Phantom doing the printing.
$ pandoc -o out.pdf README.mdNice tool. I started thinking of applications already.
Is it possible to print gists right now ?
$ pandoc -o gist.pdf http://gist.github.com/BLAHBLAHNo, not right now. Will add that to the task list too. Thanks
Are there any plans to open source this ?
Nice work!
I got frustrated with not having a good way to print Markdown files from GitHub (root level repo READMEs and individual .md/mdown files).
It's super simple to use: just replace 'github.com' with 'gitprint.com' (when on a GitHub markdown file page) and it will convert it to a beautiful print-friendly PDF and prompt you to print.
Any feedback would be appreciated. (It's just a fun side project, but would like to improve it as I think it could be useful for like-minded people)