Colorado
i've migrated to my self-hosted code repo, see: https://git.nytpu.com/
From Alex // nytpu to ~mieum/booksin.space
On 2021-06-12 12:22AM, mieum wrote: > Would you like me to wait on this until we decide about the gempub > generation mechanism/syntax? Yeah, that'd be best IMO ~nytpu -- Alex // nytpu alex@nytpu.com gpg --auto-key-locate=wkd --locate-key alex@nytpu.com Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/
From Alex // nytpu to ~mieum/booksin.space
On 2021-06-11 09:41AM, mieum wrote: > So, for instance, headings preceeded by a '%' could indicate a > chapter? The added bonus of doing something like this is being able > to automatically generate a ToC or break up long texts by chapter for > non-gempub versions. I like this. Simple, and it automatically includes chapter titles to the index/ToC. In that case then we'd either need to start numbering headers in the gemtext itself or have the converter script auto-number the chapters, because gemtext doesn't auto-number for us usually. > Another option would be to have a ToC key in the YAML frontmatter that > specifies the names of the chapters (with some default values for > indicating that every heading is a chapter or that there are no > chapters etc.). This would eliminate the need for extra markup, but I
From Alex // nytpu to ~mieum/booksin.space
Accidentally wrote directly to mieum instead of to the list. On 2021-06-10 10:35AM, mieum wrote: > Ah, I see. I guess having fewer quality gempubs is better than a ton > of awkward ones that slaughter the content. In that case I will update > the readme with a link to the gempub spec and some notes about > contributing them. So is that a nack on possibly adding YAML (or something) throughout the document to indicate where to break apart a file into separate files? Thinking about it more it wouldn't add that much more for contributors (just add markup every chapter break while you're converting to gemtext) and it'd be pretty easy to convert from the one-page format to gempub if you have actual markers on where to split it up (and also some
From nytpu to ~mieum/booksin.space
--- Added title and byline to body text itself. cataloging/chambers_the-king-in-yellow.gmi | 4087 ++++++++++++++++++++ 1 file changed, 4087 insertions(+) create mode 100644 cataloging/chambers_the-king-in-yellow.gmi diff --git a/cataloging/chambers_the-king-in-yellow.gmi b/cataloging/chambers_the-king-in-yellow.gmi new file mode 100644 index 0000000..00d04d8 --- /dev/null +++ b/cataloging/chambers_the-king-in-yellow.gmi @@ -0,0 +1,4087 @@ --- [message trimmed]
From Alex // nytpu to ~mieum/booksin.space
On 2021-06-09 01:43PM, mieum wrote: > Should this file have a title heading + byline? Is it preferrable to > programatically insert those using the metadata, or to have > contributors format submissions with a title and byline themselves? I think it should. In my opinion (I don't know what you envisioned), you should be able to strip out all YAML and other such elements and get a standalone gemtext document without having to make any modifications, which means it should include all title, byline, and possibly copyright info at the bottom. Depending on how you decide formatting should possibly be changed, I'll probably make a revision once some more stuff is finalized. Thanks!
From Alex // nytpu to ~mieum/booksin.space
On 2021-06-09 11:44PM, mieum wrote: > I think gempubs are a great idea! Is there a particular reason you > suggest them to be optional? It is a minor to major amount of extra work when making them by hand, and I didn't want to burden extra contributors too much. > It seems that gempub archives could be generated for each item easily > enough at the time of cataloging. I'd say that properly splitting up an arbitrary book into a gempub programatically (without manual intervention and reediting at least) would be very difficult. However, generating the format used by booksin.space from a gempub is very easy. In fact, to create my The King in Yellow submission I just took my gempub version and did `cat [0-9]-*.gmi >> book.gmi`
From nytpu to ~mieum/booksin.space
To note: Like how the author metadata field is lastname, firstname for sorting purposes, I made the title field have a suffix "the" to facilitate sorting. Also, if my proposal about including gempubs is accepted, there is a gempub for The King in Yellow available here: gemini://nytpu.com/gpubs/the-king-in-yellow.gpub (I can send another patch adding it if necessary) --- cataloging/chambers_the-king-in-yellow.gmi | 4084 ++++++++++++++++++++ 1 file changed, 4084 insertions(+) create mode 100644 cataloging/chambers_the-king-in-yellow.gmi diff --git a/cataloging/chambers_the-king-in-yellow.gmi b/cataloging/chambers_the-king-in-yellow.gmi [message trimmed]
From Alex // nytpu to ~mieum/booksin.space
As a possible suggestion, could we (optionally) include gempubs[a] alongside the regular gemtext versions of a book? We could be like Project Gutenberg where you can read in your Gemini browser, or you could download the ebook version and read in your preferred ereader software. If the book's already in gemtext format, then to convert to gempub all you do is split up the chapters into different files, add an index page, add some metadata stuff (basically the same as booksin.space's metadata anyways) and zip it up. And I suggest that making gempubs is optional. As in, booksin.space is primarily a regular Gemini library, that sometimes has gempubs as a bonus.
From nytpu to ~sircmpwn/gmni-devel
By default, kineto loads a stylesheet given to -s from disk and places it inline with the HTML in a <style>...</style> block. This patch adds a -e flag to load a stylesheet externally. When the -e flag is passed with a URI (relative or absolute), the given link is placed in the href of a <link rel="stylesheet"...> tag. This helps facilitate caching which can *significantly* reduce request overhead, particularly when the stylesheet is large (>= the size of the page content). The given URI is not validated, and if it is invalid the browser will 404 when requesting it and the page will have no style. --- README.md | 14 +++++++--- main.go | 77 +++++++++++++++++++++++++++++++++---------------------- 2 files changed, 58 insertions(+), 33 deletions(-) [message trimmed]
From Alex // nytpu to ~sircmpwn/gmni-discuss
As a genuine question, may I ask why you chose BearSSL to switch to? I understand why OpenSSL is...not a wonderful library to put it kindly, but BearSSL has the worst TLS 1.3 support out of any of the major libraries, and TLS 1.3 is more important for Gemini than most other applications of TLS considering how insecure client certificates are in TLS 1.2[0], plus the fact that TLS 1.2 is only "reluctantly" allowed in Gemini and "TLS 1.3 or higher may be specced [once TLS libraries get better 1.3 support]," which most libraries other than BearSSL have. I just have concerns about future compatibility. BearSSL hasn't had a new release since 2018[1] and that it's averaged well under 0.3 commits per month for the past three years[2], which isn't giving me hope that the six print pages of to-do for TLS 1.3 support[3] will ever be completed.