Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Text Rendering #3611

Closed
mapserver-bot opened this issue Apr 3, 2012 · 3 comments

Comments

@mapserver-bot
Copy link

commented Apr 3, 2012

Reporter: tbonfort
Date: 2010/11/20 - 12:55
Trac URL: http://trac.osgeo.org/mapserver/ticket/3611
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.

@mapserver-bot

This comment has been minimized.

Copy link
Author

commented Apr 3, 2012

Author: sdlime
Date: 2010/11/30 - 18:10
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

@mapserver-bot

This comment has been minimized.

Copy link
Author

commented Apr 3, 2012

Author: panzel
Date: 2011/09/17 - 21:18
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.

@tbonfort

This comment has been minimized.

Copy link
Member

commented Jul 24, 2013

c.f. RFC78: #4673 , closing

@tbonfort tbonfort closed this Jul 24, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.