Sizing covers

[eshellman]

In #5 it was decided to use large covers, we can resize later. I suggest this can be done in Unglue.it or in giten_site.

In Giten_site these are stored as version controlled repository assets. In unglue.it, covers are stored in S3 using django file storage. I expect it's not practical to use (duplicate) repo assets and instead we should make sizing code for unglue.it and deplow on gitensite as well.

Thoughts?

[rdhyee]

I don't feel ready to weigh into discussing this question because I don't have a good sense of how we envision connecting unglue.it, gitensite, and github at an over architectural scale (along with attendant goals). A lot of my thinking has been driven by the short term goal of producing 50 books. That's why, for example, we just store a cover.jpg in its respective repo: for the pragmatical reason of making it easy to build a book using travis.

To decide on where to store covers and how to resize them, we have issues like:

• how many covers do we expect per book
• what sources?
• what type of transformations do we need to do and where do we have to send the results?
• how much should we cram into travis?
• overall flow of stuff among unglue.it, gitensite, and github.

[eshellman]

should leave it out of travis. other websites will want to scale differently

[jenny8lee]

• how many covers do we expect per book

RTC will get many many covers for some books (upwards of a dozen), and
others just two. Not all of those have to be Gitenbergized.

• what sources?

RTC is the main source, but you might have others I am not aware of.

Generally, the full versions are way too big for an epub. You probably want
to use the equivalent of a "web version," which are creating for
recoveringtheclassics.com anyway.

I don't know the answers below.

• what type of transformations do we need to do and where do we have
  to send the results.
• how much should we cram into travis?
• overall flow of stuff among unglue.it, gitensite, and github.

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

[rdhyee]

@jenny8lee You should know that we had decided to write the big covers to the 50 repos as cover.jpg at this point. (for example: https://github.com/GITenberg/Adventures-of-Huckleberry-Finn_76/blob/master/cover.jpg) and building that epub based on the large cover.

[sethwoodworth]

I suggest writing a reusable django app for this. It would contain a model
for cover images, which would be stored as user media rather than static
files. There are a variety of configurable thumbnail generators for django
that can we can use to generate thumbnails in a variety of sizes. There
should be a focus in the app on providing covers via API requests, which
would let us resize images from the cli and add them to repos as a commit
or on build. Details TBD

On Thu, Jul 30, 2015 at 12:40 PM, Raymond Yee notifications@github.com
wrote:

@jenny8lee https://github.com/jenny8lee You should know that we had
decided to write the big covers to the 50 repos as cover.jpg at this point.
(for example:
https://github.com/GITenberg/Adventures-of-Huckleberry-Finn_76/blob/master/cover.jpg)
and building that epub based on the large cover.

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

[eshellman]

that's pretty much what I was thinking.