Skip to main content

Umlauts

18 replies [Last post]
hallenberg
Offline
Joined: 2007-01-05

I took a look on the font drawing (gxj_text.c and gxj_font_bitmap.c in midp/src/lowlevelui/graphics/putpixel/native) and realized that it would be very pretty to add the characters '

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
selenau
Offline
Joined: 2006-10-11
hallenberg
Offline
Joined: 2007-01-05

Looks nice, anti-aliased and all...

selenau
Offline
Joined: 2006-10-11

In fact it looks terrible on my LCD. That image was dump of the frame buffer device. It look amazing on CRT, I looked it on a laptop lcd and it looks worse than CRT better than embedded lcd. I'm trying to get it better but like everybody I've time problem :)

I also have little problems like fuzziness :), but it looks promising.

stuart_marks
Offline
Joined: 2006-08-24

Hi guys,

Just to follow up on bugs and on the legal issues. Yes, "Sun fellows asking to sign something" means that you'll need to sign the Sun Contributor Agreement before any substantial amounts of code can be accepted into the source base. We're still trying to work out what "substantial" means. I think that if something is a one-liner (like the one hallenberg posted in this thread last week) it can probably be accepted without the SCA. I don't know how much work it was to get the system to link with libfreetype. If it's a few ld flags and make rules, it might not need the SCA, but if it involves any logic or algorithms it might need the SCA.

The page that describes how to contribute is here:

https://mobileandembedded.dev.java.net/content/contribute.html

and this in turn links to the SCA, which is here:

https://mobileandembedded.dev.java.net/content/sca.html

I realize that signing an agreement is potentially an imposition, but I hope you understand the reasons for it. (Or if you don't, please post and I'll try to explain it.)

@hallenberg,

You referred to some bugs that you had filed that aren't getting any attention. Sorry about that. I'll follow up with it. The engineering team is still working primarily from our internal bug database, and they're not used to tracking the second (external) database as well. Eventually they'll be integrated -- see

http://weblogs.java.net/blog/sue_abellera/archive/2006/12/stop_bugging_m...

but for now we'll have to live with two bug databases. Hallenberg, I'd encourage you to consider continuing to file bugs on any problems that you see. They might pile up for a while, but that way they won't be forgotten. I'll follow up with the engineering team to include the Issue Tracker bugs in their backlog.

s'marks

hallenberg
Offline
Joined: 2007-01-05

Thanks for clarifying.

selenau
Offline
Joined: 2006-10-11

root@xscale:/work/pxa/phoneME/feature/build/midp/bin/arm# ./runMidlet -classpathext /work/midlet.jar 1 HelloWorld

worked.

I have seen "Hello World! "

Do you have freetype library on your target? It is quite easy to build, last month they released a new version. If you have the latest version I can give you my stupid code.

ps: Yeah I know, I need to sign something... :)

hallenberg
Offline
Joined: 2007-01-05

Nopes, how big is it?

Unfortunately I'm not that up to date with the legal issues as of now, I'll have to look into that...

selenau
Offline
Joined: 2006-10-11

# ls /lib/libfreetype.so.6 -lha
-rwxr-xr-x 1 root 0 408.1k Jan 1 00:06 /lib/libfreetype.so.6

But this size is max (stripped also). You can leave font supports other than true type, it can help on the size issue.

ps: by signing I mean sun fellows will ask us...

selenau
Offline
Joined: 2006-10-11

I'm testing (trying to port) free type libraries to midp. If you can provide me a test midlet (jad/jar file available on the net) I want to check how it works with umlauts.

maybe it can help you, too.

thanks

hallenberg
Offline
Joined: 2007-01-05

I would, if only the midlet I'm testing was freely available...

Shouldn't be hard to make an own midlet (if you know how), just try printing the unicode characters 0x00c4, 0x00c5, 0x00d6, 0x00e4, 0x00e5 and 0x00f6 ('Ä', 'Å', 'Ö', 'ä', 'å' and 'ö').

Unfortunately I just noticed that I have to include 'é' as well :-)

Why wasn't the 0x0080-section just complete to begin with? It would've been much easier for me :-)

Edit: Apparently I had misread my unicode table...

Message was edited by: hallenberg

selenau
Offline
Joined: 2006-10-11

sorry, don't have the tools to create midlet on my pc.

anyway, if you find any midlet with umblauts, just pass the link.

hallenberg
Offline
Joined: 2007-01-05

I created a simple midlet for you: http://dreamcache.mine.nu/upload/midlet.jar

selenau
Offline
Joined: 2006-10-11

