Page 1 of 2

Wierd ANNOTATE results....

Posted: 2008-06-30T19:50:07-07:00
by wortell
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):

Use this code:

Code: Select all

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.

ANY ideas?!

There's reasons I have to stick with annotate ;).

- Bill

Re: Wierd ANNOTATE results....

Posted: 2008-06-30T20:06:35-07:00
by anthony
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.

Re: Wierd ANNOTATE results....

Posted: 2008-06-30T20:23:18-07:00
by wortell
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 :)

but i'm open :)

Re: Wierd ANNOTATE results....

Posted: 2008-06-30T22:46:00-07:00
by anthony
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?

Re: Wierd ANNOTATE results....

Posted: 2008-06-30T22:52:40-07:00
by fmw42
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.

Re: Wierd ANNOTATE results....

Posted: 2008-06-30T23:21:11-07:00
by anthony
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.

See how that setting works in IM -draw, though I don't think it is the IM draw that is causing this in fonts.
http://imagemagick.org/Usage/draw/#mvg_settings

Re: Wierd ANNOTATE results....

Posted: 2008-07-01T05:48:18-07:00
by wortell
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.

See how that setting works in IM -draw, though I don't think it is the IM draw that is causing this in fonts.
http://imagemagick.org/Usage/draw/#mvg_settings

well, i'm actually using Annotate :)...hmmm any other suggestions?

Re: Wierd ANNOTATE results....

Posted: 2008-07-01T08:07:21-07:00
by wortell
wortell wrote:
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.

See how that setting works in IM -draw, though I don't think it is the IM draw that is causing this in fonts.
http://imagemagick.org/Usage/draw/#mvg_settings

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...

but here it is...

Code: Select all

		-draw "stroke-linejoin round stroke-miterlimit 1 text 79,100 'n' " 
removes the miter issue :)
thoughts on the degradatoin of speed?

- is there a way to use the
stroke-linejoin round stroke-miterlimit 1

using annotate?!

Re: Wierd ANNOTATE results....

Posted: 2008-07-01T16:15:56-07:00
by anthony
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.

-annotate however does percent escape image property substitutions

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.

Re: Wierd ANNOTATE results....

Posted: 2008-07-01T20:23:32-07:00
by wortell
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.

-annotate however does percent escape image property substitutions

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!}

Re: Wierd ANNOTATE results....

Posted: 2008-07-02T14:25:32-07:00
by wortell
wortell wrote:
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.

-annotate however does percent escape image property substitutions

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)

Re: Wierd ANNOTATE results....

Posted: 2008-07-02T16:28:09-07:00
by anthony
-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.

Re: Wierd ANNOTATE results....

Posted: 2008-07-02T19:04:40-07:00
by wortell
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 :)

Re: Wierd ANNOTATE results....

Posted: 2008-07-02T20:44:28-07:00
by anthony
Yes you can.

For example -draw 'text 0,0 "@file"'

Re: Wierd ANNOTATE results....

Posted: 2008-07-02T20:50:21-07:00
by wortell
anthony wrote:Yes you can.

For example -draw 'text 0,0 "@file"'
sorry, Anthony - what I meant was something like this

-draw 'text 0,0 "she said, "Hey!" " '
i can escape the ' but not the ".
or at least i'm having trouble with this.