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 tbonfort, 13 years ago

Milestone: FUTURE

comment:2 by sdlime, 13 years ago

Cc: sdlime added

comment:3 by sdlime, 13 years ago

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

comment:4 by panzel, 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.

Note: See TracTickets for help on using tickets.