Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Does anyone know what set of Unicode characters BREW supports ?

If I code a BREW app properly (use AECHAR types, wide character string handling routines, etc) will any Unicode string get properly rendered ?

Or is the Unicode character range hardware/device dependent ?

Thanks,
Ben

BREW supports UTF16. So if you have any unicode data make sure that you convert it to UTF16 before giving it to BREW. Your unicode data can be in UTF8, UTF16, UCS4 etc. format, so you need to do appropriate conversion.
regards
ruben

BREW supports UTF16. So if you have any unicode data make sure that you convert it to UTF16 before giving it to BREW. Your unicode data can be in UTF8, UTF16, UCS4 etc. format, so you need to do appropriate conversion.
regards
ruben

Thanks Ruben, yes I get this.
But say for example, in a BREW app, I properly construct UTF16 strings, each of which uses codepoints from various Unicode codecharts, like a string of Devanagari codepoints and a string of Cyrillic codepoints and a string of Katakana codepoints, will all the strings be properly displayed on the BREW device the app is executing on ?
I think if the Unicode code point is rendered via software within the BREW OS then all codepoints could be supported. But more likely, a subset of Unicode codepoints as bitmaps reside in ROM on the device, so only that subset of Unicode is supported on the device.
If the latter is the case, not only does a BREW app developer have to properly manage UTF16 strings in their app, but the app has to be running on a device that supports the Unicode codepoints that the developer uses.

Thanks Ruben, yes I get this.
But say for example, in a BREW app, I properly construct UTF16 strings, each of which uses codepoints from various Unicode codecharts, like a string of Devanagari codepoints and a string of Cyrillic codepoints and a string of Katakana codepoints, will all the strings be properly displayed on the BREW device the app is executing on ?
I think if the Unicode code point is rendered via software within the BREW OS then all codepoints could be supported. But more likely, a subset of Unicode codepoints as bitmaps reside in ROM on the device, so only that subset of Unicode is supported on the device.
If the latter is the case, not only does a BREW app developer have to properly manage UTF16 strings in their app, but the app has to be running on a device that supports the Unicode codepoints that the developer uses.

That's right. If the device does not have fonts associated with the requested codepoints, device would not be able to display the text. In that case either application needs to run on a device with supported code points or you need to supply fonts with your application.
regards
ruben

That's right. If the device does not have fonts associated with the requested codepoints, device would not be able to display the text. In that case either application needs to run on a device with supported code points or you need to supply fonts with your application.
regards
ruben

