Stroke text using FreeType capabilities

[Ryder]

Hi!

I wanted to use stroke fonts with SFML. FreeType supports stroked glyphs but this is not made available in SFML.
I know it is posible to obtain a similar result by drawing the text several times with small position offsets, but they are several drawbacks to this method:
 - for larger borders and font sizes you have to draw more occurences of the text or artefacts will appear
 - space between characters does not take account of the border (or you have to draw each character independently, without relying on SFML)
 - sharpness of edges is not preserved
 - the result is more a "glow effect" than a stroke.

I made a small patch to SFML to add stroked support (feel free to ask if your are interested). Basically it adds:
 - m_borderWidth, m_borderColor and m_borderVertices members to Text (with associated constructors)
 - a borderWidth parameter (defaulting to 0) to glyph-related methods (ex. Font::loadGlyph()), along the characterSize parameter
API is preserved (new methods for Text, new optional parameter for glyph-related method), but not ABI (especially, glyph pages are now indexed by character size and border width).

Here is a picture showing the difference between FT-based stroke font and the multiple drawing method for 4 configurations (regular and bold font style, border width 3 and 6). For each configuration there are:
 - FreeType stroking (using FT_STROKER_LINECAP_BUTT and FT_STROKER_LINEJOIN_MITER_FIXED stroke style)
 - stroke by drawing the text 9 times with offsets from (-width,-width) to (width,width) to produce sharp corners
 - stroke by drawing the text 8 times around the initial position (at multiples of pi/4 angles)
 - stroke by drawing the text 16 times around the initial position (at multiples pi/8 angles)

As you can see, when the border is thick, drawing 8 times is not enough. And even with a small border, artefacts are visible where the FT-based stroking is always clean. FT-based version is larger because character spacing respects the border width.


This is just a proposal. I know that Laurent is very cautious with API changes (and he's right!) and maybe this solution would not fit its requirements, but I think stroke text would be a nice addition to SFML and I'm ready to help.

[Laurent]

It's true that workarounds are just ugly hacks and will never be able to produce the desired effect. An implementation using FreeType's features is mandatory if we really want to support this feature.

Now let's discuss it. I'm not alone to decide anymore, there's a whole team plus the entire community

My own opinion is that it would be a good addition. However we'd need to expose the stroking attributes: style of line cap and join.

[zsbzsb]

I fully support this feature. To be honest, it isn't even that hard to do. Maybe with 2.4? 

[Ryder]

I agree for the need of configurable stroking attributes. I didn't had it because it was simpler, but it's definitely needed. There is another parameter: the miter limit, used for FT_STROKER_LINEJOIN_MITER_FIXED and FT_STROKER_LINEJOIN_MITER_VARIABLE. We could decide to enforce it to 0 though; in this case all FT_STROKER_LINEJOIN_MITER_* styles are equivalent.

If we keep the same logic for fonts and glyphs, then we would have to introduce a new parameter to Font::getGlyph() for each new attribute: border width, line join style, line cap style and (possibly) miter limit. A probably better solution would be to create a struct/class to gather all stroking attributes, hence avoiding functions with too much parameters and logical grouping of stroking attributes. This would also allow easier passing of stroke configuration troughout the code (notably for accessors). This structure needs to be comparable to be used as index in Font::PageTable. Since all stroke attributes are integers or enums, this is easy to implement.

What do you think of this?

[dk123]

Hi, this seems like a great feature, and possibly simply to do - has this received any attention since the last post?

[Laurent]

Implemented in SFML 2.4

[dk123]

Implemented in SFML 2.4

Absolutely great

[Phanoo]

does substring coloration will be supported someday ?

[Laurent]

does substring coloration will be supported someday ?

It's not planned.