Image resizing

[balupton]

Current you can insert images fine, and drag them around, but there doesn't appear to be a way to resize them.

What are the current plans for this? As this is a pretty important thing :)

[jejacks0n]

I currently have it disabled in the browsers as it leads to a misunderstanding of what size an image actually is. I have an image cropper that I may integrate eventually that will allow resizing/cropping in the proper way -- really adjusting the image size down instead of just adjusting the width/height of an image.

[balupton]

I disagree, when you resize an image in Word - you are not resizing the source image, but merely the width and height of the one inserted into the document.

[jejacks0n]

I'll look into this. I'd like to try and come up with an intuitive way that allows for image resizing both ways. What I'd prefer not to see happen is a 4 meg+ image scaled down to 50x50px because there's no better way. I'd like to provide a way to scale / crop the image properly so a new image is generated and inserted in place of the original (so we aren't serving up large assets scaled down).

Resizing an image should be pretty easy, but I'd also like to accomodate users who want to do it properly. That's what I think needs some consideration, and why I haven't attacked the feature head on yet.

[balupton]

Updated

How about this:

1. An image is inserted
   1. A reference to the original image is added as a data attribute
   2. The image is resized to an appropriate size via CSS
2. User is resizing the image
   1. The resize is applied via CSS
3. When a CSS resize has finished (via user, or initial)
   1. The image is resized properly either client side or server side if client side is not supported
   2. If the image has grown bigger than the last saved size, then we use the original image as reference for the resize

[balupton]

I'm available on the weekend. Let's make this happen.

[gvarela]

Client side resizing of images is a terrible idea. It leads to performance issues client side because users almost never understand the implications. I think image resizing should always be handled server side with a cropping tool.

[balupton]

@gvarela I can say that's a terrible idea too, please provide more of your rationale with the pros and cons of both approaches.

[jejacks0n]

It's a hard thing to approach right? There's downsides to allowing a user to easily change the dimensions of an image in markup when they don't know what they're doing, and there's complications with setup/installation if you use a server implementation.

Since we have the luxury of targeting a specific browser set we may be able to accomplish this solely in the client -- with an optional server spec if the client can't handle it for some reason (eg. really large files etc).

@balupton it was basically your suggestion of "The image is resized properly either client side or server side if client side is not supported" that got me thinking about this.

There will always be a requirement for image uploading on the server, that's just the nature of it if we want to have that feature.. but the image upload is done in a multipart form that includes the binary data of the image, so I expect if we do image manipulation on the client, we can send that information back as a normal upload -- the same as we currently do, just resized, cropped, etc.

I'm still thinking about how to get to the original image once a user has done this, but that's for a different conversation.

[jejacks0n]

I spent a little time this evening writing up a test page to see if I could draw on a canvas and then save the contents to the server easily (I just pushed the results of this test).. Using some stuff that I already had in place for multipart forms this came out pretty quick. What this means is that we can do all the image resizing and cropping on the client and the server will only ever have to accept and store file uploads. I think this was the only aspect that I wasn't sure of, and now I'm confident this can happen.

The only lingering question is how to handle original images.. how does everyone feel about not handling original images? This keeps the server simple, and allows the user to keep his/her own originals.. but then if you have multiple users trying to share assets -- it gets complicated. But to try and keep it from being a whole system around that, I'd like to avoid it.. thoughts?

[balupton]

Keep the original image in localStorage and keep a copy on the server side. Use a data-original-image attribute on the <img> element. That way you support both client and server side resizing.

Thoughts?

[jejacks0n]

I may just keep it simple and not try and create an association with the original. Think of it more as a "we'll give you a few features so you don't have to open photoshop" feature. :)

[balupton]

Okay... so is that with just CSS resizing or with optimised/actual/canvas/whatever resizing?

The issue I see with optimised resizing is that it really needs an original, so when they accidentally resize the image very small, and want to take it back to big, it will be incredibly pixelated - having them to reinsert the original image and start again.

So either CSS resizing, then an optimised resizing with original reference, or both is good by me :)

Btw, I've included jQuery Resizable in my fork but can't seem to get it working for images - any idea why?

[jejacks0n]

I'm making this decision based on past experiences. What you're asking for requires additional server functionality, which as your fork suggests, should be minimized as much as possible. The uses I foresee, and what Mercury was written for, don't necessitate the feature you're suggesting, even though there's merit to it.

If we needed the functionality we would write a feature complete asset manager that has all of the features you're suggesting (and more), but it would not be part of Mercury. Mercury was written in coffeescript for this exact reason, and doesn't include every feature that I thought up in the process -- so it is easy to extend or adjust (believe me, I had lots of ideas that didn't make it in there). I just want to provide enough to get people editing content, and the rest is up to developers in their own projects.

Hopefully you see my point and don't take it as a rejection. I'm planning to add the basics of the solution that you suggested, which you can then run with. It seems like a good opportunity to see how plugins might be structured. =)

I'll be working on this, and you can re-raise any issues you may come across after it's been implemented, and in the meantime, I'll look into the jQuery resizable thing you mentioned.

[balupton]

Cool. Sounds good to me.

[microweber]

any news on this?

[arron3]

You mentioned that you had an image re-size feature disabled... how would one go about's enabling it? For my purposes, the re-size option as is would be fine....

[jejacks0n]

It only works in FF, as it's a native feature and I never wrote anything for it -- just disabled it for consistency.

it's line 40 in vendor/assets/javascripts/mercury/regions/editable.js.coffee.

@document.execCommand('enableObjectResizing', false, false)

You can hack that as you wish based on your setup.

[microweber]

Worked!! Thanks :)) Love you