Legacy ImageMagick Discussions Archive

IM 6.7.7.7 Q16 (hdri) Mac OSX Snow Leopard

String format %X and %Y are not including signs contrary to http://www.imagemagick.org/script/escape.php where it says:

%X page (canvas) x offset (including sign)
%Y page (canvas) y offset (including sign)


convert -size 100x100 xc:black -size 50x50 xc:white -gravity center -composite -trim test.gif
identify -format "%X%Y" test.gif
2525

but should be

+25+25

Are the string formats %X and %Y supposed to include the signs or is the documentation wrong?
______________

I know that %O works and is a workaround

identify -format "%O" test.gif
+25+25

Look for a patch in ImageMagick 6.7.7-8 Beta by sometime tomorrow. Thanks.

Probably my bad, it will be in both IMv6 and IMv7

anthony wrote:Probably my bad, it will be in both IMv6 and IMv7

I have no problem with the change. I just need to know what version it happened. There is no point going backwards and reverting it (although that would then match what is used for -fx), since some releases will have one notation and others a different one. So I need to find the release where it changed and just put version traps in my scripts.

The change log shows I submited the settings update on... IM v6.7.6-9 and v6.7.6-10
The later is probably the one where the bug was introduced.

Extracting versions from the SVN (thanks to SVN revision numbers now placed in changelog, 7812 and 7952 ) and looking would be the only true way of finding out exactly which release it was. Checking the releases before and after these would confirm the versions.

NOTE: Before that in v6.7.6-7 (SVN 7587), geometry arguments understand the offset syntax +-10+-10
that is you can just use +$X+$Y in shell regardless of if the number is negative or not.
It was one of your requests.

STRANGE: This fails! It should be working...
I'll see what I can do, when I get some time.

anthony wrote:The change log shows I submited the settings update on... IM v6.7.6-9 and v6.7.6-10
The later is probably the one where the bug was introduced.

Extracting versions from the SVN (thanks to SVN revision numbers now placed in changelog, 7812 and 7952 ) and looking would be the only true way of finding out exactly which release it was. Checking the releases before and after these would confirm the versions.

NOTE: Before that in v6.7.6-7 (SVN 7587), geometry arguments understand the offset syntax +-10+-10
that is you can just use +$X+$Y in shell regardless of if the number is negative or not.
It was one of your requests.

Yes it was my suggestion and I appreciate the fix.

Not sure I follow, when did you allow +- syntax, that is if X is a negative value that one could still use WxH+X+Y and not have it object to the negative value (without having to take the absolute value for X and then use -X)

In any case, my bug was really about the string format not putting in the + sign. That is

convert -size 100x100 xc:black -size 50x50 xc:white -gravity center -composite -trim test.gif
identify -format "%X%Y" test.gif
2525

but should be

+25+25

magick wrote:Look for a patch in ImageMagick 6.7.7-8 Beta by sometime tomorrow. Thanks.

I do not yet see this fix in IM 6.7.7.8 beta. Not urgent. Just checking.



convert -size 100x100 xc:black -size 50x50 xc:white -gravity center -composite -trim test.gif
identify -format "%X%Y" test.gif
2525

With 6.7.7-8 Beta, we get:

• convert -size 100x100 xc:black -size 50x50 xc:white -gravity center -composite -trim test.gif
  identify -format "%X%Y" test.gif
  +25+25

magick wrote:With 6.7.7-8 Beta, we get:

• convert -size 100x100 xc:black -size 50x50 xc:white -gravity center -composite -trim test.gif
  identify -format "%X%Y" test.gif
  +25+25

Thanks. You are right. I was accidentally testing with IM 6.7.7.7. Forgot to preface with im6b.

Sorry for the false alarm.

Thanks for the fix.

I added the geometry parse fixes so that IM now accepts two (actually any) number of sign characters before the offset numbers.

As such, this works fine (both IMv6 and IMv7) But also this (which was what was broken) Note that the order of the signs does not matter! positive then negative, or, negative then positive!

NOTE also the using a double negative "--30" will be handled correctly too. That is as a positive"+30"!
That is you can negate the number string substitution without problem, and it will still come out right!

as such will work as you would expect! EG: substitute -> "--30+-20" -> "+30-20").

This should also be useful for global percent substitutions (another form of string substitution) in IMv7.

Not to be picky as that is great. But what happens if it sees multiple + signs, such as ++?

It handles it too. result is a positive.

actually ANY number of signs can be used. It just loops over + and - charcaters, and 'flips' the sign flag when it sees a - until it finds something else, then looks for the number (whcih will now be a positive, as the signs were pre-read). Afterwards it negates the number depending on the sign flag for that number.