[mapserver-dev] Removing Bitmap Font Support

[Lime, Steve D (MNIT)]

I'm ok with the change...

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
Sent: Friday, August 30, 2013 4:30 AM
To: MapServer Dev Mailing List
Subject: Re: [mapserver-dev] Removing Bitmap Font Support

The diff for this change can be seen at
https://github.com/tbonfort/mapserver/compare/rfc98-b70...ttf-in-mem

--
thomas

On 30 August 2013 11:16, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> Hi devs,
>
> This will become an RFC for 7.0 unless there's wild objection right away...
>
> With the dropping of the GD renderer, I would like to streamline our
> text rendering some more and remove support for BITMAP fonts. I will
> stress right away that backwards compatibility (aside from the actual
> rendered output) will be maintained through the use of an embedded
> truetype font.
>
> Bitmap font support has the following inconveniences:
> - They are not supported by the cairo (svg+pdf) and kml renderers
> - They do not support rotation
> - They only cover the ASCII characters
> - They are difficult if not impossible to place correctly as they
> don't contain the information as to where their baseline is placed
> - This can be left to the appreciation of the reader, but my opinion
> is that they are far too ugly for any serious text rendering (c.f.
> https://github.com/mapserver/msautotest/blob/branch-6-2/renderers/expected/labels-bitmap.png
> )
> - All the previous points imply that maintaining their support in the
> codebase is brittle and painfull
>
> They are however usefull from a user's point of view, as they allow
> creating maps without having to define a fontset. Their simplicity
> also probably means that they are somewhat more performant to render
> than truetype fonts (I don't have any metrics to back this up).
>
> I am thereby proposing that we drop support for bitmap fonts. To
> maintain backwards compatibility, and to still allow quickly creating
> mapfiles without referencing and creating a fontset, labels of type
> bitmap, and/or labels with no font defined will fallback to an
> embedded truetype font that freetype will load from memory. The TINY,
> SMALL, MEDIUM, LARGE and GIANT keywords will map to equivalent pixel
> sizes (proposed: 5,7,10,13,16).
>
> The downsides I see to this modification are an increased libmapserver
> memory footprint (due to the embedded truetype font), and possibly
> slower rendering for those specifically using bitmap fonts. In
> exchange, we get nicer output, support for curved/angle labels,
> support for all latin, greek and cyrillic glyphs, support for all
> renderers, and a more maintainable codebase.
>
> regards,
> Thomas
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev