[wp-trac] [WordPress Trac] #13556: wp_get_attachment_image() displays larger images than necessary with an array

WordPress Trac wp-trac at lists.automattic.com
Thu May 27 08:05:35 UTC 2010


#13556: wp_get_attachment_image() displays larger images than necessary with an
array
-----------------------------+----------------------------------------------
 Reporter:  tomthewebmaster  |        Owner:          
     Type:  defect (bug)     |       Status:  reopened
 Priority:  normal           |    Milestone:  3.0     
Component:  Media            |      Version:  3.0     
 Severity:  blocker          |   Resolution:          
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by markjaquith):

  * severity:  normal => blocker


Comment:

 {{{13556.off-by-one-pixel.diff}}} does the following:

 Instead of always using the smaller of the height/height, width/width
 ratios, it tries to see if the larger one will fit. If it does, great — it
 is likely the more "snug" fit. If it doesn't, it falls back to the smaller
 ratio.

 In either case, it then checks the dimensions that were resized, and for
 each, checks to see if the result is within one pixel of the max. If it
 is, it bumps up the resulting resize by one pixel (i.e. to the max).

 For example, before this patch, 465x700 in a 177x177 box was 117x176... a
 pixel short. After the patch, that 176 would become 177. One of the
 dimensions should equal one of the maxima. This seems to mostly (if not
 completely) eliminate the effect whereby an image constrained to a box,
 and then constrained to the result of that constraint, would become
 progressively more cropped. You'd get a stepping effect where with each
 constraint operation, a pixel or two would be shaved off. e.g. 100x199
 might become 99x199, which might become 99x198, etc. That causes a
 mismatch in the "next biggest image of the same ratio" check, which causes
 the full res image to be used instead (the whole point of this bug).

 To compensate for this possible one-pixel inflation, the "next biggest
 size that matches the ratio" check now has a -1 pixel area of forgiveness.
 This is so that a crops generated in earlier versions will match
 constraints done in 3.0.  So a 200x199 image in 2.9 will be used if 3.0 is
 looking for a 200x200 version of that image.

 Setting as a blocker, because I don't want an RC/final going out until
 this is resolved. Please test the patch!

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/13556#comment:16>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list