github.com
[Edit] Sample PDF :: https://drive.google.com/file/d/1n7M1TKOptSsYiibrbvV_Yojx53T...
OP: this is important. There are a million tools to generate PDF files, most of them don't produce nice looking PDFs.
Also just my opinion and honest feedback but I don't really consider that PDF "beautiful" or readable. However, your project is a very good start toward something that is potentially very useful.
Here are my suggestions:
- Switch to a modern, beautiful, readable serif font that isn't an overused (Times New Roman, Garamond, and pretty much any MS fonts are overused and will make your PDF end up looking like "yet another Word document"). Some good options that come to mind are Tiempos Fine, Butler, Lora, but there are lots of good ones out there. Shop around for something both unique AND highly readable. Make sure your PDF generator embeds the font or (preferably) converts all text to paths instead of just referencing the font.
Also, know the difference between fonts designed for printing and screen reading and fonts designed for both, and adjust according to whatever use case you're marketing.
- Figure out how to make the sub-headers heavier weight and significantly larger to stand out. Be bold with your font size changes. Printed documents look "nice" when the sections are clearly laid out and EASY for the eye to parse from a distance how the document is organized and which are top level headings and which are subheadings under those headings. For generation purposes there's a good chance you can probably just parse it from <h1> <h2> <h3> ... tags in the HTML, unless the website uses some JS-framework-of-the-month bullshit. Use more white space before each header to physically separate it. Avoid using lines between a header and the text it corresponds to, as that can be distracting to the eye since lines are normally thought of as separating sections.
I'd give you a pull request but I'm super busy these days.
Maybe increase the line height a bit.
If there's any interest I might OSS the pipeline
Edit: Ah, there was a thread(1) with related examples further down. And Pandoc can indeed do epub output.
I'm on mobile, so I can't add a Google Drive file screenshot to the readme, and iframes are not supported.
sudo apt install pandoc wkhtmltopdf
npm install -g readability-cli
pandoc -s https://www.paulgraham.com/avg.html -o output.html && readable output.html -o readable.html && wkhtmltopdf readable.html output.pdf && open output.pdf
#!/bin/bash
# Prompt the user for a URL
read -p "Enter the URL: " URL
# Use the URL in the pandoc command
pandoc -s $url -o output.html && readable output.html -o readable.html && wkhtmltopdf readable.html output.pdf && open output.pdf
chmod +x web2pdf.sh
# add an alias to bashrc
alias web2pdf='/path/to/your/web2pdf.sh'
source ~/.bashrcWhich is pretty much what OP did, with a few nice additions like nice output and some custom css and fonts. Which is nice and OP hope brings value to people.
If you add a few printf:s and include a nice template for pandoc* it would be more along the same thing.
*) Neither pandoc, wkhtmlpdf or weasyprint have (in my opinion) bad default templates.
It would be really nice if there existed a utility able to produce a PDF file where the Web pages are rendered as well as the browsers render them on the screen, without becoming confused even by complex scripts loaded by the page.
The alternatives to "Print" (producing a PDF) are even worse. A screenshot has limited resolution and it loses the text. In the past "Save as ..." was the normal solution, but now even if you save a "complete" page, it will still frequently include scripts that will no longer work offline. What I want to save are the pages perfectly rendered as they were at that instant, without any scripts that could make them appear differently in the future.
pipenv shell
pipenv install
python main.py https://www.paulgraham.com/avg.html, https://www.paulgraham.com/determination.html
What’s the rationale for “separated by commas”? The convention for CLI arguments is to use one argument per input file.
If you want to support multiple input URLs just pass all of them in, one URL per element in sys.argv
% python main.py https://www.paulgraham.com/avg.html
Traceback (most recent call last):
File "/Users/bill/web2pdf/main.py", line 7, in <module>
from readability import Document
ImportError: cannot import name 'Document' from 'readability'
(/Users/bill/.local/share/virtualenvs/web2pdf-
gXeVRXKg/lib/python3.9/site-packages/readability/__init__.py)
"readability": {
"hashes": [
"sha256:f9030df8bc31aad45baffa9a2d9ce1fdd8051833e5b5bda3027df32fdec00fad"
],
"index": "pypi",
"version": "==0.3.1"
},
pdfpage() {
convert -resize 0x1000^ "${1}"[${2}] -background white -flatten sixel:-
}
For e-ink readers epubs are generally better than PDFs for urls anyways, as epubs are basically packed htmls, and also the flow text works better on smaller screens.
One benefit of using a Chrome extension (vs. CLI) is that it's easy to 'print' things that require authentication.
I'm sure I'm missing something, what is a cli interface buying me here?