Id rather not have to continuously build my own binaries to make it work properly. Is this issue related to having two different font processors or something? I am using SharpDX's implementation of the DirectX toolkit SpriteFont compiler. According to what has been said before SharpDX now uses the same implementation of DirectX SpriteFont processor so I'm not sure what could cause the issue unless the DirectX Toolkit includes the issue itself. #86 describes this issue.

There is no easy fix, because if we will revert to previous patch - it will cause issues with whitespaces at beginning of the line. The problem lies much deeper, and it may require to rewrite the actual sprite font generation functionality. I will take a look at it once I will find more free time.

Should I submit a temporary fix where SpriteFont has a static propery determining whether to ignore the offset at the beginning or not?

I would prefer not. I believe DirectXTk has this problem as well and the problem lies into the font generation. I will investigate to switch to DirectWrite rendering for the compiler.

I have a new working version with DirectWrite that seems to fix this issue, though it seems that supporting underline/strikethrough is a bit problematic. Are you using those?
Edit: Seems that BMFont is not supporting underline/strikethrough, so It would be probably fine to drop this feature

@xoofx, I agree to drop this feature. We can investigate it later - probably a call to IDWriteTextLayout::SetUnderline might help - in case if TextLayout is used to render each char.

I was primarily not using TextLayout (using the lower level part of DirectWrite)... but only TextLayout provide underline/strikethrough. Unfortunately, when using TextLayout, we are loosing the font offsets info, but I have found some possible workaround, testing it right now.

I use SharpDX's version of MakeSpriteFont, no underline/strikethrough, never knew such a feature existed in the first place.

Can you try latest version (from sourcecode) and let me know if there is anything wrong?

Sorry for late reply, anyway with the latest sources (including the most recent commit) this happened:

This is the compiled font file that i am using http://www.xanather.com/Main.font

Have you tried to recompile the font? SpriteBatchAndFont Toolkit sample works fine.

Will do

Yep rendering good now! Thanks for the fix.

Well the measurements are fine, however supports for some fonts gone now? I am trying to create a "MS Sans Serif" font but it results in a 0 byte output file. So instead I choose "Microsoft Sans Serif" (they are different), which results in a non 0 byte output file but the difference is that "Microsoft Sans Serif" is anti-aliased/more smooth which I don't want (not solid pixels/has blending). I generated the last font file over 2 months ago and can't remember if I chose "Microsoft Sans Serif" or "MS Sans Serif".

Edit: Just tested out on a old tkfont binary, this seems to be my issue (I think). All I'm trying to do is get a pixelized/not smooth/jagged version out of Microsoft Sans Serif.

Edit2: Silly me, I remember using BMFont to do this. Anyway this issue seems to be fixed so closing...

I was right. I can no longer create Jagged fonts with the new TKFont, is this intentional or is it just how DirectWrite handles it?