I ask because it looks like you’ve done most of the heavy lifting between this and your full-text RSS feed service.
The main problem I see is that you can embed trackers in the link URLs.
(You probably want the proxy to be a stateless cache shared by many users, which prevents tracker stuff from persisting in whatever rendering engine it uses for the conversion)
We haven't really thought much about running this kind of thing as a proxy service, or what it would be like to implement it. Our tools are really intended for web articles, so they will fail on lots of other kinds of content you'll encounter in day-to-day browsing. If the intention is to avoid trackers, the proxy will have to handle everything, and not everything will be web articles. Browser extensions might be best here.
Thanks for the response!
My own interest was piqued the other day when I went to pdf-print a paywalled article for a friend and the formatting was atrocious. Would have been the perfect use case for this. But that was the point I thought "does anyone print anymore or do they just message the article?" Most of the print use cases that came up in my life (maps, recipes, contracts) have been solved/replaced by SAAS products, smartphones, tablets, kindles etc.
Which webpage does PrintFriendly doesn't support?
1. The tool for extracting article content is Full-Text RSS. It relies on arc90's original (open source) article detection algorithm, Readability, as well as a set of site-specific extraction rules which we maintain on Github.
2. Our PDF Newspaper application then cleans that extracted article output to normalise HTML/CSS styles so we can present the output in our own layout without things breaking. We use CSS for multi-column output.
3. Finally, we use Chromium's new headless API to request the generated output in step 2 and create three PDFs - injecting CSS to increase the font size each time. After we have the three PDF files, we check the PDFs in order of smallest to largest font size and as soon as a larger font size creates an extra new page, we discard that and keep the PDF we had before and return that. So if PDF 1 (small font size) has three pages, PDF 2 (medium font size) also three pages, but PDF 3 (larger font size) four pages, then we return PDF 2.
 - http://epchan.blogspot.com/
Has this been addressed? Do you have an article on it or a position statement?
"Sorry, something went wrong :("
That said, I don't quite understand the advantage of this solution versus a plain article view (e.g. firefox's built-in article view or something similar provided by some plugin/service) saved to disk via an PDF printer.
As for the advantages, at the moment FireFox's built-in reader view doesn't produce the kind of output we do. If you're curious, we created a video of the kind of multi-column print layout we're experimenting with here a few years ago. All HTML and CSS: https://www.youtube.com/watch?v=854Csokl3QA
So if they did create a more print-friendly output, it'd be closer. But there'd still be that step of you creating the PDF yourself. Our server-side approach allows it to be integrated in other kinds of applications. It also allows us to do things like return a PDF which doesn't include an additional page due to a slight overrun that can be avoided with a minor font size reduction (see my other comment explaining how we try to do that at the moment).
Too many Kindle in single comment
1. Enter a URL (we also have browser extensions)
2. Click 'Preview'
3. Select the No Kindle? tab and choose 'EPUB'
> Premium access key If you pay for premium access, enter your key here. A valid key will enable more pages in each PDF (provided the given feed contains more content), more full-text fetches, and the ability to change the subheading. > Subscribe — 24 € a year
macOS has had print to pdf for any app since its inception, iOS has had it for at least the last couple of versions, surely Windows and Android have similar functionality built in by now too?
In somes cases, e.g. a site that's gone to the trouble of creating a good print stylesheet, printing from the site itself will probably create a more readable output than this. But many sites don't do that.
There's also the use case of automating PDF creation from code. For example, automatically sending a PDF to your printer (some wireless printers can now be set up with email addresses) of articles you save to read later in a read-later service.