[Mapserver-dev] Labels that follow streets with bends

[woodbri at swoodbridge.com]

On 10 Feb 2003 at 16:50, Steve Lime wrote:

> So MapServer actually takes metrics from unrotated labels and then
> rotates them internally so that bounding polygons are tight to the
> label. 

How do you do that? Store x,y,h,w,ang instead of the *brect

> Your function is
> going to have to produce more detailed information it gives back. Even
> bounding rects for each rotated character would be workable (i.e. turn
> int *brect into int **brect).  

OK, this is no problem. Do we want to assume there are strlen(string) 
entries in **brect, alternatively the array *brect could be 
terminated with a null pointer which would make freeing it 
independent of remembering strlen(string). I am prefer the later, but 
what makes the most sense for mapserver?

> You first have to produce a placement
> without drawing and then evaluate that placement against the cache.

Yup, this was my plan, you pass in NULL for the image pointer and I 
don't do the drawing only return **brect

On memory allocation, I assume I should alloc the memory and return a 
pointer to in brect.

> That will be more expensive in this case.

Yup, that is why I'm thinking about a phase two redesign, but figure 
it is best to get it working before trying to optimize it.

> Does this help/make sense?

Yes. See questions above.

-Steve W.

> 
> Steve
> 
> >>> <woodbri at swoodbridge.com> 02/09/03 10:56AM >>>
> Hi all,
> 
> There has been some some discussion of have street labels follow bends
> in the streets in the past. I have decided to take a pass at
> implementing a routine to do this.
> 
> Here are my initial thoughts on this. I am looking for comments and
> feedback.
> 
> My plan is to implement a function like this:
> 
> bchar *TextPath(
>     gdImagePtr im,
>     int *brect,
>     int fg,
>     char *fontname,
>     double ptsize,
>     int npts,
>     int *X,
>     int *Y,
>     char *string,
>     int flags);
> 
> most of these args are identical to the gdImageStingFT() call and this
> function would work similarly to it if you pass it NULL for im. The
> polyline would be passed in using the npts, X, Y args; and flags I
> envision would be used to control the behavior of the function with
> respect to NO_PARTIAL  - fail is polyline is too short to render the
> whole string TRUNCATE  - trucate the string if it is too long EXTEND -
> virtually extend the last segment to write the whole string REVERSE -
> the direction of the polyline AUTO - figure out the best placement of
> the text so it is most readable ABOVE|BELOW|CENTER the text on the
> polyline
> 
> My first pass at this will be straight forward if not brute force. I
> will take each char in the string and see if I have enough room to
> place it on the segment, if not place it on the next segment until I
> run out of chars or segments. I will also probably ignore most of the
> flags and implement it as flags = EXTEND|AUTO; I plan to write the
> function to just call gdImageStringFTEx() to do the work, a later
> optimization might be to clone the gdImageStringFTEx() source so I can
> make some optimization.
> 
> This implementation has the advantage for me that I can dev and test
> in a simplified GD only environment. On the down side real performance
> will not be as easily tested until it is integrated into mapserver.
> 
> If I implement as described above will it be easy to integrate into
> mapserver? Issues? concerns?
> 
> -Steve W.
> 
> 
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu 
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
> 
> _______________________________________________
> Mapserver-dev mailing list
> Mapserver-dev at lists.gis.umn.edu
> http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev
>