php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22777 Imagick: NonconformingDrawingPrimitiveDefinition
Submitted: 2003-03-18 21:14 UTC Modified: 2005-09-23 15:32 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: ceo at l-i-e dot com Assigned: mcmontero (profile)
Status: Not a bug Package: *General Issues
PHP Version: 4.3.1 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ceo at l-i-e dot com
New email:
PHP Version: OS:

 

 [2003-03-18 21:14 UTC] ceo at l-i-e dot com
I was drawing cities/zips onto some maps using:

imagick_drawcircle
imagick_drawannotation

The calculation for x/y co-ordinates were yielding non-integral (float) numbers.

I kept getting intermittent (fairly frequent) errors:
Imagick Error: NonconformingDrawingPrimitiveDefinition

By calling round() on all args first, this error message went away.

I suspect something in the conversion of float to integer somewhere is failing on some numbers -- perhaps those with too many/few digits after the decimal??? :-v

The "description" sometimes contained: "circle" and sometimes contained numbers such as:
477.5
356.2
213.7
458
469.4
473.9
458.7
.
.
.

Perhaps, though, my source code was passing in PHP values that were beyond the scope of "float" -- -INF and INF, for example...

Even so -- the wrappers between PHP and Imagick should, IMHO, allow just about any PHP value and auto-convert it just as PHP always does.

An attempt to reduce the script down to a short sample yielded only another problem -- memory.

Why would this simple image/script chew up hundreds of meg of RAM?
http://ldsonline.com/imagickbug/

I tried it with both the image.jpg (beach scene) in the PHP /ext/magick/examples dir and the actual image I've been using.

I can only get memory errors, as displayed at the URL above (after you wait for the server to chew up several hundred megs of RAM...)

Oddly enough, in the longer, more complex script, the image works fine, once I round off all my numbers.  Dog-slow, but it works...

PERHAPS the real problem is attempting to draw to points outside the actual size of the image???

I'm sorry I'm flailing around here for a bug report, but it's the best I can do...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-18 21:25 UTC] ceo at l-i-e dot com
I added a comment and ended up on the edit submission page...

So I dunno if that comment went in or not...  Quick search didn't find it.

So, possibly repeating myself:

IGNORE the parts in this report about rounding numbers off "fixing" the problem.  The client changed the map images out from under me last night, and as soon as I scaled my long/lat numbers to match, up cropped the bug again.
 [2003-03-19 10:38 UTC] ceo at l-i-e dot com
Aha!

Hypothesis:
When the string argument to imagick_drawannotation contains a COMMA, it sometimes messes up the parsing engine of the Imagick module, and the args/primitives get skewed off by one.

By changing my code to not use "$city, $state" and using just "$city $state" instead, it seemed to fix the bug...

Maybe.

Though why it's intermittent, I'm not sure -- There must be some other boundary (string buffer?) condition kicking in...

Still flailing, aren't I?
 [2005-09-23 15:32 UTC] sniper@php.net
Report this to the pecl bug system: http://pecl.php.net/bugs/
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 17:01:58 2024 UTC