My latest version of Talapanna, exhibits a strange bug in Jarte, Wordpad, and PagePlus. Some character sets, but not all are rotated by 90°
In font drop lists the name is shown as
@Talapanna
which is normally used for Asian fonts.
What is causing this odd behaviour?
Talapanna Regular.7z (201 KB)
Someone pointed me to this thread, but the problem is that calculating code pages is adding the wrong pages.
Have I messed something up while playing with Unicode 6.0 data?
Here are before/after shots of the code pages selected after using Calculate on the Ranges/Code pages tab.
On the PC that I am using, the font appears as Talpanna and as @Talapanna.
Here is a graphic made with Microsoft Paint of a Print Screen from WordPad.
The upper row is from Talapanna and the lower row from @Talapanna, both at 36 point.
William Overington
12 October 2010
Two more observations.
I tried the font in PagePlus X3.
Once I had tried @Talapanna, using Talapanna went wrong at times, such as acting as if English text has the advance widths of the glyphs reduced, with the effect of overlapping glyphs.
However, when I closed PagePlus and started again using just Talapanna, all seemed well with English text. This was not an exhaustive test, just a few words.
When I studied the font in FontCreator 5.6 using Format Settings… Ranges and used Edit… to study the code page flags, I found that four flags related to Japan, Chinese and Korean were checked.
I hope that this helps.
William Overington
12 October 2010
Deleting the code pages for Asian fonts solves the problem, but it doesn’t explain why the calculate function is broken on my installation.
Is it also broken on yours if you calculate code pages for the attached Talapanna Regular.ttf ?
Could you clarify please as to why you think that the calculate function is broken?
Here are the results here this morning, using FontCreator 5.6, graphic files produced using Print Screen and Paint.
I hope that this helps.
William Overington
13 October 2010
Your results after calculating in FC5.6 are the same as my Before screen shot, so either FC 6.1 has a bug, or I have broken it somehow.
The specs are not that clear about when to set a code page character range, but since FontCreator 6.0 we improved the calculation of the codepage character ranges.
http://www.microsoft.com/typography/otspec/os2.htm#cpr tells us:
The determination of “functional” is left up to the font designer, although character set selection should attempt to be functional by code pages if at all possible.
170 of your characters are part of code page 932 which itself contains 7771 characters. To name a few your font has: 8208, 8213, 8229, 8741
168 of your characters are part of code page 936 which itself contains 21763 characters.
208 of your characters are part of code page 949 which itself contains 17004 characters.
114 of your characters are part of code page 950 which itself contains 13488 characters.
The algorithm now beleives these code pages are functional even though not all character are included.
Thanks for the response. At least I haven’t broken FontCreator by editing Blocks.txt 
I like to comment out the blocks that I never use to make it easier to navigate the Insert Character dialogue.
I guess I just have to edit the code pages, and delete four checkmarks for the CJK fonts to make my fonts work as intended.
I expected to find a flag for Windows to determine whether a font has vertical text support or not, rather than just checking for the presence of certain code pages.
I never thought about that, but it is no surprise to me as you are an expert in getting the most out of FontCreator 
FYI changes to the Unicode files won’t affect the internals of your fonts.
Well you actually found them as these are the (undocumented) flags 