Left one is from photoshop, right one is from monogame, no rescaling or anything. Also left text is font size 20, right one is 16. Non italic, both bold.
It definitely isn’t rotated, position is rounded and even if it wouldn’t be it is using linear sampling which should result in blurry font not pseudo italic with missing pixels. In anyway if results by newest monogam pipeline for fonts (even when correct) are close to XNA I would still greatly prefer superior Nuclex results, I mean… it’s different league of quality.
Now I need to figure out how to use nuclex with XNA just for font compiling while using Monogame with VS 2015 on Win 10 for everything else without making any mess.
Really tho, if monogame would start using same opensource rendering engine for fonts as Nuclex they would have my eternal gratitude. I understand if monogame is trying to get visually as close to original XNA as possible.
I have always had issues with Monogame/XNA spritefonts. They look awful. It’s been a pretty big pain point for us because we’ll design menus in Photoshop and the result in-game is always bad.
I recently began using Monogame.Extended for their Bitmap Fonts and they look much better. I don’t have any experience with Nuclex, but it was easy to get the Bitmap Fonts to work. I was originally afraid that I wouldn’t be able to use this solution for console ports, but it’s possible.
We use the FreeType library for rasterization, the same as Nuclex, and it usually gives a very good result. We have unit tests that compare our SpriteFont output to XNA’s output. There will be a reason for the particular rasterization issue you are seeing, and we would like to find out why.
In the SpriteFont processor properties, did you have the texture format set to Color or Compressed? Color will give the full uncompressed output at the cost of memory. Compressed uses a specialised DXT3 compressor on desktop targets designed specifically for font texture use that avoids the usual blocky compression artifacts.