root@xscale:/work/pxa/phoneME/feature/build/midp/bin/arm# ./installMidlet http://dreamcache.mine.nu/upload/midlet.jar
Error installing the suite: Reason = 38
com.sun.midp.installer.InvalidJadException: Reason = 38
- com.sun.midp.installer.HttpInstaller..unknown.(), bci=708
- com.sun.midp.installer.HttpInstaller.downloadJAR(), bci=287
- com.sun.midp.installer.Installer..unknown.(), bci=51
- com.sun.midp.installer.Installer.performInstall(), bci=137
- com.sun.midp.installer.Installer.installJar(), bci=87
- com.sun.midp.scriptutil.CommandLineInstaller.run(), bci=342
- java.lang.Thread.run(), bci=5
root@xscale:/work/pxa/phoneME/feature/build/midp/bin/arm# ping dreamcache.mine.nu
PING dreamcache.mine.nu (85.225.235.243): 56 data bytes
64 bytes from 85.225.235.243: icmp_seq=0 ttl=114 time=405.8 ms
64 bytes from 85.225.235.243: icmp_seq=1 ttl=114 time=414.1 ms
64 bytes from 85.225.235.243: icmp_seq=2 ttl=114 time=427.1 ms

--- dreamcache.mine.nu ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 405.8/415.6/427.1 ms
root@xscale:/work/pxa/phoneME/feature/build/midp/bin/arm# ./installMidlet http://wap.jbenchmark.com/JBenchmark2.jar
The suite was succesfully installed, ID: 2
root@xscale:/work/pxa/phoneME/feature/build/midp/bin/arm#

hallenberg
Offline
Joined: 2007-01-05

Sorry, I hadn't added the correct mime types to that server. It's fixed now.

bsher
Offline
Joined: 2007-05-17

I have the same problem. This is the trace:
-------------------------------------------------------------------------

[root@localhost bin]# ./installMidlet http://134.242.66.173/JSR190/Guess/guess.jad
QVFB info: 240x320, depth=16
Error installing the suite: Reason = 28
com.sun.midp.installer.InvalidJadException: Reason = 28
- com.sun.midp.installer.JadProperties.partialLoad(), bci=108
- com.sun.midp.installer.JadProperties.load(), bci=6
- com.sun.midp.installer.Installer..unknown.(), bci=94
- com.sun.midp.installer.Installer.performInstall(), bci=109
- com.sun.midp.installer.Installer.installJad(), bci=42
- com.sun.midp.scriptutil.CommandLineInstaller.run(), bci=358
- java.lang.Thread.run(), bci=5
-----------------------------------------------------------------------------------------------------------------------

I am running the Apache server at 134.242.66.173 as well.

If this is a mime error, how do I set the correct MIME type at the server (as i said, i am the server root as well), as hallenberg points out.

Thanks,
bsher

hallenberg
Offline
Joined: 2007-01-05

How to add the mime types is a webserver specific detail, and you should really ask google for it since it's not actually that relevant to this list. But since I'm feeling generous today I will nevertheless tell you how to do it in Apache. Just add the following two rows to conf/mime.types:

application/java-archive jar
text/vnd.sun.j2me.app-descriptor jad

You will most probably need to restart the server as well (goes without saying I suppose, but you never know).

However, if you ask google (you should, really), InvalidJadException 28 means that your jad-file is incorrect (as you can see above, 38 would have been incorrect mime types).

Personally, I always use the jar files directly when I run installMidlet... Probably because installing from the jad file didn't work in earlier releases of PhoneME, at least not to my knowledge. Maybe they fixed it...

hallenberg
Offline
Joined: 2007-01-05

After extending the bitmaps in gxj_font_bitmap.c manually and still not getting it to work I found the following bug:

midp/src/lowlevelui/graphics/putpixel/native/gxj_text.c (row 83-86):

unsigned long mapLen =
((fontbitmap[FONT_CODE_FIRST_LOW-FONT_DATA]
- fontbitmap[FONT_CODE_LAST_LOW-FONT_DATA]
+ 1) * fontWidth * fontHeight + 7) >> 3;

should be:

unsigned long mapLen =
((fontbitmap[FONT_CODE_LAST_LOW-FONT_DATA]
- fontbitmap[FONT_CODE_FIRST_LOW-FONT_DATA]
+ 1) * fontWidth * fontHeight + 7) >> 3;

This also explains why I got random noise on undefined characters instead of just blanks...

I would file my own bug report if they'd result in anything. My last bug report (former KEY_9, now KEYMAP_KEY_9, missing in the default keymap) is still left unfixed a month or so later. I must say that it disappoints me somewhat, since the fix is so simple... I'd fix it myself if I only had write access to the svn repository.

(As a parenthesis, not only is KEYMAP_KEY_9 missing, but the release key code for KEYMAP_KEY_7 is wrong as well afair...)

stuart_marks
Offline
Joined: 2006-08-24

Hi, I did some investigation of these issues.

The change to gxj_text.c was integrated in r2288, apparently only a few hours after your post. I guess somebody is reading these forums but not necessarily following up. Anyway, thanks for posting this fix! And no, I don't think you need to sign anything. :-)

As for the KEYMAP_KEY_9 issue, this #6, right?

https://phoneme.dev.java.net/issues/show_bug.cgi?id=6

It turns out this was fixed the other day, in r2324 of

/components/midp/trunk/src/events/input_port/fb/native/fb_keymapping.c

At least, KEYMAP_KEY_9 was added. I'm not sure about KEYMAP_KEY_7. It looks right to me, at least its values are in between the values for 6 and 8. Are they correct?

Anyway, thanks once again for pointing this out. We should have followed up on this. I'll make sure the bug report gets updated as well.

s'marks