Last 7 days

• Dec 30, 2009

  FAQs (Frequently asked questions regarding implementing the croppe...) Wiki page edited by david.spurr   -   Revision r12 Edited wiki page through web user interface.

  Revision r12 Edited wiki page through web user interface.

Older

• Nov 26, 2009

  issue 34 (IE7 performance) reported by catalin.banu   -   IE7 stays on 100% cpu. Any ideea?

  IE7 stays on 100% cpu. Any ideea?
• Nov 13, 2009

  issue 33 (Allow ratios that *limit*, but don't *lock* an aspect ratio) commented on by ejsanders   -   Attached new diff against version 1.2.1 (above file is against 1.2.0).

  Attached new diff against version 1.2.1 (above file is against 1.2.0).
• Nov 13, 2009

  issue 33 (Allow ratios that *limit*, but don't *lock* an aspect ratio) commented on by ejsanders   -   Attached new diff against version 1.2.1 (above file is against 1.2.0).

  Attached new diff against version 1.2.1 (above file is against 1.2.0).
• Nov 13, 2009

  issue 33 (Allow ratios that *limit*, but don't *lock* an aspect ratio) reported by ejsanders   -   Consider a site (e.g. Facebook) where an profile picture is of a fixed width (W), but cannot exceed a certain height (H). This requires a cropper than limits the crop to any ratio R such that R <= W/H. This can be presented the user as an option to allow the ratio to be "wider", "taller" or "exactly the same" as the given value. Attached patch implements this as a initialisation option "ratioType".

  Consider a site (e.g. Facebook) where an profile picture is of a fixed width (W), but cannot exceed a certain height (H). This requires a cropper than limits the crop to any ratio R such that R <= W/H. This can be presented the user as an option to allow the ratio to be "wider", "taller" or "exactly the same" as the given value. Attached patch implements this as a initialisation option "ratioType".
• Oct 08, 2009

  issue 32 (IE7: crop values do not update for newly loaded images) commented on by david.spurr   -   No the crop manager is just an example of how to keep a reference to the cropper and change the image, you can either use that and add your customisations or simply use the ideas from it.

  No the crop manager is just an example of how to keep a reference to the cropper and change the image, you can either use that and add your customisations or simply use the ideas from it.
• Oct 08, 2009

  issue 32 (IE7: crop values do not update for newly loaded images) commented on by rismaril   -   That seems to work as it did in the demo. But how can I reset the cropper from my own function updateImgLarge? Do I have to use the cropmanager?

  That seems to work as it did in the demo. But how can I reset the cropper from my own function updateImgLarge? Do I have to use the cropmanager?
• Oct 08, 2009

  issue 32 (IE7: crop values do not update for newly loaded images) commented on by david.spurr   -   Have you tried following the example in the dynamic image test (e.g. using a manager to add/update the cropper settings)

  Have you tried following the example in the dynamic image test (e.g. using a manager to add/update the cropper settings)
• Oct 08, 2009

  issue 32 (IE7: crop values do not update for newly loaded images) reported by rismaril   -   What steps will reproduce the problem? This is my set up: 1: I upload an image that is passed to a php file through an iFrame. 2: The uploaded image is being processed by the php file and returns the result to the js function "updateImgLarge" 3: updateImgLarge creates a new image element and puts the newly uploaded file as the src. then it loads the js function "loadCropper". 4: then you can crop the image and save the thumbnail by submitting the crop values to a php file that creates the image. What is the expected output? What do you see instead? After cropping the first image and uploading a second image, the cropping values do not change. You can adjust the cropping rectangle but the values stay the same as the previous crop that you made with the other image. As a result when hitting the upload thumbnail button you will get a crop of the new image but with the same coordinates as the first image that you cropped. This only happens in IE7, it works fine in FF and Chrome. I did not test it in IE8. What version of the product are you using? On what operating system? I am using the same version as in the demo file on Windows Vista 64. Please provide any additional information below. Some of the code that I used: <script type="text/javascript" language="javascript"> function updateImgLarge(img_src, w, h, img_name){ document.getElementById("testWrap").innerHTML = ""; var newImg = document.createElement("img"); document.getElementById("testWrap").appendChild (newImg); newImg.src = img_src; newImg.width = w; newImg.height = h; newImg.id = "testImage"; document.crop_img.reset(); document.getElementById('th_file_ext').value = img_name; loadCropper(); } function onEndCrop( coords, dimensions ) { $( 'x1' ).value = coords.x1; $( 'y1' ).value = coords.y1; $( 'x2' ).value = coords.x2; $( 'y2' ).value = coords.y2; $( 'width' ).value = dimensions.width; $( 'height' ).value = dimensions.height; } function loadCropper(){ new Cropper.ImgWithPreview( 'testImage', { previewWrap: 'previewWrap', minWidth: 120, minHeight: 120, ratioDim: { x: 120, y: 120 }, onEndCrop: onEndCrop } ); } </script> <span class="iframe_container"> <iframe id="submit_target" name="submit_target" src="#" style="width:0;height:0;border:0px solid #000;"></iframe> </span> <form action="img_functions.php" method="post" target="submit_target" enctype="multipart/form-data"> <h2>Upload Photo</h2> Photo <input type="file" name="image" size="30" /> <input type="hidden" name="upload" /> <input type="submit" value="upload!" /> </form> <br /><br /> <div id="testWrap"> </div> <div id="previewOuterWrap"> <h2>Crop preview:</h2> <div id="previewWrap"></div> </div> <span class="clear_float"></span> <form name="crop_img" id="crop_img" action="img_functions.php" method="post" target="submit_target"> <div id="results"> <h2>Crop values:</h2> <div> <label for="x1">x1:</label> <input type="text" name="x1" id="x1" size="4" /> </div> <div> <label for="y1">y1:</label> <input type="text" name="y1" id="y1" size="4" /> </div> <div> <label for="x2">x2:</label> <input type="text" name="x2" id="x2" size="4" /> </div> <div> <label for="y2">y2:</label> <input type="text" name="y2" id="y2" size="4" /> </div> <div> <label for="width">width:</label> <input type="text" name="width" id="width" size="4" /> </div> <div> <label for="height">height:</label> <input type="text" name="height" id="height" size="4" /> </div> </div> <input type="hidden" name="file_ext" value="" id="th_file_ext" /> <br /> <input type="submit" name="upload_thumbnail" value="upload!" /> </form>

  What steps will reproduce the problem? This is my set up: 1: I upload an image that is passed to a php file through an iFrame. 2: The uploaded image is being processed by the php file and returns the result to the js function "updateImgLarge" 3: updateImgLarge creates a new image element and puts the newly uploaded file as the src. then it loads the js function "loadCropper". 4: then you can crop the image and save the thumbnail by submitting the crop values to a php file that creates the image. What is the expected output? What do you see instead? After cropping the first image and uploading a second image, the cropping values do not change. You can adjust the cropping rectangle but the values stay the same as the previous crop that you made with the other image. As a result when hitting the upload thumbnail button you will get a crop of the new image but with the same coordinates as the first image that you cropped. This only happens in IE7, it works fine in FF and Chrome. I did not test it in IE8. What version of the product are you using? On what operating system? I am using the same version as in the demo file on Windows Vista 64. Please provide any additional information below. Some of the code that I used: <script type="text/javascript" language="javascript"> function updateImgLarge(img_src, w, h, img_name){ document.getElementById("testWrap").innerHTML = ""; var newImg = document.createElement("img"); document.getElementById("testWrap").appendChild (newImg); newImg.src = img_src; newImg.width = w; newImg.height = h; newImg.id = "testImage"; document.crop_img.reset(); document.getElementById('th_file_ext').value = img_name; loadCropper(); } function onEndCrop( coords, dimensions ) { $( 'x1' ).value = coords.x1; $( 'y1' ).value = coords.y1; $( 'x2' ).value = coords.x2; $( 'y2' ).value = coords.y2; $( 'width' ).value = dimensions.width; $( 'height' ).value = dimensions.height; } function loadCropper(){ new Cropper.ImgWithPreview( 'testImage', { previewWrap: 'previewWrap', minWidth: 120, minHeight: 120, ratioDim: { x: 120, y: 120 }, onEndCrop: onEndCrop } ); } </script> <span class="iframe_container"> <iframe id="submit_target" name="submit_target" src="#" style="width:0;height:0;border:0px solid #000;"></iframe> </span> <form action="img_functions.php" method="post" target="submit_target" enctype="multipart/form-data"> <h2>Upload Photo</h2> Photo <input type="file" name="image" size="30" /> <input type="hidden" name="upload" /> <input type="submit" value="upload!" /> </form> <br /><br /> <div id="testWrap"> </div> <div id="previewOuterWrap"> <h2>Crop preview:</h2> <div id="previewWrap"></div> </div> <span class="clear_float"></span> <form name="crop_img" id="crop_img" action="img_functions.php" method="post" target="submit_target"> <div id="results"> <h2>Crop values:</h2> <div> <label for="x1">x1:</label> <input type="text" name="x1" id="x1" size="4" /> </div> <div> <label for="y1">y1:</label> <input type="text" name="y1" id="y1" size="4" /> </div> <div> <label for="x2">x2:</label> <input type="text" name="x2" id="x2" size="4" /> </div> <div> <label for="y2">y2:</label> <input type="text" name="y2" id="y2" size="4" /> </div> <div> <label for="width">width:</label> <input type="text" name="width" id="width" size="4" /> </div> <div> <label for="height">height:</label> <input type="text" name="height" id="height" size="4" /> </div> </div> <input type="hidden" name="file_ext" value="" id="th_file_ext" /> <br /> <input type="submit" name="upload_thumbnail" value="upload!" /> </form>
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by D...@Newfield.org   -   Thanks for taking the time to understand this -- sorry it wasn't clearer to begin with. :-)

  Thanks for taking the time to understand this -- sorry it wasn't clearer to begin with. :-)
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by david.spurr   -   Ah-ha I fully understand you now. However I do respectfully disagree that it should work in the way you suggest. I think would find myself moving the cropper around more using your way. It's a compromise neither are 100% correct and it entirely depends on the situation which way you would want it to work as an end user. So I won't be implementing this request.

  Ah-ha I fully understand you now. However I do respectfully disagree that it should work in the way you suggest. I think would find myself moving the cropper around more using your way. It's a compromise neither are 100% correct and it entirely depends on the situation which way you would want it to work as an end user. So I won't be implementing this request.
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by D...@Newfield.org   -   http://www.defusion.org.uk/demos/060519/cropper.php? demoType=ratioFourThree&image=castle&formSubmit=Load+demo If you drag any of the corners, the opposite one remains stationary. If you drag the top edge, the lower left corner remains stationary (instead of the lower edge center marker). If you drag the right edge or the bottom edge, the top left corner remains stationary (instead of the left/top edge center markers, respectively). If you drag the left edge the top right corner remains stationary (instead of the right edge center marker).

  http://www.defusion.org.uk/demos/060519/cropper.php? demoType=ratioFourThree&image=castle&formSubmit=Load+demo If you drag any of the corners, the opposite one remains stationary. If you drag the top edge, the lower left corner remains stationary (instead of the lower edge center marker). If you drag the right edge or the bottom edge, the top left corner remains stationary (instead of the left/top edge center markers, respectively). If you drag the left edge the top right corner remains stationary (instead of the right edge center marker).
• Oct 06, 2009

  issue 23 (Change Dimension without Loading) changed by david.spurr   -   Please add more information for requirements and I will consider adding this as a feature.

  Status: Invalid

  Labels: Type-Enhancement −Type-Defect

  Please add more information for requirements and I will consider adding this as a feature.

  Status: Invalid

  Labels: Type-Enhancement −Type-Defect
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by david.spurr   -   "If you move a corner the opposite corner shouldn't move." - It doesn't "If you move an edge, the opposite edge shouldn't move." - It doesn't Dale, please provide an example if you are getting different functionality

  "If you move a corner the opposite corner shouldn't move." - It doesn't "If you move an edge, the opposite edge shouldn't move." - It doesn't Dale, please provide an example if you are getting different functionality
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by D...@Newfield.org   -   If you move a corner the opposite corner shouldn't move. If you move an edge, the opposite edge shouldn't move. So this example: "Otherwise, what if you got the top left exactly where you want it but wanted the bottom right moving a little bit. With your suggested change the top left would move." isn't a good counter-example. For moving corners it already does "the right thing", and the top right would NOT move. I'm not suggesting that the behavior for moving a corner should change. Just the behavior when you drag the edge of an aspect ratio constrained selection. Again, not a critical thing to address, just a nice-to-have.

  If you move a corner the opposite corner shouldn't move. If you move an edge, the opposite edge shouldn't move. So this example: "Otherwise, what if you got the top left exactly where you want it but wanted the bottom right moving a little bit. With your suggested change the top left would move." isn't a good counter-example. For moving corners it already does "the right thing", and the top right would NOT move. I'm not suggesting that the behavior for moving a corner should change. Just the behavior when you drag the edge of an aspect ratio constrained selection. Again, not a critical thing to address, just a nice-to-have.
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by david.spurr   -   Ah-ha, I see what you mean now. However the way that my cropper works is exactly as it works in Photoshop and I believe this is the expected behaviour. Otherwise, what if you got the top left exactly where you want it but wanted the bottom right moving a little bit. With your suggested change the top left would move. It could be an option I suppose but in most cases this would not be the desired behaviour.

  Ah-ha, I see what you mean now. However the way that my cropper works is exactly as it works in Photoshop and I believe this is the expected behaviour. Otherwise, what if you got the top left exactly where you want it but wanted the bottom right moving a little bit. With your suggested change the top left would move. It could be an option I suppose but in most cases this would not be the desired behaviour.
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by D...@Newfield.org   -   Ah! The critical bit I left out is that this is all dependent upon being in the fixed aspect ratio mode (for me it's "keep square").

  Ah! The critical bit I left out is that this is all dependent upon being in the fixed aspect ratio mode (for me it's "keep square").
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by david.spurr   -   I'm still very confused, here's what happens when moving handles, which I believe is the expected behaviour and would not astonish anyone. - Moving a horizontal only handle, the horizontal edge it belongs to moves in the given direction of movement. No other edges move. - Moving a vertical only handle, the vertical edge it belongs to moves in the given direction of movement. No other edges move. - Moving a corner (horizonal & vertical) handle, the vertical & horizontal edges it belongs to move in the given direction(s) of movement. No other edges move.

  I'm still very confused, here's what happens when moving handles, which I believe is the expected behaviour and would not astonish anyone. - Moving a horizontal only handle, the horizontal edge it belongs to moves in the given direction of movement. No other edges move. - Moving a vertical only handle, the vertical edge it belongs to moves in the given direction of movement. No other edges move. - Moving a corner (horizonal & vertical) handle, the vertical & horizontal edges it belongs to move in the given direction(s) of movement. No other edges move.
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by D...@Newfield.org   -   The top drawing in those two makes sense if you were dragging the bottom right corner. If you're dragging the middle of the right edge that behavior violates <a href="http://en.wikipedia.org/wiki/Principle_of_least_astonishment">the principle of least astonishment</a>, since users expect it to behave like the bottom drawing. Basically the handle you're moving doesn't go where the user moves it to (but rather slides down from there). The point of reference (anchor point against which changes should be compared) should be the corner or edge opposite the one being moved. This works for corners, but for edges the choice of the corner as an anchor point is confusing to my users. It's really not a bug, just a behavior that doesn't match users' expectations. If you're not going to fix it, that's a reasonable answer, but saying you don't follow makes me want to keep trying to explain it :-)

  The top drawing in those two makes sense if you were dragging the bottom right corner. If you're dragging the middle of the right edge that behavior violates <a href="http://en.wikipedia.org/wiki/Principle_of_least_astonishment">the principle of least astonishment</a>, since users expect it to behave like the bottom drawing. Basically the handle you're moving doesn't go where the user moves it to (but rather slides down from there). The point of reference (anchor point against which changes should be compared) should be the corner or edge opposite the one being moved. This works for corners, but for edges the choice of the corner as an anchor point is confusing to my users. It's really not a bug, just a behavior that doesn't match users' expectations. If you're not going to fix it, that's a reasonable answer, but saying you don't follow makes me want to keep trying to explain it :-)
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by david.spurr   -   I'm sorry that doesn't clarify it any further for me. I'm really not following what the issue is.

  I'm sorry that doesn't clarify it any further for me. I'm really not following what the issue is.
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) commented on by D...@Newfield.org   -   The easiest way to illustrate this is with a couple drawings:

  The easiest way to illustrate this is with a couple drawings:
• Oct 06, 2009

  issue 27 (Scroll offset problem when using in modal panel) Status changed by david.spurr   -   This suggestion has been incorporated into the latest release (1.2.1)

  Status: Fixed

  This suggestion has been incorporated into the latest release (1.2.1)

  Status: Fixed
• Oct 06, 2009

  issue 21 (Cropper components not transparent, blocking image -- when i...) Status changed by david.spurr   -   Tested latest version (1.2.1, will be released shortly) and it works fine.

  Status: Fixed

  Tested latest version (1.2.1, will be released shortly) and it works fine.

  Status: Fixed
• Oct 06, 2009

  issue 16 (Better "fixed point" management on constrained edge drags.) Status changed by david.spurr   -   Can't replicate

  Status: WontFix

  Can't replicate

  Status: WontFix
• Oct 06, 2009

  issue 8 (Hardcoded reference to cropper.js for dynamic includes) Status changed by david.spurr   -  

  Status: Fixed

  Status: Fixed
• Oct 06, 2009

  issue 15 (Initializing cropper on gif animations) Status changed by david.spurr   -   Can't replicate

  Status: WontFix

  Can't replicate

  Status: WontFix
• Oct 06, 2009

  issue 13 (Version 1.2.0 doesn't work on Opera) Status changed by david.spurr   -   Tested latest version (1.2.1) in Opera and it works fine

  Status: Fixed

  Tested latest version (1.2.1) in Opera and it works fine

  Status: Fixed
• Oct 06, 2009

  issue 11 (The image that is to be cropped does not show in IE6.0) Status changed by david.spurr   -   The change to the CSS is included in the latest version 1.2.1, which will be released shortly

  Status: Fixed

  The change to the CSS is included in the latest version 1.2.1, which will be released shortly

  Status: Fixed
• Oct 06, 2009

  issue 7 (onEndCrop not called after moving area with keyboard) Status changed by david.spurr   -  

  Status: Fixed

  Status: Fixed
• Oct 06, 2009

  issue 7 (onEndCrop not called after moving area with keyboard) commented on by david.spurr   -   Fixed in version 1.2.1 which will be released shortly

  Fixed in version 1.2.1 which will be released shortly
• Oct 06, 2009

  issue 6 (IE7 when constructor called from inside a method a white ove...) Status changed by david.spurr   -   Can't replicate

  Status: WontFix

  Can't replicate

  Status: WontFix
• Oct 06, 2009

  issue 26 (IE 8 issue...) Status changed by david.spurr   -   Latest version (1.2.1) tested & working in IE 8. It will be released shortly

  Status: Fixed

  Latest version (1.2.1) tested & working in IE 8. It will be released shortly

  Status: Fixed
• Oct 06, 2009

  issue 22 (Cropper object is not created due to a crash at the beginnin...) Status changed by david.spurr   -   The ability to skip auto-include of JS is added in 1.2.1 which will be released shortly

  Status: Fixed

  The ability to skip auto-include of JS is added in 1.2.1 which will be released shortly

  Status: Fixed
• Oct 06, 2009

  issue 30 (Not working with Firefox 3.5 on OSX) Status changed by david.spurr   -   This is fixed in v1.2.1 which will be released later today

  Status: Fixed

  This is fixed in v1.2.1 which will be released later today

  Status: Fixed
• Oct 06, 2009

  issue 28 (Not working with Scriptacoulous 1.8.2) Status changed by david.spurr   -   Fixed in v1.2.1 - to be released later today

  Status: Fixed

  Fixed in v1.2.1 - to be released later today

  Status: Fixed
• Oct 06, 2009

  issue 2 (Navigator) Status changed by david.spurr   -   Not a priority feature anymore

  Status: WontFix

  Not a priority feature anymore

  Status: WontFix
• Oct 06, 2009

  issue 1 (Allow Zooming) Status changed by david.spurr   -   This is not a priority

  Status: WontFix

  This is not a priority

  Status: WontFix
• Oct 05, 2009

  issue 30 (Not working with Firefox 3.5 on OSX) commented on by dblue.sv   -   I came across this on Windows Firefox 3.5 and found this when I came here to report it. In case you haven't had time to look into a fix yet, it worked for me to do 2 things: 1. update Prototype.js to 1.6.1, and 2. change line 58 of cropper.js from $A(document.getElementsByTagName("script")).each(function(s){ to $$('script').each(function(s){ Either of those alone didn't do it. These changes don't seem to break IE8, Opera 10, or Safari 4 on Vista though I haven't tested on any Mac or *nix browsers yet. hope this helps.

  I came across this on Windows Firefox 3.5 and found this when I came here to report it. In case you haven't had time to look into a fix yet, it worked for me to do 2 things: 1. update Prototype.js to 1.6.1, and 2. change line 58 of cropper.js from $A(document.getElementsByTagName("script")).each(function(s){ to $$('script').each(function(s){ Either of those alone didn't do it. These changes don't seem to break IE8, Opera 10, or Safari 4 on Vista though I haven't tested on any Mac or *nix browsers yet. hope this helps.
• Aug 23, 2009

  issue 31 (Polygon gates) commented on by david.spurr   -   No I'm afraid I don't. It's not really possible in HTML direct, you might want to look at something that uses the canvas element or SVG (or alternatively something in Flash).

  No I'm afraid I don't. It's not really possible in HTML direct, you might want to look at something that uses the canvas element or SVG (or alternatively something in Flash).
• Aug 23, 2009

  issue 31 (Polygon gates) commented on by benjamin...@umit.at   -   Do you know any other toolkit which fits my requirements? And thanks for your quick answers...

  Do you know any other toolkit which fits my requirements? And thanks for your quick answers...
• Aug 23, 2009

  issue 31 (Polygon gates) commented on by david.spurr   -   That's not really possible with the cropper as it is designed to work. That would be an entirely new project and is not something that will be added to the cropper.

  That's not really possible with the cropper as it is designed to work. That would be an entirely new project and is not something that will be added to the cropper.
• Aug 23, 2009

  issue 31 (Polygon gates) commented on by benjamin...@umit.at   -   At the moment it is only possible to select rectangles. I'd need to select a polygon with 5 corners.

  At the moment it is only possible to select rectangles. I'd need to select a polygon with 5 corners.
• Aug 23, 2009

  issue 30 (Not working with Firefox 3.5 on OSX) Status changed by david.spurr   -  

  Status: Accepted

  Status: Accepted
• Aug 23, 2009

  issue 30 (Not working with Firefox 3.5 on OSX) commented on by david.spurr   -   This is an issue with the bit that includes the stylesheet dynamically. I am planning a fix release for this, but for now just remove that bit and include the stylesheet manually.

  This is an issue with the bit that includes the stylesheet dynamically. I am planning a fix release for this, but for now just remove that bit and include the stylesheet manually.
• Aug 23, 2009

  issue 31 (Polygon gates) Status changed by david.spurr   -   Not sure what the request is asking for.

  Status: Invalid

  Not sure what the request is asking for.

  Status: Invalid
• Aug 23, 2009

  issue 31 (Polygon gates) reported by benjamin...@umit.at   -   Could you extend your toolkit so that it can handle polygon ROIs?

  Could you extend your toolkit so that it can handle polygon ROIs?
• Aug 19, 2009

  issue 11 (The image that is to be cropped does not show in IE6.0) commented on by rustam.bogubaev   -   change in cropper.css below block from : ----------------- previous ----------------- .imgCrop_wrap, .imgCrop_wrap * { font-size: 0; } to ----------------- fixed ----------------- .imgCrop_wrap, .imgCrop_wrap * { font-size: 0; opacity: 1; filter:alpha(opacity=100); } IE inherits css properties from parents, so in order to show image to be cropped, you have to strictly specify all child elements opacity as 100% in imgCrop_wrap div. rustam bogubaev

  change in cropper.css below block from : ----------------- previous ----------------- .imgCrop_wrap, .imgCrop_wrap * { font-size: 0; } to ----------------- fixed ----------------- .imgCrop_wrap, .imgCrop_wrap * { font-size: 0; opacity: 1; filter:alpha(opacity=100); } IE inherits css properties from parents, so in order to show image to be cropped, you have to strictly specify all child elements opacity as 100% in imgCrop_wrap div. rustam bogubaev
• Aug 17, 2009

  issue 30 (Not working with Firefox 3.5 on OSX) commented on by teamroundegg   -   it's also not working on windows too.. can someone please provide a solution

  it's also not working on windows too.. can someone please provide a solution
• Jul 28, 2009

  issue 30 (Not working with Firefox 3.5 on OSX) reported by adamgamble   -   What steps will reproduce the problem? 1. Install firefox 3.5 2. Open example What is the expected output? What do you see instead? You can see the image, but no cropper interface on top. What version of the product are you using? On what operating system? OS X 10.5.7 Firefox 3.5

  What steps will reproduce the problem? 1. Install firefox 3.5 2. Open example What is the expected output? What do you see instead? You can see the image, but no cropper interface on top. What version of the product are you using? On what operating system? OS X 10.5.7 Firefox 3.5
• Jul 17, 2009

  FAQs (Frequently asked questions regarding implementing the croppe...) Wiki page commented on by TeikkMind   -   Hi, Nice work and very easy to use with coldfusion. I would like to integrate this cropper for a web site which is working on a server with coldfusion 7 but I can't use neither cfimage or imageCrop() because they have been implemented for coldfusion 8. Any idea about How I could do?

  Hi, Nice work and very easy to use with coldfusion. I would like to integrate this cropper for a web site which is working on a server with coldfusion 7 but I can't use neither cfimage or imageCrop() because they have been implemented for coldfusion 8. Any idea about How I could do?