Skip to content
This repository has been archived by the owner on Mar 30, 2019. It is now read-only.

Tkfont new generation vs old #276

Closed
xanather opened this issue Feb 12, 2014 · 14 comments
Closed

Tkfont new generation vs old #276

xanather opened this issue Feb 12, 2014 · 14 comments

Comments

@xanather
Copy link
Contributor

New:
test

Old:
test2

Now each type of output could benefit difference situations depending on what you are developing. However, is it possible to get the old output with the new tkfont?

The xml file used for generation:
http://www.xanather.com/Main.xml

@xoofx
Copy link
Member

xoofx commented Feb 12, 2014

Is the old generated with "Microsoft Sans Serif" or "MS Sans Serif"? I'm not able to generate "MS Sans Serif" either using the old system or the new. DirectWrite is not supporting bitmap .fon files, so it can't support fonts like "MS Sans Serif", but we could use the old system in case DirectWrite can't handle it... but still, I can't make tkfont working with "MS Sans Serif"

@xanather
Copy link
Contributor Author

Yeah I cant make MS San Serif either, never could. I realized I used Microsoft Sans Serif for both, which now produces different results.

Edit: In the old system, using Microsoft Sans Serif produced something that looked almost exactly like MS Sans Serif (no antialising/jeggedness)

xoofx added a commit that referenced this issue Feb 12, 2014
…able anti-aliasing when font size is <= 13 to mimic System.Drawing text anti-aliasing behavior
@xoofx
Copy link
Member

xoofx commented Feb 12, 2014

If you can test latest fix. I tried to emulate the behavior of default System.Drawing font, and actually force no-antialiasing when font-size <= 13. Anti-Aliasing is not completely equal at font size == 14, and is probably on par with higher font sizes.

@xanather
Copy link
Contributor Author

It is much clearer now, but more spaced out?

Result:
hmmm

@xanather
Copy link
Contributor Author

Changing the spacing to negative makes it look unnatural/not what it should.

xoofx added a commit that referenced this issue Feb 13, 2014
… original DirectXTk implementation. Add SpriteFontApp sample
@xoofx
Copy link
Member

xoofx commented Feb 13, 2014

Ok, hopefully this is the last fix. I have been struggling with the implem, and discovering that the code I used from DirectXTk was invalid in several parts... I should have not trusted it.
I have added a new sample to the toolkit sample (SpriteFontApp) that is covering most of the rendering cases and It looks good (hopefully to you as well!), at least much better than before.
Let me know if you have any issue with it (oh god of coders, I implore you this is fixed :D )

@xanather
Copy link
Contributor Author

Well, its working much better now! Few very minor issues though. Some glyphs seem to be spacing incorrectly (only slightly though). Ill create comparison image now. It also seems commas (,) are drawn as dots/fullstops (.), this could just be how directwrite processes such small fonts (I am using Microsoft Sans Serif size 10).

@xanather
Copy link
Contributor Author

differences

xoofx added a commit that referenced this issue Feb 15, 2014
…f round to have better spacing (will slightly increase overall size). Fix offsets for small fonts when rendering ","
@xoofx
Copy link
Member

xoofx commented Feb 15, 2014

I have tried to improve the issue of spacing (though it has increase slightly the overall width) and the incorrect rendering of ","
I'm closing this issue, as the rendering looks correct, probably different from XNA, but I don't see how I can fix these minor space issues.

@xoofx xoofx closed this as completed Feb 15, 2014
@xanather
Copy link
Contributor Author

Alright no problem, looks good now anyway as it. Thanks for all the patches.

xoofx added a commit that referenced this issue Feb 16, 2014
…the final value instead of the original advance value
@xoofx
Copy link
Member

xoofx commented Feb 16, 2014

Ok, probably last fix. I have modified the code to perform the round on the final value instead of the original advance value. This seems to improve the compact spacing and it looks closer to what we are seeing in Word for example. It is still not perfect with small fonts like MS sans serif 10, but the difference is difficult to distinguish.

xoofx added a commit that referenced this issue Feb 16, 2014
…the final value instead of the original advance value
@xoofx
Copy link
Member

xoofx commented Feb 16, 2014

Sorry, messed with wrong commit being uploaded. Last version should be fine

xoofx added a commit that referenced this issue Feb 16, 2014
@xoofx
Copy link
Member

xoofx commented Feb 16, 2014

I did some changes to the previous implem. Now the system doesn't automatically switch to no-AntiAlias when font is under <= 13. You need for this to specify <AntiAlias>Aliased</AntiAlias> mode in the xml file.

I have double checked rendering with DirectWrite and offsets and spaces are on par. The only thing that is not supported is that DirectWrite is able to offset at subpixels but we can't do that in SharpDX as we are rendering bitmap fonts snapped to pixels.

Also, you may be interested in using <AntiAlias>ClearType</AntiAlias> mode that can improve the rendering (specifically for example for Microsoft Sans Serif 10, it looks better than grayscale)

Pfew, quite a big rabbit hole this font rendering thing... Hope that I'm out of it ;)

@xanather
Copy link
Contributor Author

ClearType actually looks very nice! Rendering looks exactly like MS Sans Serif as well now. Once again, thank you.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants