Opened 13 years ago
Last modified 13 years ago
#3611 new enhancement
Refactor Text Rendering
Reported by: | tbonfort | Owned by: | tbonfort |
---|---|---|---|
Priority: | normal | Milestone: | FUTURE |
Component: | Renderer API | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | sdlime |
Description
Text rendering could probably be improved to support high level wrapping and alignment:
- Current renderers only implement a renderText method, which is called with the full label string for "normal text", and called repeatedly with a single character for angle follow labels (which is rather inefficient as the font loading mechanism has to be repeatedly called by the renderer, although it is usually cached somehow).
- For multiline labels, each renderer has to take line breaks into account, when computing label size and when rendering, which can lead to discrepancies between renderers.
I propose we refactor the label handling code by always using a labelPathObj object for the precise placement of each glyph:
- renderers expose a getLabelSize method that returns the advances of each character in the stream (it would be up to higher level code to calculate the actual bbox of the label)
- high level code uses this advance information: as done now for FOLLOW labels, or for calculating line breaks and/or offsets used for multiline alignment and wrapping.
- renderers expose a renderText(char *text, labelPathObj *placements, .../*styling*/) method that ignores line breaks, and places each glyph as defined in the labelPath.
For vector renderers, where the label as a whole is more important than the precise position of each glyph, we'd have to decide if we want to expose a specific text handling function, or if the renderer just ignores the labelPathObj data.
Change History (4)
comment:1 by , 13 years ago
Milestone: | → FUTURE |
---|
comment:2 by , 13 years ago
Cc: | added |
---|
comment:3 by , 13 years ago
comment:4 by , 13 years ago
See also Ticket #4026 (new enhancement), "Inter-character spacing control for labels and annotation" for some thoughts on additional control of spacing within and between words.
So the higher level code would make use of the renderer's advances and construct the labelPathObj, correct? That makes a lot of sense.
In this scheme can we potentially support some in-label formatting (e.g. different sizes)? How to mark that up in a mapfile aside it seems like this more character oriented approach might allow that.
Steve