Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.
I get a wierd pointy-thing above my "n" when running imagemagick's annotate - when working with the placement of JUST that letter... (using the Impact.ttf font file):
convert -size 320x100 xc:none -font Impact.ttf -pointsize 48 -fill white \
-stroke black -strokewidth 25 -annotate +25+75 'n' \
test_n.png
the "N" appears but I get this wierd ARROW/POINT to the upper-rigiht when I put in a strokewidth... it seems to occur at strokewidth's greater than 7 or so...
When writing same code as ABOVE - including the same FONTSIZE of 25 - but instead of just "n" I make it 'Download' - and it all writes out with teh thick strokewidth - without any issues... it's only when I place the "n" in particular.
anthony wrote:The 'pointy' bit is being caused by the font defination for the strokes. IM has no control of this.
Why do you want to use such a large stroke width anyway?
There may be other solutions that could work better.
I'm open to looking into it... but i've worked on a very slick kerning php combo with imagemagick using the annotate feature... and it is heavily based on the -annotate feature.
suggested others to use?!
i use that one becuase of it's multifeatured uses... i used to use '-draw' but now like the -annotate as it's overruled the draw in so many text usages... i use gradients to fill text quite a bit
in fact, I built a whole app around it and it went like hotcakes
so, i'd like to use the annotate feature... but i'm VERY open to suggestions... i take each letter, get the boundingbox (using IM not imagettftext - that's incorrect) and work the magick in letter placement using kerning
Sorry the problem is probably being caused by the font rendering library an not IM itself.
I would suggest you re-post the problme in the BUGS forum, but with image example showing the output being produced with an increasing stroke-width size. The 'point' started to become visible at a value 5. This example should make it clear about the 'needle' that is a problem.
The only other suggestion is to pass this to the font rendering library group, who may be able to help you more.
Of course you sould use a different font too!
Can you check to see is a windows version of IM produces the same problem?
I see the same effect using other fonts: Arial, Verdana, etc, but to a lesser degree. But once your strokewidth gets too large, it starts to show this pointy thing. I suspect it has to do with such a large strokewidth causing funny overlapping of widely varying parts of the fonts.
Actually I suspect it is the way the vector edge is being drawn by the font library. Probably a bad 'stroke-miterlimit' setting or something like that.
anthony wrote:Actually I suspect it is the way the vector edge is being drawn by the font library. Probably a bad 'stroke-miterlimit' setting or something like that.
anthony wrote:Actually I suspect it is the way the vector edge is being drawn by the font library. Probably a bad 'stroke-miterlimit' setting or something like that.
well, i'm actually using Annotate ...hmmm any other suggestions?
alright, based on what you've stated, i think i've gotten it to work the way I want it... i don't really like moving from -annotate to -draw, bcz it seems to take a lot more time to use the -draw command versus the annotate...
At this time no. Though I am suprised that -draw does work!!! As it means that IM is itself 'drawing' the font!
Speed issue is more likely caused by the setup and parsing of the 'draw' environment, because internally both annotate and draw should be using the same internal function.
As I mentioned I would make a bug report, as it is likely that the stroke setting defaults for -annotate are not defined, and is the cause of the problem.
anthony wrote:At this time no. Though I am suprised that -draw does work!!! As it means that IM is itself 'drawing' the font!
Speed issue is more likely caused by the setup and parsing of the 'draw' environment, because internally both annotate and draw should be using the same internal function.
As I mentioned I would make a bug report, as it is likely that the stroke setting defaults for -annotate are not defined, and is the cause of the problem.
hmmm... too bad the -annotate command doesn't make use of the "-draw "stroke-linejoin round stroke-miterlimit 1 " stuff.
Oh well, got it working and it's slick {toot! toot!}
anthony wrote:At this time no. Though I am suprised that -draw does work!!! As it means that IM is itself 'drawing' the font!
Speed issue is more likely caused by the setup and parsing of the 'draw' environment, because internally both annotate and draw should be using the same internal function.
As I mentioned I would make a bug report, as it is likely that the stroke setting defaults for -annotate are not defined, and is the cause of the problem.
hmmm... too bad the -annotate command doesn't make use of the "-draw "stroke-linejoin round stroke-miterlimit 1 " stuff.
Oh well, got it working and it's slick {toot! toot!}
the more i'm currently improving upon what i'm currently working on - YES, the ability to setup the "stroke-miterlimit" etc...just like in -draw command would be a 'godsend' ... as it's better in -annotate esp. when I go to 'skew' any objects for obvious reasons already discussed in your usage areas.
So, I'm hoping it'll make its way into a newer release quickly
(was also thinking that if there was a way to bypass the annotate %escape sequence, that seems to be apparently what's botching it up... for some strange reason - as you previously mentioned)
-draw does not use the %escapes. However if the annotate string input is from a file, or STDIN, then all escapes are also ignored. This was on purpose to provide a 'secure' string input method.
anthony wrote:-draw does not use the %escapes. However if the annotate string input is from a file, or STDIN, then all escapes are also ignored. This was on purpose to provide a 'secure' string input method.
so i could make an input string in a file, without escapes?
cuz i'm having trouble getting a dbl quote inside the -draw command... the \" isn't working too swell
.
