search

storborg / pyramid_frontend

Theme handling, image filtering, and asset optimization for Pyramid
Other
0 stars 2 forks source link

Speculative future features #35

Open storborg opened 9 years ago

storborg commented 9 years ago

Support SASS-- since bootstrap has abandoned LESS, SASS is probably the future.

This might be a bit troublesome because sass doesn't really have a workable client-side rendering option: but that was never really a good solution to begin with, because large themes can really kill certain browsers.

Add mechanism for themes to pass variables (possibly as class members?) into asset compilers, e.g. lessc or libsass.

This could be restricted to certain asset compilers: might be hard to actually implement that for certain command-line compilers/parsers.

The idea here is that it should be possible to make a new subclass theme that only requires a Python file to customize basic look and feel.

Don't use uploaded filenames: they tend to suck.

Possible alternatives:

  1. Allow admin interface to pass a 'name hint' (e.g. the name of the article the page is on, or the name of a title passed in at the same time, or both) and use that to generate a better filename.
  2. Make filenames totally non-human-readable, e.g. a hash of the content, random, etc.
  3. Use a combination of both: e.g. suffix the non-human-readable filename with the uploaded filename.
  4. ??

Provide inherent protection against re-uploading the same file as a new object.

Admin users will do stupid things like re-upload the exact same file or re-upload a generated variant of the same file (even worse).

Allow for versioning / re-uploading new variants of a source file.

Particularly when batch-uploading: e.g. it should be easy to re-export an entire gallery from Lightroom, and have the system identify / update any images that changed.

Support alternative / arbitrary media formats.

Add support for <picture> and <srcset>

Not sure how this would work. With <picture>, that might require things like multiple variants of a given image, which may be outside the scope of pyramid_frontend. Or, it could maintain things like crop or filter information.

Add support for multiple source files

E.g. you might want to have a DNG or TIFF file that is tracked alongside a JPG, where the JPG would be used for generating smaller thumbnails. This might also be outside of the scope of pyramid_frontend.

Smarter aspect-ratio changing algorithm

Basically, follow the following steps:

  1. Check if an image has a clean background edge: e.g. the entire border is exactly the same color (possibly check to see if a few pixels of border are consistent).
  2. If the border is clean, first crop to the bounding box of consistent color, then pad with that color to the desired aspect ratio. Offer a parameter to pad around the bounding box: default to 0 pixels.
  3. If the border is not clean, crop to the desired aspect ratio. Default to entropy cropping, but also offer a mode that crops to the center (possibly additional modes?).