💾 Archived View for jdcard.com › blog › 2023-12-06T19-40.gmi captured on 2024-03-21 at 15:36:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
The oldest pages on my website date back to about 1997. I was in school, my ISP provided webspace for me as part of their service, so I learned to write HTML to take advantage of that. The School of Business at this university had recently decided that the ability to work well with others in group setting was a very important skill for their graduates to acquire. Nearly every course included a group project of some sort, and having a place to easily share files with group members proved to be very helpful.
HTML soon became my primary document format. I used word processor software for documents that required more than what HTML offered, but nearly everything else I wrote was done as HTML; in fact I soon started writing drafts of papers in HTML and then imported the HTML into a word processor for the final edit.
In the beginning I tried various ways of editing my HTML files. Netscape Navigator included authoring tools, W3C offered their Amaya software that was designed from the beginning to be both an editor and a browser, and most word processor software by this time had an option to export a document in HTML format. I soon dicovered a small editor (QuickPage) I liked that was designed just for editing HTML, and specifically tried to ensure that the HTML you wrote included only valid markup, making it easier for me to avoid careless mistakes as I wrote. I began to care even more about the quality of the HTML code that I wrote and soon updated all my pages to ensure they were compliant with the latest HTML specification: 4.0.
This worked well for me for the following 20 years or so. I spend most of my time with a web browser open anyway. If I needed to print a document the browser nearly always did a good job of that. HTML files are easy to edit, relatively small, and easy to share. I had been writing HTML for so long that I didn't mind inserting "<p>" and other markup as needed, it had become mostly automatic.
In May of 2022 I discovered the Gemini protocol and its associated gemtext file format. I tried it out for a while at tilde.team and discovered it was quick, light, had smaller document sizes than an equivalent HTML document, and really easy to write. I tinkered with it a while and soon decided to convert most of my existing HTML to gemtext on my website. (There are a few documents I left as HTML that demand the more complex features of HTML, but even some of those I provide a simplified gemtext version of.) I never learned to like Markdown, I often resorted to just inserting HTML code into the markdown file anyway, so it never really semed worth the effort to master it. But gemtext is a breath of fresh air! When I bump up against its limitations I can still switch to HTML, so I am really enjoying writing again.
Now I find that gemtext has become my new default document type. My biggest frustration though, has been that I only know of one Gemini client that prints a nicely rendered gemtext document: Rosy Crow. Sadly, even that one has not been working properly on my phone since recent updates.
This past week I spent a few days exploring what options there might be. The simplest option would be "lpr myfile.gmi", but this just prints the raw text of the file rather than a nicely-formatted version that clients like Lagrange offer, and it doesn't even word-wrap the lines. Gemtext is simple to parse, so I thought I might write a quick script to generate a nicer version to send off to the printer. Soon I was up to my eyebrows in LaTeX, PostScript, and PDF generation -- there is NOTHING simple about that option. Those toolsets are very old and very complex to work with, and do not easily handle Unicode characters. Of course it could be a case of "yes, Linux is user-friendly, it's just real picky about who its friends are", since my programming skills are rather shallow.
The best option I've found for printing a gemtext document is converting it to HTML, loading that into a web browser, and printing from there. There are dozens of gemtext-to-HTML converters available; the one I found easiest to use is a single PHP script that I found somewhere last year. I thought it had come from Hundredrabbits, but couldn't find any reference to it on their site. I originally stored it in a directory named "gemini.sensorstation.co/" with a read-me file named "computing.gemini.gmi-to-html.gmi". Similarly, I can find no reference to it at gemini.sensorstation.co, so I can't offer a link to the source. It includes no comments or metadata within the file to offer clues. I suppose I could publish my modified version of the file if anyone is interested in it.
gemini://gemini.circumlunar.space/users/hundredrabbits/
gemini://gemini.sensorstation.co/
That's great for printing gemtext files that are on my webserver, but I want to print files from my local nework. I do already have PHP running on my local desktop machine but didn't want to mess with installing and configuring a real webserver. A few modifications to the script now allow me open a local gemtext in a web browser and then hit CTRL-p to print. It is clunky and cumbersome but it will work until I can convince the rest of the world that sometimes we do still need to print paper copies of our documents, and it would be good for full-featured Gemini clients to offer that option.
I've spent another day or two looking at this issue and have worked out a two-pronged approach for generating printed documents from gemtext source files.
The first I have already implemented, thanks to the generosity of Frank Seifferth, who e-mailed me offering his solution to the problem: a Python script that generates nice PDF files from gemtext. I spent a little while building a custom CSS stylesheet and now get good-looking prints when I need them. There are two limitations to gemdoc that lead me to continue working on this problem.
Another limitation of gemdoc is also a feature that I like: the PDF that is generated is a gemtext/pdf polyglot -- the same file can be viewed in your Gemini client and in a PDF viewer with no modifications. The slight disadvantage with this is that Gemini clients will display the first couple of lines of the PDF code at the top of the page, and a large chunk of PDF code at the bottome of the page, which may be acceptable for some uses. The generated file functions perfectly as a PDF though. Another slight annoyance is that gemdoc over-writes the source gemtext file, but this was easy enough to work around. This program is almost what I need, and if I had any experience with Python I'd work on getting it to do what I want. It is what I'm relying on for now. Thanks, Frank! (If you'd like to try my gemdoc stylesheet I've included a link here.)
https://github.com/seifferth/gemdoc
The second solution came to me while I was customizing my gemdoc stylesheet. Web browsers do a good job of displaying -- and printing -- documents. I'm already familar with HTML/CSS and PHP and with some Bash scripting to glue together various bits of the work flow I'll have something that works just right for me. Browsers can print direct to my printers, or print to a PDF file that I can then easily print. Browsers seem to have conquered the issue of reliably displaying Unicode. So I'm brushing up my CSS skills regarding paged media and I'll add @media sections to the code I'm already using. When it's all finished I'll make a new post with more details.
I've decided not to use gemdoc for my blog posts -- at least for now -- because I'll have to rewrite my blog scripts to accomadte the PDF content.
📧Comment on this post (via e-mail)
📅 c: 2023-12-06 19:40 ✏️ e: 22023-12-12 13:17
🏷 tags: #print #gemtext #php #script #gemdoc