Sam's notebook

Email-letters February 25th, 2018, 9AM

Writing

I’ve been attempting to write to people again lately. As in, proper letters on paper and in envelopes and stuck through holes in walls and doors. It doesn’t work though. Ten years ago I wrote to people, and it was reasonably easy although one had to ignore the anachronistic self-consciousness. Now, it feels like writing a telegram, for all the relevance it has to modern life. And doing so on some sort of rare letterpress’d form at that — the mechanics have become harder, the whole thing far less familiar. Where even is there a post box around here? Do stamps still come in booklets? What’s it even cost to send a letter? Only people having weddings send things in the post these days.

I once wrote a little system for writing email-letters. It was a bit like Gmail’s system of having the reply-box at the bottom of the to-and-fro conversation, except it went to further extremes of actually deleting the quoted reply text from emails, and of actually tracking correspondents as entities in their own right and not just by email address. It also prohibited writing to more than one person at once.

It feels like there’s a place for a letter-writing system that really is just email but also isn’t one’s normal email client (be that Fastmail, Gmail, Thunderbird, or whatever). Writing to a friend should be a different act to tapping off a note to a colleague or haggling with a civil servant. The user interface should reflect that. It should be simpler, calmer, and prioritise longer paragraphs and better grammar. (I’ve read similar sentiments relating to the design of the Discourse forum software; the developers of that want the software to shunt people towards better discussions, and I’m pretty sure Google don’t have anything like that idea with the Gmail interface. No one wants to write a letter on a blotter edged with full-colour advertisements for Fletcher’s Fantastic Fumigator, and Google want you to use the exact same interface for work and for social interaction. Doesn’t seem like a good idea to me.)

I’d still be using my email archiver, but it dates from an age before two-factor authentication, and improvements in the security of email providers broke it and I’ve not yet gotten around to fixing it. Perhaps it’s time to do so.

[No comments] [Keywords: , , , , , ] [Permanent link]

Why do socialists only drink herbal tea? February 25th, 2018, 8AM

Programming

Because they’re sick of non-semantic CSS class names, and of not having sensible default formatting for the main, header, article, section, aside, footer, and nav tags.

No, it’s actually because property is theft!

A few years ago I came across Marx CSS reset, which is a simple and small (7.92 KB) stylesheet that provides decent formatting not only for the usual HTML element, but also all the new HTML5 ones. It does it by not expecting anyone to do things like <ul class="nav">…</ul> but rather <nav><ul>…</ul></nav> which mightn’t seem like much, but it feels better to me.

Maybe I just wish to live in a classless society.

[No comments] [Keywords: , , , , ] [Permanent link]

Extension:DocBookExport February 21st, 2018, 9AM

Open content

There’s a new extension recently been added to mediawiki.org, called DocBookExport. It provides a system of defining a book’s structure (a set of pages and some title and other metadata) and then pipes the pages’ HTML through Pandoc and out into DocBook format, from where it can be turned into PDF or just downloaded as-is.

There are a few issues with getting the extension to run (e.g. it wants to write to its own directory, rather than a normal place for temporary files), and I haven’t actually managed to get it fully functioning. But the idea is interesting. Certainly, there are some limitations with Pandoc, but mostly it’s remarkably good at converting things.

It seems that DocBookExport, and any other MediaWiki export or format conversion system, works best when the wiki pages (and their templates etc.) are written with the output formats in mind. Then, one can avoid things such as web-only formatting conventions that make PDF (or epub, or man page) generation trickier.

[No comments] [Keywords: , , , , , , ] [Permanent link]

Twittery February 21st, 2018, 8AM

Miscellaneous

There’s not really much that can be said on Twitter that can’t instead be said much more verbosely and with far fewer people seeing it on one’s own blog. There’s no limit to the meaningless silly things you can write on the internet, so they might as well be written in one’s own place.

I’m just a bit sick of the non-chronological nature of Twitter, where some mysterious inner force in the machine is telling me what’s “important”, and leaving me with the feeling that it’s not showing me things that I might actually want to see.

So I think I’ll come back here, to blog in this quiet secluded corner of the web. This, in combination with a bare-bones chronological RSS reader, has worked pretty well for 15 years; might as well carry on with it.

[No comments] [Permanent link]

Flickr2Piwigo 1.3.0 February 20th, 2018, 8AM

Programming

I thought I’d help out and try to update the Flickr2Piwigo plugin to support OAuth, but having done so I now seem to have become a maintainer of the thing. So that’s good. I’ve just released version 1.3.0.

I’ll try to see to all the outstanding bug reports (well, there’s only one at the moment). And then perhaps add some extra features (support for approximate dates? automatic downloading? download of other people’s photos?).

[No comments] [Keywords: , , , , , ] [Permanent link]

Updating Flickr2Piwigo February 18th, 2018, 8AM

Programming

I’ve decided to try to bring the Flickr2Piwigo plugin up to date in order to support OAuth (Flickr’s old system of authentication was turned off in the middle of last year). I’ve been tinkering with getting the PhpFlickr library working properly lately (which is what Flickr2Piwigo uses to talk to Flickr), and although there’s lots more to do to it I’ve at least got the OAuth parts working (thanks to the lusitanian/oauth package). So now I’m going to add this to the Flickr2Piwigo.

There’s no support for Composer in Piwigo, so I’m not really sure how this is going to work. Probably some custom distribution-generation process; I’ll worry about that later. Hopefully we’ll not resort to committing vendor/.

Once this is working, I’ll go back to PhpFlickr and write some better documentation (probably Read The Docs) and fix up the caching system (it’s a bespoke oddity at the moment, that I think should be replaced with simple PSR-6 support).

[No comments] [Keywords: , , , , , ] [Permanent link]

Wikisource books for binding February 11th, 2018, 12PM

Open content

I have been experimenting with turning Wikisource works into LaTeX-formatted bindable PDFs. My initial idea was to produce quatro or octavo layout sheets (i.e. 8 or 16 book pages to a sheet of paper that’s printed on both sides and has the pages layed out in such a way as when the sheet is folded the pages are in the correct order) but now I’m thinking of just using a print-on-demand service (hopefully Pediapress, because they seem pretty brilliant).

Basically, my tool downloads all of a work’s pages and subpages (in the main namespace only; it doesn’t care about the method of construction of the work) and saves the HTML for these, in order, to a html/ directory. Then (here’s the crux of the thing) it uses Pandoc to create a set of matching TeX files in an adjacent latex/ directory.

So far, so obvious. But the trouble with this approach of wanting to create a separate source format for a work is that there are changes that one wants to make to the work (either formatting or structural) that can’t be made upstream on Wikisource — but we also want to be able to bring down updates at any time from Wikisource. That is to say, this is creating a fork of the work in a different format, but it’s a fork that needs to be able to be kept up to date.

My current solution to this is to save the HTML and LaTeX files in a Git repository (one per work) and have two branches: one containing the raw un-edited HTML and LaTeX, on which the download operation can be re-run at any time; and the other being based off this, being a place to make any edits required, and which can have the first merged into it whenever that’s updated. This will sometimes result in merge conflicts, but for the most part (because the upstream changes are generally small typo fixes and the like) will happen without error.

Now I just want to automate all this a little bit more, so a new project can be created (with GitHub repo and all) with a single (albeit slow!) command.

The output ends up something like The Nether World by George Gissing.pdf.

[No comments] [Keywords: , , , , , , , ] [Permanent link]