Truetype Font Glyphs - Positioning

[DonaldKerr]

Truetype font glyphs are rotated correctly on their centre points for the AGG renderer but not for gif, jpeg, png or pdf: pdf doesn't even rotate correctly as yet. This has been reported previously and I have reopened the bug report which I originally reported for the AGG renderer to cover genereation of the other file types.

This request is for an enhancement that would allow truetype font glyphs to be positioned in the same way as labels PRIOR to being rotated so that the rotation point can be pre-determined with the rotation point then becoming the anchor point for the glyph.

See attached files showing:

1. The symbol unrotated as it appears in the font ttf file.

2. The symbol correctly rotated on a POSITION of cl (centre left) and anchored on that point.

3. The symbol incorrectly rotated on a POSITION of cc (centre centre) which is where the limitation is i.e. this is how the symbol appears on my maps with the AGG renderer. "cc" is better than it used to be for AGG rendering only as the other renderers (see above) still rotate on ll (lower left).

4. The symbol rotated by the Gif, Jpeg and Png renderers.

So, the CLASS and SYMBOL definitions could be as follows with the inclusion of the new POSITION key word:

CLASSITEM    "symbolclass"

CLASS
	NAME "boundaryMereingChangeSymbol"
	EXPRESSION "boundaryMereingChangeSymbol"
	STYLE
		SYMBOL "boundaryMereingChangeSymbol"
		SIZE 15
		MAXSIZE 30
		MINSIZE 4
		COLOR 255 0 255
		ANTIALIAS TRUE
		POSITION lc
		ANGLE [orientation]
	END # STYLE
END # CLASS

SYMBOL
	NAME 'boundaryMereingChangeSymbol'
	TYPE TRUETYPE
	FONT OSMasterMapSymbols
	FILLED false
	ANTIALIAS true
	CHARACTER '8'
END # SYMBOL

[tbonfort]

Donald, Please have a look at RFC45 which I believe proposes something similar to what you want, except that the rotation center and anchor point is determined by the ANCHORPOINT keyword, whose parameters is a percentage in x,y directions, i.e. the default is ANCHORPOINT 50 50, which means the symbol is centered. This would apply to all types of symbols, not only truetype ones.

The implementation is halted essentially due to lack of time/funding, wink wink.

[DonaldKerr]

RFC45 would seem to cover all bases and an ANCHORPOINT keyword is the ideal way deal with the functionality that I am looking for.

Is there any possibility that this RFC may be resurrected at some point for inclusion in the next version?

[tbonfort]

as all of the requirements are in rfc45, closing this ticket.

we now need to find funding for rfc45.