Open Font Rasterizer in Symbian 9

13	Open Font Rasterizer in Symbian 9 2:34 AM \| Font • OFS • Symbian
2007.9

In the great changes of Symbian 9, most plug-in interfaces have been migrated to ECOM framework, Open Font Rasterizer (OFS for short) interface is just one of them.

Even from the newest SDK document of Symbian 9.2, the OFS related contents are still only for implementation before version 9. The following changes must be considered if you are writing OFS plug-in or porting it to Symbian 9.

As all other applications, the UID of pre-Symbian 9 is no longer available in Symbian 9, you must apply for a new one if you are porting your old OFS plug-in. Please remember, you should use separate UIDs for pre-Symbian 9 and Symbian-9 releases because they are incompatible with the Symbian version of each other.
As migrated to ECOM framework, the ordinal 1 of exported functions needs to be the group proxy for your ECOM plug-in. The formerly exported factory function CMyFontRasterizer::NewL should be keeped unexposed now and only proxied by exported implementation group proxy.

class CMyFontRasterizer : public COpenFontRasterizer
{
public:
  /*IMPORT_C*/ static COpenFontRasterizer* NewL();
  ...
}

const TImplementationProxy ImplementationTable[] =
{ IMPLEMENTATION_PROXY_ENTRY(KUidMyFontRasterizer, CMyFontRasterizer::NewL) };

EXPORT_C const TImplementationProxy * ImplementationGroupProxy(TInt& aTableCount)
{
  aTableCount = sizeof(ImplementationTable) / sizeof(TImplementationProxy);
  return ImplementationTable;
}

Because of the scalable-UI introduced in Symbian 9, OFS interface now has two new virtual functions which need to be implemented in your plug-in:

COpenFontFile::GetNearestFontToDesignHeightInPixelsL()
COpenFontFile::GetNearestFontToMaxHeightInPixelsL().

The first one is as the same as former COpenFontFile::GetNearestFontInPixelsL(), which is no longer called by OFS framework. The second one just has one more argument “aMaxHeight”, which means your plug-in must do the best to find a typeface that fits within the max height, otherwise, a leave must be performed. If aMaxHeight is passed in a zero value, the implementation should be exactly the same as COpenFontFile::GetNearestFontToDesignHeightInPixelsL().

As part of the ECOM framework, the resource file (.rss) is essential for your plug-in. This is example rss file for OFS plug-in.

#include "RegistryInfo.rh"
RESOURCE REGISTRY_INFO theInfo
{
  dll_uid = 0x20009F34;
  interfaces =
  {
    INTERFACE_INFO
    {
      interface_uid = 0x101F7F5D; //KUidOpenFontRasterizerPlunginInterface
      implementations =
      {
        IMPLEMENTATION_INFO
        {
          implementation_uid = 0x20009F34;
          version_no = 1;
          display_name = "FontRouter";
          default_data = "Font Enhancement Plugin";
          opaque_data = " ";
        }
      };
    }
  };
}

The “dll_uid” should be replaced with the UID allocated by Symbian Signed, and “implementation_uid” can the same as “dll_uid”.

Directory difference.

Directory   pre-Symbian 9    Symbian 9
DLL file    /system/fonts    /sys/bin
RSC file    -                /resource/plugins
Font files  /system/fonts    /resource/fonts

RSC file is compiled from the resouce definition file (.rss).

Save to del.icio.us • Digg This! • Stumble It!

Comments(22): [RSS for comments] [TrackBack URI]

1
I have won Nokia E90 as a prize! « Oasis Feng
[PINGBACK] | 2007.9.13 2:54 AM

[...] 这次Symbian的Wiki大赛，我总共投稿两篇，另一篇是：Open Font System in Symbian 9，主要介绍OFS在Symbian 9中的变化，以及如何移植旧版本的OFS插件至Symbian 9。（稍后将发布在Blog中） [...]
2
Mah | 2007.9.13 9:26 AM

Hello.
In a word, is your FontRouter the OFS of Ecom plug-in?

[Reply]
3
oasisfeng | 2007.9.13 9:56 PM

That’s true.

[Reply]
4
Mah | 2007.9.14 8:15 AM

Oh, it’s nice infomation!
It is what I was wanting it.
Thanks.

Why do FontRouer need the ProtServ capability?

[Reply]
5
Mah | 2007.9.14 9:12 AM

And, did you code TTF->Bitmap algorithm and COpenFont::RasterizeL by yourself?

[Reply]
6
newaa | 2007.9.14 3:15 PM

换字体三个问题：FontRouter LE＋雅黑字体。
1.E90和E61情况不同。E90换雅黑后，字体稍淡但是边缘较清晰还是很美观。E61换了后，字体边缘比较粗，而且字体会浓淡不一致。
请问如何解决？配置都是用缺省的配置。
2.已经解决了字库放在c盘的问题。把雅黑打包成sis文件装入C盘，Fontrouter放E盘，配置文件放E盘，E90和E61都没有问题。
3.E90用雅黑的英文没这么好看。能否只是中文用雅黑？

[Reply]
7
oasisfeng | 2007.9.15 11:05 AM

ProtServ capability is needed by all ECOM plug-ins.
TTF->Bitmap is implemented by the built-in rasterizer from your phone vender.

