The title really says it all. I need help in creating a custom font from either a set of separate image files or from one image with a series of characters setup in a grid fashion in C#. I have searched everywhere and haven't found any useful resources on the subject. If you have any advice, thanks in advance.
As far as I have read, there is nothing within the C# framework that allows for the creation of a font, by the looks of it you will have to implement this on your own. Microsoft of course puts out some tools and a SDK for font creation, here along with other information here There are several tools outside of Microsoft that will allow you to create fonts aswell, for example this. I'm sure this isn't quite what you are looking for but it's a start.
This was something that was done 20 years ago, before freely scalable outline font technologies like TrueType became available. Some of these fonts are still on your machine, the .fon files in c:\windows\fonts. They actually contain bitmaps of the letters in the font, usually around 256 of them for each individual font height supported by the font.
Support for these fonts is not present in .NET so don't consider creating one of them. In general, the disadvantages of not using a TrueType font are:
only available in certain point sizes
no decent Unicode support
different code pages require different fonts
no support for kerning and glyph overhang
no anti-aliasing support
no ClearType support
Tools are available to create your own TrueType font. It is not exactly easy to get right, one of the things that makes TrueType shine is 'hinting', altering the letter shapes when they font is rendered at small point sizes so that they are still legible. Verdana is a exemplary font that is hinted extraordinarily well.
Anyhoo, to pursue your approach you'll need to create a bitmap that contains all the letters that you are willing to support, arranged horizontally for example. The best way to order them is to pick the letters in a code page that's close to you, like Windows 1252 which is common in Western Europa and the Americas.
Things are simple if the font is fixed-pitched, every letter will start at a multiple of the letter width. A proportionally spaced font requires a separate lookup table that specifies at what pixel offset each letter starts. Using System.Drawing for example, you'd use the Graphics.DrawImage(image, rectangle, rectangle, graphicsunit) overload where you setup the rectangles so that the letter you want to render is copied. Use Encoding.GetBytes() to convert the string to render to indices in your font bitmap.
Related
I want to use a thin font weight in my win forms window. The only thing I've been able to find is FontStyle, but I can only choose from Bold, Italic, Regular, Strikeout and underline. No possibility to make my font thin. Preferably, I'd like to be able to specify the font weight (100, 200 etc).
I've not tried it, but looking through CreateFont function I believe it can certainly be done via P/Invoking CreateFont function.
It takes a parameter fnWeight which is font weight. Then you could call Font.FromHFont method to get the instance of Font.
You will have to include a font file of a thin weight font in your deployment.
Then you can use it within your app.
This will likely cost you licensing I'm afraid. Wpf does make it easier so might be a more viable option depending on how great the need and how great the budget.
As far as I know, you can't do it directly.
That being said, you embed WPF controls in Windows Forms pretty easily, and WPF controls have font weight property exposed directly. Perhaps that might be suitable?
In my app i want to add feature to use custom fonts.
User choose font from list on my server, download and use it in app.
How to do the part of the app that will render font?
How to do it in an app that does not use the xaml?
The task you're about to embark on is probably going to involve a fair amount of code because the characters in the font will need to be rendered to a texture first before they can be rendered as part of a SpriteBatch.
Typically, this works in XNA by going through the content pipeline. You select a font file and setup the font properties in XML, then the content content pipeline compiles this information into an xnb resource which can be loaded and rendered. The problem is, it all happens at compile time and therefore it's going to be hard to do at run-time.
Reference: http://rbwhitaker.wikidot.com/drawing-text-with-spritefonts
An alternative method is to use a tool like BMFont to pre-render your font to a texture and write your own renderer. I wrote a tutorial once using this technique. However, it's much the same thing but you're replacing the XNA content pipeline with the BMFont tool.
http://www.craftworkgames.com/blog/tutorial-bmfont-rendering-with-monogame/
With this in mind, if you want to achieve this you'll probably need to write your own code to render each font to a texture after you've loaded it at run-time. You'll also need to keep track of the rectangle on the texture for each glyph as you're loading in the font. To save texture space and support larger font sizes you might also need to consider texture packing and excluding certain characters.
Situation: Simple 3D game project - OpenGL + C#
I read that OpenGL functions doesn't support easily print the text on the screen.
Have anyone clue how to do it? I don't need any too much sophisticated solution.
I just need show for example FPS rate in one corner or show the number of picked up objects in anohter corner.
thx.
One good method for text rendering is to use a texture with the font characters and draw one quad for each character with the good texturing coordinates. This usually gives good results and is platform independant. However this is quite heavy to implement.
Use wgl functions of Opengl32.dll on windows to render text. Example here: http://www.pinvoke.net/default.aspx/opengl32.wglusefontoutlines#
The basic process is you have to build a display list of glyphs in advance (rending the Windows font into an OpenGL context), then you can draw characters on the OpenGL display surface using the characters as indices into the pre-rendered display list.
For a prepackaged managed solution, take a look at Mono's Tao library: http://www.mono-project.com/Tao
http://nehe.gamedev.net/tutorial/freetype_fonts_in_opengl/24001/ This should give you all you want. Its in C++ but I am guessing that should not be a problem. It basically elaborates on what neodelphi suggested.
Although you say you don't need to much complexity and require it for just the FPS, having
a nice font rendering system comes in extremely handy.
HTH
I have a c# application that does text rendering, something on par with a simple wysiwyg text editor.
I'm using TextRenderer.DrawText to render the text to the screen and GetTextExtentPoint32 to measure text so I can position different font styles/sizes on the same line.
In Vista this all works fine. In XP however, Arial renders differently, certain characters like 'o' and 'b' take up more width than in Vista. GetTextExtentPoint32 seems to be measuring the string as it would in Vista though, with the smaller widths. The end result is that every now and then a run of text will overlap the text preceding it because the preceding text gets measured as smaller than it actually is on the screen.
Also, my text rendering code mimics ie's text rendering exactly (for simple formatting and english language only) and ie text rendering seems to be consistent between vista and xp - that's how I noticed the change in size of the different characters.
Anyone have any ideas about what's going on?
In short, TextRenderer.DrawText and GetTextExtentPoint32 don't match up in xp for Arial. DrawText seems to draw certain characters larger and/or smaller than it does in Vista but GetTextExtentPoint32 seems to be measuring the text as it would in Vista (which seems to match the text rendering in ie on both xp and vista). Hope that makes sense.
Note: unfortunately TextRenderer.MeasureString isn't fast or accurate enough to meet my requirements. I tried using it and had to rip it out.
Thanks for taking the time to respond Adrian.
My understanding is that TextRenderer.DrawText actually wraps a call to GDI, bypassing GDI+ text rendering completely. That's why I was confused about GetTextExtentPoint32 not jiving with the output.
I think I found the issue though. It turns out if you set Graphics.TextRenderingHint to System.Drawing.Text.TextRenderingHint.ClearTypeGridFit, or possibly other values, it causes some characters in some fonts to increase or decrease in size. This seems to be true more in XP than in Vista. I haven't seen it happen at all in Vista. Anyway, it looks like GetTextExtentPoint32 is either not capable of recognizing the difference or I am not setting some kind of flag when I make the call.
My solution is to just use the system default textrenderinghint settings.
Actually both TextRenderer's DrawText and MeasureString based on DrawTextEx (and this is User32, not Gdi function).
So you can consider using native marshalled calls to this function instead of MeauseString, because it doing some additional calculations (especially if you are using function override without HDC).
Also maybe this post will be helpful for you too.
I'm not a C# guy, but I believe the .NET rendering is built on top of GDI+. I'm also pretty sure that GDI+ does its own font rendering which uses unhinted scaling.
GetTextExtentPoint32, on the other hand, is part of GDI. GDI uses sizing hints, which can affect the width of characters depending on the font size. In general GDI text at small sizes will look a little bit getter, but it won't scale linearly.
You have to consistently use one model or the other to get pixel-perfect results.
There may be other factors in play that may make this more obvious on XP than on Vista, but the fundamental problem exists in both. These other factors might include DPI settings, DPI scaling, ClearType or antialiasing settings, font-linking (if you're mixing scripts from other alphabets), font substitution (especially in printing), and possibly even different versions of Arial. I'm not even sure GDI+ uses the same default mapping mode as GDI.
Also see my answer on print preview.
A few years back, I created a WinForms application that has been successfully deployed. The next version of the application must support Chinese and Korean characters. For aesthetic reasons, my client wanted all the text in the application displayed with the Arial font family.
However, Arial doesn't support Chinese and Korean characters. On most platforms, the Windows Uniscribe Font Fallback mechanism adequately chooses a font to display the East Asian characters. But on English Windows XP, the font it picks is terrible.
I've been looking at resolving this problem with Font Linking. This would allow me to specify which font should be used when Arial can't display a character. This seems like a very elegant solution.
The problem is that the article I linked to says that adding font links through the registry is not officially supported. Also, changing the font links in the registry would impact the whole computer and not just my application.
Does anyone have experience with added font links? Did it work? What are the situations that are going to bit me later?
The "not supported" clause in the linked article is telling you that you can't call Microsoft Support and complain because you used Regedit.exe incorrectly and messed up the machine. It doesn't say that font linking isn't supported.
You can't really affect another program negatively by doing this. Font linking doesn't replace glyphs, only substitute missing ones. Such a program would previously not render text correctly. It will show readable text after you're done. They'll buy you a very nice dinner and some dancing girls.
Can you use the font Arial Unicode MS?
That's what I use to display Chinese fonts in charts and PDFs.
So, the problem is that you want to use one font if the characters match some criteria, and another font if they don't, right?
So, why not just write some code that, when the text is updated, checks the criteria and sets the font appropriately? It may be a little bit of busy work, but if it's done all over the place I bet you could encapsulate it in a custom control.
Sometimes it's a lot easier to just do the work than to try and get clever with a bunch of system settings. Not as fun, admittedly, but less likely to cause problems.