[wp-trac] [WordPress Trac] #18532: resized image dimensions incorrectly floored instead of rounded
WordPress Trac
wp-trac at lists.automattic.com
Thu Sep 1 00:14:12 UTC 2011
#18532: resized image dimensions incorrectly floored instead of rounded
--------------------------+------------------------------
Reporter: _ck_ | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Media | Version: 2.5
Severity: normal | Resolution:
Keywords: |
--------------------------+------------------------------
Changes (by scribu):
* version: => 2.5
Old description:
> Since WP 2.5 no one has noticed this, not sure if I am surprised.
>
> Image dimensions are incorrectly floored instead of rounded to a proper
> number. Some attempt at "fixup" is done later in some processes to move
> them by a pixel, but still the way it's initially calculated is wrong.
>
> '''For example:
>
> A typical photo has a 3:2 (3/2 = 1.5) ratio.
>
> If it's resized to 600px width, WP will make the height 399px - this is
> wrong.'''
>
> It happens because of ''function wp_constrain_dimensions'' in
> ''media.php'' (~line 304) which floors the float using intval, which is
> wrong.
>
> {{{
> $w = intval( $current_width * $ratio );
> $h = intval( $current_height * $ratio );
> }}}
>
> '''I propose'''
>
> {{{
> $w = round( $current_width * $ratio );
> $h = round( $current_height * $ratio );
> }}}
>
> Earlier in the function, both $ratio and $current_width are already
> handled as numbers, so they have to be valid numbers, no need to use
> intval for that reason, it's just being used to floor, which is bad in
> this case.
>
> Using round is not a performance issue because this function is not used
> in realtime output for templates but typically in admin area.
>
> Optionally while you are at it, put a filter on wp_constrain_dimensions
> and pass the filter all the values passed to the function before the
> array is returned at the end.
New description:
Image dimensions are incorrectly floored instead of rounded to a proper
number. Some attempt at "fixup" is done later in some processes to move
them by a pixel, but still the way it's initially calculated is wrong.
'''For example:
A typical photo has a 3:2 (3/2 = 1.5) ratio.
If it's resized to 600px width, WP will make the height 399px - this is
wrong.'''
It happens because of ''function wp_constrain_dimensions'' in
''media.php'' (~line 304) which floors the float using intval, which is
wrong.
{{{
$w = intval( $current_width * $ratio );
$h = intval( $current_height * $ratio );
}}}
'''I propose'''
{{{
$w = round( $current_width * $ratio );
$h = round( $current_height * $ratio );
}}}
Earlier in the function, both $ratio and $current_width are already
handled as numbers, so they have to be valid numbers, no need to use
intval for that reason, it's just being used to floor, which is bad in
this case.
Using round is not a performance issue because this function is not used
in realtime output for templates but typically in admin area.
Optionally while you are at it, put a filter on wp_constrain_dimensions
and pass the filter all the values passed to the function before the array
is returned at the end.
--
--
Ticket URL: <http://core.trac.wordpress.org/ticket/18532#comment:1>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list