August 4th, 2002

  • brad

External Stylesheets

mart's a CSS junkie and wanted a function to print an external stylesheet that you can link from your other HTML pages.

Good for everybody: saves bandwidth.


That's linking to this stylesheet:

Where "res" is for "resource" and "1" means styleid 1.

The stylesheet is mostly static... it's written in S2, so it has access to the style's properties and such.

For cache control, the Last-Modified field of the document returned is going to be the time of the most recently layer in that style. Going to do that part now. (Done)

(And fixed two s2compile errors in the process of doing this.)
  • brad

Gallery Thumbnails

As promised, here's the plan for gallery thumbnails.

I'll begin implementing shortly.

One thing I'll need very soon here (in addition to the JS color picker!) is the crop region & focus point editor.

Basically, start with /manage/pic, copy it to /manage/cropregion and make it so you can drag/resize a rectangle around some region of the scaled image, and also move a circle focus point.

Then, let people save it.

I'll do all the database stuff... just do the cross-platform DHTML to move the rectangle and dot. (and they should be in multiple high-contrast colors, so they're visible on all images)
  • brad

Holy war time.. variable/function names

core1.s2 is getting ugly already, as we haven't decided on a policy for variable and function names.

Should we go?


Right now we're doing some of each.

I don't care much, as long as it's consistent. I don't like all lowercase much, like Page.stylesheeturl (which we currently have) so the alternatives are like:

Page.styleSheetURL (java-style)
Page.stylesheet_url (gtk-style)

Or, Java style with initial capital:

Page.StyleSheetURL. (C#-style)

Should we vote? ... fight? ... argue with reasons? I'm not sure.

  • brad

Thumbnail support progress!

Thumbnail transformation stuff is in. Lot still to go, but it's straight-forward. Check it out:

Move your mouse over the pictures. Woooo. :-)

If you choose this layout for your collection, you'll notice it may load slowly. One optimization which I don't do yet is I always scale down from the original image. If I want a 100x100 greyscale image, it's stupid to start with a 3.1 megapixel source image. If I already have the 100x100 color or 320x200 color, I should start with that.

I have FIXMEs where I need to do that, but I've been waiting until I've needed it several times, so I know how to best generalize a new API call for it.
  • brad

Efficient scaling

The scaling optimization I previously discussed is in.

A 320x240 image is created on upload, which is the same size on the /manage/pic page, so it'll be sure to be used. But also, any thumbnails are scaled using the 320x240 as a base.

Actually, the rule is... if it wants to scale to W*H, it needs to find a version of the original that is at least W*H*4 pixels. I figure that will guarantee a high-quality scale (minimum 2x2 averaging regions), but maybe that's overkill. We'll see. It's better than the slowness before, though.

But as thumbnails are 150x150 max now, 320x240 is large & small enough to be the source for any uncropped, unzoomed thumbnail.

The fun part is later when we have to decide which scaled version to start with when we also have a cropping region. :-)