possible bug in -border X% in IM 6.7.8.6 Q16

[fmw42]

IM 6.7.8.6 Q16 Mac OSX Snow Leopard

see topic at viewtopic.php?f=1&t=21536#p88212

[magick]

You need -border 5x5%. Without the second value, the height is assigned to the width (i.e. -border 10x10 instead of the expected -border 10x8). If you think a single percent value should apply to both width and height, see if Anthony is in agreement and we'll add a patch.

[fmw42]

You need -border 5x5%. Without the second value, the height is assigned to the width (i.e. -border 10x10 instead of the expected -border 10x8). If you think a single percent value should apply to both width and height, see if Anthony is in agreement and we'll add a patch.

Thanks. I have no problem specifying both, though it is a bit confusing. So I would recommend making 5% be equivalent to 5x5%. I will send this to Anthony and see what he thinks. If the decision is to leave alone, I will modify the docs page for -border to clarify.

In the meantime I will explain to the user who posted the topic.

[Draoidh]

Seeing as I started this stooshie with my post, may I add some comments:

I thought this was rather amusing: Fred filed a bug report when he realized how -border <width> operated; when I, as a novice IM user, needed to create the border in above example, I didn't expect it to work they way it does but was delighted that it did exactly what I needed!

Please, don't change the behaviour of -border 5% to be equivalent to 5x5%! How else would you then create a border of equal width on all sides for a rectangular image?

[magick]

Good point. The behavior will remain intact then. A single percent argument specifies a width and height as a percentage of the width. Two values specifies a percent width and a percent height border.

[Draoidh]

Many thanks and thanks for a fantastic product!

A wee note in the -border option description wouldn't go amiss but it's no big deal. One can figure it out easily enough, or stumble upon it as I did.

[fmw42]

Good point. The behavior will remain intact then. A single percent argument specifies a width and height as a percentage of the width. Two values specifies a percent width and a percent height border.

Can I presume that specifying -border x5% would then be equal border, but based upon the height?

[Draoidh]

Strangely, no.

Code: Select all

convert \( -size 200x100 xc:red \)  -border x5% x.png

results in a 600x110 file

[fmw42]

Strangely, no.

Code: Select all

convert \( -size 200x100 xc:red \)  -border x5% x.png

results in a 600x110 file

I can confirm this:


convert \( -size 200x100 xc:red \) -border x5% -format "%w x %h" info:
600 x 110

But I have no idea why 600 rather than 210 or even 220? That seems like a bug, unless using xH% is not allowed.

[magick]

If you don't specify the width, it defaults to the image size. A border width of 200 x 2 added to an image width of 200 is 600. Its behaving as expected.

[fmw42]

If you don't specify the width, it defaults to the image size. A border width of 200 x 2 added to an image width of 200 is 600. Its behaving as expected.

OK. Thanks for the clarification.

So does that means there is no way to use % and use the height for the computation without doing -rotate 90 -border 5% -rotate -90?


If not, then it seems to me that it would be more consistent. if -border would honor the xH% and do the same on the height as it does when doing W%, rather than defaulting to the width of the image.

Anthony or Draoidh, do you have any opinion on this?

Whatever is decided, I will try to document it on the options page.

[anthony]

I do not see making xH% work in a similar way to W%x (or just W%) as a problem.
It would just make 'single value handling' for -border at least more symmetrical.
This can be done quite easily for IMv6 and IMv7

On the other hand I would think that a single value (with no 'x'), would mean 5% of width and 5% of height! That is actually what I've always assumed, but never actually tested!

Summery of what I think it should do...
-border 5% -- 5% of width and 5% of height!
-border 5%x -- 5% of width for both horizontal and vertical
-border x5% -- 5% of height for both horizontal and vertical
NOTE this is different to the actions of
-border 5%x0 -- only add 5% border to width
-border 0x5% -- only add 5% border to hight
-border 0x0 -- no border added -- just 'normal' border compose setting effects on image transparency.

The problem is that the 'geometry' handler will have to flag if an 'x' was provided or not for this to work!
And that is adding a new flag for a stable function, and a library API structure change that would limit such a change to IMv7 only.

NOTE: other operators may also have similar effects: -crop -chop -splice -raise
But also -resize type operators, which I think may already do something like this! -- test with '!' to turn of aspect ratio!

So what is decided for one, probably should become a 'rule of thumb' for other operators which can take either a single value or separate values. As such think carefully before suggesting we do something!


I'll add this to my ToDo, but no promises on a ETA.
I want to concentrate more on getting the major parts of IMv7 scripting complete.

[magick]

We can reproduce the problem you posted and have a patch. Look for it in ImageMagick 6.7.8-8 Beta by sometime tomorrow. Thanks.

[fmw42]

We can reproduce the problem you posted and have a patch. Look for it in ImageMagick 6.7.8-8 Beta by sometime tomorrow. Thanks.

Are you going to make xH% work on height for both like W% works on width for both. Or are you going to make X% work on each of width and height separately.

Don't forget the post above at viewtopic.php?f=3&t=21537#p88226

[magick]

The patch is available now. Give it a try.