[Reply]
8
oasisfeng | 2007.9.15 11:08 AM

字体的反锯齿渲染效果是TrueType字体驱动决定的，不受FontRouter影响。至于中英文分别使用不同字体，是FontRouter2的功能，FontRouter LT将来会考虑加入。

[Reply]
9
Mah | 2007.9.15 8:20 PM

Thank you for your answer :).
I examine the built-in rasterizer(FreeType?).

[Reply]
10
Mah | 2007.9.20 10:35 AM

I made OFR by the method that had been said by you.
However, COpenFontRasterizer::NewFontFileL() did not work at system boot.
Then, it worked at system boot when I changed the place where the RSC file was put from “/resource/plugins” to “/resource/fonts”.

Is it a problem?

[Reply]
11
Mah | 2007.9.20 12:48 PM

Sorry, I was wrong.
NewFontFileL() only reacted to the RSC files that existed in “/resource/fonts”.

Is “FontRouter.ini” being read by NewFontFileL()?

[Reply]
12
oasisfeng | 2007.9.21 7:58 PM

RSC file should be placed in /resource/plugins, but not /resource/fonts. To correctly check this out, you must flush the ECOM registry cache after modification by deleting the folder c:\private\10009D8F.

[Reply]
13
Mah | 2007.9.24 7:56 PM

Do I delete “10009D8F” not “10009D8D”?

[Reply]
14
blesio | 2008.3.3 11:08 PM

Hi Oasisfeng, will you have a signed version of FontRouter? Since Symbian Signed isn’t giving away dev cert’s it’s impossible to use your app. I tried Open Signed but the app’s UID is from a restricted range, maybe you could change it to the developers range so we could sign the app from the Open Signed?
BTW it’s a cool app you wrote. Too bad I can’t use it on my phone :(

br

blesio

[Reply]
15
blesio | 2008.3.6 11:55 PM

Hi Oasis, or maybe you could sign it for me? I just need to have this app, please ;)

My IMEI is 357663015906070

br

blesio

[Reply]
16
oasisfeng | 2008.3.7 12:07 AM

请下载可在线签名版：

http://fontrouter.oasisfeng.com/forum/viewtopic.php?t=3456

[Reply]
17
wuheguo | 2008.10.14 5:02 PM

我想问一下在 s60 3版下如何获得字体的点阵数据呢

[Reply]
18
wuheguo | 2008.10.14 5:09 PM

我目前是通过CFont 类中的GetCharacterData方法
CGraphicsDevice* screenDevice = CEikonEnv::Static()->ScreenDevice();
TInt verticalTwips = screenDevice->VerticalPixelsToTwips(12);
TPtr typefaceName(NULL, KMaxTypefaceNameLength);
typefaceName.Set(CEikonEnv::Static()->NormalFont()->FontSpecInTwips().iTypeface.iName.Des());
TFontSpec fontSpec(typefaceName, verticalTwips);
CFont* font;
fontSpec.iFontStyle.SetBitmapType(EAntiAliasedGlyphBitmap);
screenDevice->GetNearestFontInTwips(font,fontSpec);
TOpenFontCharMetrics metrics;
const CFbsFont* fbsfont = static_cast(font);
fbsfont->GetCharacterData(code,metrics,iFontLattice,iFontsize);
但是我获得数据对照symbian的行程算法好像不对。所以，想你能指导一下。如能指教，将不胜感激

[Reply]
oasisfeng Reply:
October 14th, 2008 at 6:53 PM
S60v3对于非GDR字体（包括TTF、CCC）已经不再采用run-length算法存储点阵信息，而是简单的但点阵单字节格式。

[Reply]
19
wuheguo | 2008.10.15 10:01 AM

但是好像我通过fontSpec.iFontStyle.SetBitmapType(EAntiAliasedGlyphBitmap);
或者是fontSpec.iFontStyle.SetBitmapType(EMonochromeGlyphBitmap);
2者的获得的数据不一样。第二的设置能获得它的没有反锯齿数据吗

[Reply]
oasisfeng Reply:
October 15th, 2008 at 1:19 PM
请求的BitmapType不能保证一定能获得对应类型的格式，要读取返回字体的CBitmapFont::GlyphBitmapType()。如果是EMonochromeGlyphBitmap，则代表获得的点阵数据是run-length格式的。

[Reply]
20
wuheguo | 2008.10.15 1:55 PM

主要是我现在有个项目移植，看能不能获得系统的字体的点阵数据，这样就不必装上该项目自带的一个点阵字体库了。而是根据系统的点阵数据（1，0）格式画出该字符，我通过fontSpec.iFontStyle.SetBitmapType(EAntiAliasedGlyphBitmap);
获得的是一个反锯齿的一个256位色的一个数据块。
另外我想问一下 s60 3版是不是系统的都是矢量字体阿。我发现他的fonts里面没有gdr字体。
是否我这个需求就是不合适的，还是能够有一个好地解决办法。还要烦请你指点一下。
如能加我的msn wuheguo@live.cn 或者是qq 360694349 方便我随时请教就更好了。呵呵

[Reply]

Leave a comment

License

Recent Posts

Hosted by Dreamhost