By supplying fonts with my application, I'm pretty sure you mean I could write my own code which uses the graphics api's provided and my supplied font, to render my own bitmaps....as oppose to on my apps startup, somehow replacing the font on the BREW device with my own supplied font, correct ? (I don't see any interface in the BREW api doc to let me do that)
Regards,
Ben

By supplying fonts with my application, I'm pretty sure you mean I could write my own code which uses the graphics api's provided and my supplied font, to render my own bitmaps....as oppose to on my apps startup, somehow replacing the font on the BREW device with my own supplied font, correct ? (I don't see any interface in the BREW api doc to let me do that)
Regards,
Ben

You can do the following. For smaller size use/create single bitdepth bitmap font. You can create an extension of IFONT type interface and implement all the functions (if you don't need a specific one then don't implement it).
Now call IDISPLAY_SetFont and pass your new font object. Now all your text writing call will use your custom IFONT functionalities. It is possible, I have done it.
regards
ruben

You can do the following. For smaller size use/create single bitdepth bitmap font. You can create an extension of IFONT type interface and implement all the functions (if you don't need a specific one then don't implement it).
Now call IDISPLAY_SetFont and pass your new font object. Now all your text writing call will use your custom IFONT functionalities. It is possible, I have done it.
regards
ruben

Ah yes. I follow. Thanks for the advise, it was very helpful.
Regards,
Ben

Ah yes. I follow. Thanks for the advise, it was very helpful.
Regards,
Ben

Do you know if it is possible to change the font ITEXTCTL uses ? If so, how its done ?
Regards,
Ben

Do you know if it is possible to change the font ITEXTCTL uses ? If so, how its done ?
Regards,
Ben

I have never tried to do that. But as far I know it may work. Once you set IDISPLAY_SetFont, then BREW built-in controls will use that. You can do a quick check by creating a dummy font extension and then call IDisplay_SetFont and then make your text control call to see if you are getting call into your font extension methods.
ruben

I have never tried to do that. But as far I know it may work. Once you set IDISPLAY_SetFont, then BREW built-in controls will use that. You can do a quick check by creating a dummy font extension and then call IDisplay_SetFont and then make your text control call to see if you are getting call into your font extension methods.
ruben

good idea. thanks again for you help ruben.
regards,
ben

good idea. thanks again for you help ruben.
regards,
ben

I've been working on implementing the IFont interface as an extension. I've been getting some strange results that I don't understand.
In the app that uses the extension, when IDisplay_DrawText is called, IDisplay_DrawText calls into my extension's IFont implementation.
First IFont_MeasureText is called. I can see that the AECHAR * arg passed to IDisplay_DrawText makes its way here, so thats good.
Next, IFont_QueryInterface is called. I don't understand the args passed from IDisplay_DrawText here. First, the AEECLSID is 0x0012faf8. This does not seem to be a valid id after looking at aeeclassids.h. What classid is this ? Also, the (void ** p) arg is 0x00000004. Obviously an invalid address. For now, to get around this, I've simply return SUCCESS.
Next is a call to IFont_GetFontInfo(). Here, IDisplay_DrawText passes the value of 0x1E for nSize, which is much bigger than sizeof(AEEFontInfo) - 4 bytes. According to API doc, in this case IFont_GetFontInfo should return EUNSUPPORTED.
With all that the call to IDisplay_DrawText() never makes it into my IFont implementation's DrawText() routine.
To keep IDisplay happy, in my IFont implementation I maintain a ptr to a "real" IFont instance and simply proxy the calls in my IFont implementation to this real IFont instance. Although, I'm not sure what AEECLSID of the IFont interface I should be using in my call to ISHELL_CreateInstance(), like AEECLSID_FONT_BASIC9 or AEECLSID_FONT_BASIC11B (I assume B means bold)..I've tried them all.
Also I sure the AEEFont type in the call to IDisplay_DrawText must come into play somehow, but I'm not sure how.
Regards,
Ben

I've been working on implementing the IFont interface as an extension. I've been getting some strange results that I don't understand.
In the app that uses the extension, when IDisplay_DrawText is called, IDisplay_DrawText calls into my extension's IFont implementation.
First IFont_MeasureText is called. I can see that the AECHAR * arg passed to IDisplay_DrawText makes its way here, so thats good.
Next, IFont_QueryInterface is called. I don't understand the args passed from IDisplay_DrawText here. First, the AEECLSID is 0x0012faf8. This does not seem to be a valid id after looking at aeeclassids.h. What classid is this ? Also, the (void ** p) arg is 0x00000004. Obviously an invalid address. For now, to get around this, I've simply return SUCCESS.
Next is a call to IFont_GetFontInfo(). Here, IDisplay_DrawText passes the value of 0x1E for nSize, which is much bigger than sizeof(AEEFontInfo) - 4 bytes. According to API doc, in this case IFont_GetFontInfo should return EUNSUPPORTED.
With all that the call to IDisplay_DrawText() never makes it into my IFont implementation's DrawText() routine.
To keep IDisplay happy, in my IFont implementation I maintain a ptr to a "real" IFont instance and simply proxy the calls in my IFont implementation to this real IFont instance. Although, I'm not sure what AEECLSID of the IFont interface I should be using in my call to ISHELL_CreateInstance(), like AEECLSID_FONT_BASIC9 or AEECLSID_FONT_BASIC11B (I assume B means bold)..I've tried them all.
Also I sure the AEEFont type in the call to IDisplay_DrawText must come into play somehow, but I'm not sure how.
Regards,
Ben

First of all when you create the instance of your custom IFONT extension, it would be ISHELL_CreateInstance with your extension ClsID, which requires to instantiate any extension.
IDisplay_Drawtext will eventually call to IFont_DrawText, which would be your extensions custom method where you would copy all your bitmap.
regards
ruben

First of all when you create the instance of your custom IFONT extension, it would be ISHELL_CreateInstance with your extension ClsID, which requires to instantiate any extension.
IDisplay_Drawtext will eventually call to IFont_DrawText, which would be your extensions custom method where you would copy all your bitmap.
regards
ruben

Yep, my extension that implements IFont is being created properly. I'm passing the pointer to my IFont extension instance (that I got call ISHELL_CreateInstance using my extension ClsID) to IDisplay_SetFont(), then a call to IDISPLAY_DrawText is made.
IDISPLAY_DrawText() calls into my IFont extension. Running in the debugger, the following calls are made from IDISPLAY_DrawText() into my IFont extension:
IFont_MeasureText()
IFont_QueryInterface()
Ifont_GetFontInfo()
IDISPLAY_DrawText() never makes a call to my IFont extension's DrawText() routine...and its probably because I'm not returning the proper data to IDISPLAY_DrawText() from either
IFont_MeasureText()
IFont_QueryInterface()
Ifont_GetFontInfo()
...still investigating.

Yep, my extension that implements IFont is being created properly. I'm passing the pointer to my IFont extension instance (that I got call ISHELL_CreateInstance using my extension ClsID) to IDisplay_SetFont(), then a call to IDISPLAY_DrawText is made.
IDISPLAY_DrawText() calls into my IFont extension. Running in the debugger, the following calls are made from IDISPLAY_DrawText() into my IFont extension:
IFont_MeasureText()
IFont_QueryInterface()
Ifont_GetFontInfo()
IDISPLAY_DrawText() never makes a call to my IFont extension's DrawText() routine...and its probably because I'm not returning the proper data to IDISPLAY_DrawText() from either
IFont_MeasureText()
IFont_QueryInterface()
Ifont_GetFontInfo()
...still investigating.

Please check with your IFont_QueryInterface() implementation.
regards
ruben

Please check with your IFont_QueryInterface() implementation.
regards
ruben

yeah, i'm not sure about this one ruben. the args passed from IDISPLAY_DrawText() into my IFont_QueryInterface are bizarre.
the AEECLSID is 0x0012faf8. This does not seem to be a valid id after looking at aeeclassids.h.
The (void ** p) arg is 0x00000004. Obviously an invalid address.
Right now, I'm simply returning SUCCESS, otherwise an exception is thrown when i try to write to *p.

yeah, i'm not sure about this one ruben. the args passed from IDISPLAY_DrawText() into my IFont_QueryInterface are bizarre.
the AEECLSID is 0x0012faf8. This does not seem to be a valid id after looking at aeeclassids.h.
The (void ** p) arg is 0x00000004. Obviously an invalid address.
Right now, I'm simply returning SUCCESS, otherwise an exception is thrown when i try to write to *p.

As I mentioned earlier, I didnot try to use my IFont extension with standard control. But I believe it should work with IDisplay_SetFont.
Here are my thoughts:
First of all, when you do IDisplay_DrawText, you will be directly writing on to the screen buffer bitmap, which you may not be allowed, that's my guess, I might be wrong here also. IFont interface was provided in BREW 2.0 or above so that developers can write onto offscreen frame-buffer.
Try to do the following. Create a off-screen bitmap, set that as a destination bitmap, and then you can call IDisplay_SetFont, and then all IDisplay methods including IDisplay_DrawText and then do blit-update call. Still if you see IDisplay_DrawText is causing problem, then try workaround using IFont_DrawText, which will be your extension methods.
regards
ruben

As I mentioned earlier, I didnot try to use my IFont extension with standard control. But I believe it should work with IDisplay_SetFont.
Here are my thoughts:
First of all, when you do IDisplay_DrawText, you will be directly writing on to the screen buffer bitmap, which you may not be allowed, that's my guess, I might be wrong here also. IFont interface was provided in BREW 2.0 or above so that developers can write onto offscreen frame-buffer.
Try to do the following. Create a off-screen bitmap, set that as a destination bitmap, and then you can call IDisplay_SetFont, and then all IDisplay methods including IDisplay_DrawText and then do blit-update call. Still if you see IDisplay_DrawText is causing problem, then try workaround using IFont_DrawText, which will be your extension methods.
regards
ruben

well, i found some cause of the problems i've been having. the order of function pointers specified in QINTERFACE affect how BREW is calling my ifont extension.
i originally had:
QINTERFACE(IExtensionCls)
{
DECLARE_IBASE(IExtensionCls)
int (*DrawText)...
int (*GetFontInfo)...
int (*MeasureText)..
int (*QueryInterface)...
;
no reason other that that is how IFONT is listed in BREWAPIReference.pdf
i then changed it to:
QINTERFACE(IExtensionCls)
{
DECLARE_IBASE(IExtensionCls)
int (*QueryInterface)...
int (*DrawText)...
int (*GetFontInfo)...
int (*MeasureText)..
;
i did this after looking at AEEFont.h..it uses INHERIT_IQueryInterface which does have (*QueryInterface) coming immediately after the IBASE function pointers.
After doing this, IDISPLAY_DrawText() made it's way to my extension's DrawText() routine. Actually IDISPLAY_DrawText() calls:
GetFontInfo()
MeasureText()
DrawText()
what's interesting is that IDISPLAY_DrawText() behaves differently depending on where (*QueryInterface) is located in the QINTERFACE macro. It may call:
QueryInterface()
MeasureText()
GetFontInfo()
or
GetFontInfo()
MeasureText()
QueryInterface()
my guess, looking that 3 function calls are made by IDISPLAY_DrawText() each time, is that IDISPLAY_DrawText() assumes a particular function pointer order into IFont..which would explain the crazy args i was getting into my IFont extension previously.
i havent seen this happen with any other interfaces that i have implemented in an extension.
thanks for you help ruben, it wasn't until you suggested looking at my QueryInterface routine that i went down this path.
regards,
ben

well, i found some cause of the problems i've been having. the order of function pointers specified in QINTERFACE affect how BREW is calling my ifont extension.
i originally had:
QINTERFACE(IExtensionCls)
{
DECLARE_IBASE(IExtensionCls)
int (*DrawText)...
int (*GetFontInfo)...
int (*MeasureText)..
int (*QueryInterface)...
;
no reason other that that is how IFONT is listed in BREWAPIReference.pdf
i then changed it to:
QINTERFACE(IExtensionCls)
{
DECLARE_IBASE(IExtensionCls)
int (*QueryInterface)...
int (*DrawText)...
int (*GetFontInfo)...
int (*MeasureText)..
;
i did this after looking at AEEFont.h..it uses INHERIT_IQueryInterface which does have (*QueryInterface) coming immediately after the IBASE function pointers.
After doing this, IDISPLAY_DrawText() made it's way to my extension's DrawText() routine. Actually IDISPLAY_DrawText() calls:
GetFontInfo()
MeasureText()
DrawText()
what's interesting is that IDISPLAY_DrawText() behaves differently depending on where (*QueryInterface) is located in the QINTERFACE macro. It may call:
QueryInterface()
MeasureText()
GetFontInfo()
or
GetFontInfo()
MeasureText()
QueryInterface()
my guess, looking that 3 function calls are made by IDISPLAY_DrawText() each time, is that IDISPLAY_DrawText() assumes a particular function pointer order into IFont..which would explain the crazy args i was getting into my IFont extension previously.
i havent seen this happen with any other interfaces that i have implemented in an extension.
thanks for you help ruben, it wasn't until you suggested looking at my QueryInterface routine that i went down this path.
regards,
ben