Sometimes when using the Offset parameter in Text object data > Geometry > Modification to shrink or fatten characters, some characters will get incorrectly displayed:

enter image description here

The default Bfont is more immune to this then most other fonts I tried, where this starts happening even with an Offset factor of .001.

What causes this and how can I correct it?

  • $\begingroup$ I think this happens when glyphs outlines have unusual spline orderings, got any links to fonts where this happens? $\endgroup$
    – zeffii
    Sep 5, 2013 at 19:14
  • $\begingroup$ @zeffii This font has this issue with a positive offset of .001. Bfont breaks at .026. $\endgroup$
    – gandalf3
    Sep 5, 2013 at 19:25
  • $\begingroup$ The uppercase L in that font has a stray line segment i.stack.imgur.com/52hy3.png -- you could use fontforge to inspect fonts, usually if fontforge has an issue with a font it's a bad sign. If you find issues on fonts from Google WebFonts, those are generally checked better before being added -- then it might be a bug. $\endgroup$
    – zeffii
    Sep 5, 2013 at 20:56
  • $\begingroup$ I tried reporting a bug a year ago with some fonts that drew badly, the official response was - "This is an issue with scan-fill, blenders geometry filling doesn't support overlapping lines". $\endgroup$
    – sambler
    Sep 6, 2013 at 5:15

1 Answer 1


While this isn't a fault with blender's font parser I think I can offer some insight.

To give this context, this doesn't only happen with fonts, it happens with all 2D Curves that self intersect when offset too. enter image description here

Font Weights

If you have a bit of respect for typography then you don't 'fatten' fonts. Fonts are designed with certain visual weights in mind, an indiscriminate offset messes with this delicate balance of geometry and empty space. As an example Helvetica has between 34 and 51 weights depending on flavour, each is 'fattened' by hand and tweaked in subtle ways.

No doubt you don't have to pay any attention to what is considered proper use of fonts, that's part of the fun. For the moment this is the way the Blender engine offsets 2D filled curves, without respect for potentially self-intersecting geometry. If you really want fatter letters but can't find the right weight in the font family then consider doing it in Inkscape/Illustrator, and importing as an SVG. SVG is imported as a 2D curve.

Other reasons a font may render poorly

Fonts or 'digital typefaces' vary in enormously in quality. A substantial amount of free fonts has defects that may not be immediately obvious in 2D graphics packages (they may have more elaborate font loading mechanisms).

With the font you suggest, the area in question is tricking blender into thinking it has to deal with an extra line segment, this line segment however doesn't connect to any other segments and also doesn't form a closed loop with itself.

In Inkscape if you pick this Embossed Font and make a text object, with just the uppercase L, and convert it to a path (Path > Object to Path) you will notice this stray line segment. It shouldn't be there, but it is. Inkscape ignored it, but includes the path anyway.

enter image description here

This is also exactly where blender throws its hands in the air.

enter image description here

I'm sure if you inspect the other fonts where this peculiar stuff happens, they too suffer from stray line segments, and maybe self intersections.

A fix

You can edit fonts inside Blender, and remove the usual suspects.

With the font in object mode, go to:
Object -> Convert To -> Curve from Mesh / Text, or AltC-> Curve from Mesh/text

Now you can deal with stray lines, (delete them) and still apply Extrude, etc. Unfortunately this operation doesn't allow you to correct typos in the existing text object any more, because it has been converted to a Curve.

enter image description here

  • $\begingroup$ Would Bmesh have this sort of issue too? $\endgroup$
    – gandalf3
    Sep 5, 2013 at 21:24
  • $\begingroup$ @gandalf3 i think I read your question incorrectly, For offset I suppose the Positive offset code could be improved to deal with the result of self intersecting edges $\endgroup$
    – zeffii
    Sep 6, 2013 at 11:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .