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.

~nytpu

[a]: https://codeberg.org/oppenlab/gempub

-- 
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/

I accidentally responded direcrly to nytpu, so I'll re-reply to the
list.

I think gempubs are a great idea! Is there a particular reason you
suggest them to be optional? It seems that gempub archives could be
generated for each item easily enough at the time of cataloging.

Either way, I will prepare to handle gempub submissions alongside a
gemtext version, and I will at least devise a basic utility for
generating them in the cataloging phase.

Thanks nytpu!

~mieum

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`
It'd probably be easy to to throw together a script to run down the
index.gmi line-by-line and concatenate like a real gempub reader would.
The reverse is hard, because how can you know whether a header is a
chapter or section that should be split up or a minor break that
shouldn't, and whether a section has stuff meant to come before it
(rather than at the end of the previous section), etc.

I dunno, maybe you could add more semantic markup throughout the
document that would be stripped out of the regular gemtext version but
used for telling a script where to break up stuff, what to title and
number each section in the gempub index, etc.

~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/

> > 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.
...
> 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.
...
> It'd probably be easy to to throw together a script to run down the
> index.gmi line-by-line and concatenate like a real gempub reader would.
> The reverse is hard, because how can you know whether a header is a
> chapter or section that should be split up or a minor break that
> shouldn't, and whether a section has stuff meant to come before it
> (rather than at the end of the previous section), etc.

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.

Thanks nytpu!

~mieum

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
indication of what to title each chapter in the index file).

-- 
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/

> 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?
Sorry, I didn't realize you were suggesting that. I think I have been
dazed by the suddenly summery weather here @_@

> 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
> indication of what to title each chapter in the index file).

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.

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 guess it is
more error prone (if the chapter titles are mismatched). Although, it
would be easy to write a function that validates this in new patches.

Anyway, it sounds like a nice thing to implement one way or another.
What do you think? It would be cool if booksin.space could help make the
gempub format more common around geminispace.

Thanks for following up on this! Sorry I had overlooked it haha

~mieun

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
> guess it is more error prone (if the chapter titles are mismatched).
> Although, it would be easy to write a function that validates this in
> new patches.
I don't really like specifying the names of the chapters in the heading,
but I do like the automatic generation for when manual labelling isn't
needed.  Like we could have a key where every h1 is a chapter, or every
h2, or every h1 and h2, etc.  For my The King in Yellow (as an example),
you could split on every h2 and to split on chapters I think.

> Anyway, it sounds like a nice thing to implement one way or another.
> What do you think? It would be cool if booksin.space could help make
> the gempub format more common around geminispace.
I definitely think it'd be a great thing to implement it (no matter if
it ends up being manually- or auto-generated).  I'm disappointed that
the only gempubs that currently exist are the reference gempub in the
gempub repo and The King in Yellow.  I do think that's probably more of
a problem with a lack of software though.

> Thanks for following up on this! Sorry I had overlooked it haha
No problem!

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --locate-key alex@nytpu.com
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/

> 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.

Is the purpose of the numbering just to preserve the order of the
chapters when generating the gempub?

> I don't really like specifying the names of the chapters in the heading,
> but I do like the automatic generation for when manual labelling isn't
> needed.  Like we could have a key where every h1 is a chapter, or every
> h2, or every h1 and h2, etc.  For my The King in Yellow (as an example),
> you could split on every h2 and to split on chapters I think.

Yeah, that would be nifty, and I would guess that the majority of books
could be handled by one of the defaults.

> I definitely think it'd be a great thing to implement it (no matter if
> it ends up being manually- or auto-generated).  I'm disappointed that
> the only gempubs that currently exist are the reference gempub in the
> gempub repo and The King in Yellow.  I do think that's probably more of
> a problem with a lack of software though.

It would be great to see it more widely implemented! It's also kind of
neat because you could potentially use it to "carry" your capsule around
from server to server.