Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Tomcollins

#16
I think DFM, as it is now, doesn't 'know' this bom, so the first entry may not show up properly.. (at least I think I had problems once)

But you are right jeff, i also think that we should work with boms! Also dictionaryInputFiles with boms should be possible, since there maybe users who don't know how to easily remove it.

jeff: I think there is more then one problem, so I think you can wait till I have located them and updated the bitmapfontGeneration, before you test it again. Strange that it works with other fonts!?!

Sebastian
#17
Jeff:
I think the problem is with the "byte order mark"/header-character, which is not removed in your dictionary. (if you use e.g. hexplo, then you can see an EFBBBF). The Font Generator cannot handle this "character" properly yet.
I'll do an update of the Font Generator these days, which takes care of this "character".

Gert: Maybe we should remove the header by dictionary generation automaticly, if it exists, since many people forget to remove it.

Sebastian
#18
1) seems to be a problem with the settings store. Do you have an idea Gert?

2 & 3) & 4) is all the same; This one is unfortunately really a bug of the bitmapFontFeature; I already located it, but it'll take some more investigation how to fix it. Strange that it never happend with the chinese, since there are much more characters in it...
I always use ArialUnicodeMS...

5) I don't really know. Maybe a bug in DFM generally which I've with the settings too. Please try: first change to 10 and then change to 14.
On W700 I've this problem too with the interface language. I always have to switch back to english before i can choose another language. Do you have this problem too?

6) I think the same as 2,3 & 4.

Thanks for your detailed testing.

Sebastian
#19
Well, there's a lot to tell about chinese, but the as for pinyin input: I personally mostly (over 90%) just use 'xuesheng' as input (without tones). Often you even don't know the tones and there are not so many combinations. For the HanDeDict-DFM I actually just added the pinyin without tones to the search index, since from my experience it's the most useful.
A really advantage would be an IME for chinese characters, but this seems to be a lot of work.
200kB: HanDeDict is 7MB an works well on (several) phones. So that would be ok!

Thanks also for all the other information on IME and the languages!
Seems, there's still enough to do!

Sebastian
#20
Quote from: Gert on 12. May 2007, 04:48:18
I prefer 2) - which is what I was asking you to postpone to 3.2 only a few days ago ...

Can you update DfM and JarCreator ?

I can then build version 3.1.2 of both - or do you want to do the build ?

Gert

I can update DFM, I cannot update the JarCreator, since I don't have the time to get familiar with it.
I updated the JarCreator, so it ignores the fonts directory, but it does not yet copy it to the jar file!
So one has to copy it manually into the jar file again, until someone finds the time to update the JarCreator!
DFM expects the fonts now located at /dictionary/fonts/, like it is generated.

Sebastian
#21
Hi!

1) Well. For a lot of languages there's some kind of transciption to basic latin. e.g. in chinese that would be pinyin. And if this transcription is added in the search index it's no problem to search for e.g. chinese with devices, which do not support chinese characters.
Although a IME would be very nice. (I once talked to one doing an chinese ime by himself but he said that a big problem is to get good complete char lists.)
2) I'm not so familiar with the languages you mentioned, but I know that there are also many character-combinations added as one character in unicode! We have the same problem with the chinese pinyin, since there are tones on the vowels. Like xue2sheng1 should be xuéshēng. We do the convertion with a languageUpdateClass so it is just one character in the dictionary and in the bitmapfontImage.
Could that work for some of your mentioned languages too? Of course, this is just for passiv (displaying) and doesn't work for active input..

Sebastian
#22
Hi!

Yeah! There's a problem with the jarCreator. It expects just two different types of files in dictionary (font.bmf or .csv) but no folders like the new "/fonts/". So we have to make an update for the jarCreator. Sorry!
1) Copy it into an seperate folder like before or
2) Ignore it and leave it in the dictionary directory (which would mean we have to update the DFM too)?

What do you prefere Gert?

Sebastian

#23
Hi!

It's funny, since all your postings reflect the development of my first cedict dictionary for mobiles. We first had problems with the pinyin, then I didn't want to switch the language, so we implemented this and one of the last thoughts was also the sms translation (something like: just the marked text is translated). We implemented all this quite fine, but unfortenately it is just for symbian 2.1 mobiles (SonyEricsson P908/910) so I joined this project.

Well, I know which features are useful and I also want to implement some more, it just takes time...
But the language switch should be quite fast if you use the keys: menu-key --> switch language key (should be #1 or #2)...
I think we will implement the pinyin for the next version with normal vowels with numbers first. And we'll do a later version with both pinyin version, so one is able to choose, which is shown. Unfortunately this feature won't be implemented in this version, but stay tuned...
Nice to see that someone is interested!

Sebastian
#24
Hi!

The dictionary uses the fonts of the devices (mobiles). these fonts are sometimes limited. e.g. some the vowels with tone marks are not "in" the font of the mobiles. So in this case it is your device (unfortunately like a lot of devices), which does not support some specific vowl-with-tone-characters.
We are working on a new feature for our dictionary, which is the use of a bitmapfont, which means that the software uses its own fonts, not the one of the device. This font will have all necessary characters (also all vowels with tones). We will also provide a cedict version with numbers behind the pin1yin1 too, but we are waiting for some additional features till we do an update.

Sebastian
#25
Problems / Re: BITAMP Bug
06. April 2007, 12:34:50
Hi!

Thank you for your report!

I think that the .png used are too big for some mobiles.
I guess if you use smaller png (another dictionary or add just some chinese characters to the font) it should work.
Maybe you can try to use this small test dictionary and font (search for 'a' or 'abasi' or something):
http://stud3.tuwien.ac.at/~e0225729/mid_bitmap/small_png.zip
please let me know afterwards.

Now we have one single .png for all characters and I know this is a big problem.
It works on the emulators with the big png s so i think it should at least run on some mobiles.
But we should split the big png s like for chinese, japanese fonts into several smaller files if this is a problem for the devices....

Sebastian


#26
Hi!

Thank you very much for your posting!!

1) I know about the problems with the accents. Most of the mobiles don't support some of these Characters. In the Chinese-german version in changed it to pinyin with tones, e.g. pin1yin1. I can provide a version using Cedict too, i'll let you know when it's ready.
2) java is slow, but maybe there will be improvements in later versions... (on newer mobiles it also might be a little bit faster.)


1) i know, i want that feature too, but it will take some time and someone to implement it... (also see 3)
2) see 2
3) well you can not edit it on the fly, but you can edit in the cedict, and then generate and create a 'new' dictionary (see setting up a new dictionary). in the beginning it's seems lots of work, but the second time its easy and fast (few minutes).
like that you could also just delete the traditionals you don't need! and you can change other things too!!
If you need some help with the setting up, let me know!

Greetings,
Sebastian
#27
Hi Gert!

In which version and when occured the first errors with SE? What where these first errors?
Starting with which version did you implement the SE workaround?

Greetings,
Sebastian
#28
Quote from: adenin__Hi Peter and everyone else!

I got the cvs directory with all the source files and a build file included from you (Peter Kmet) two weeks ago by email. Now i wanted to start to get a little bit familiar with the DictionaryForMIDs itself, not just the Generation and the Creator. But my first attempts to compile the code and put it into a jar file, so the creator takes it as a empty DFM, failed....
Maybe you could send me another build file including the build of the DFM or give me some hints how to create an empty DFM out of the source code.
I just want to try a little bit and later on, maybe if I've got some improvements i can send them to to you (or even join you as a developer)...

Greetings,
Sebastian


Quote from: adenin__Hello,

you can use this approach:

1. Install wtk 2.5 (not beta2 - it doesn't work for me with it);
add line
javac.encoding:utf-8
into
WTK25\wtklib\Windows\ktools.properties

2. run WTK25\wtklib\Windows\bin\ktoolbar.bat
choose new project, there:

proj. name:what_you_want
midlet class name:de.kugihan.dictionaryformids.hmi_j2me.DictionaryForMIDs

then copy source tree from cvs (DictionaryForMIDs)
into WTK25\apps\what_you_want\src\

(WTK25\apps\what_you_want\src\de\... )

3. download prepared DFM (e.g. http://prdownloads.sourceforge.net/dictionarymid/DictionaryForMIDs_3.0.3_EngGer_freedic.zip?download)
...unpack jar file, (you can rename it to .zip ...) and from its content copy all directories except de\... into
WTK25\apps\what_you_want\classes (in this case these are 'dictionary' and 'char_lists' )

4. choose build and then Run ....and that's it !!! uoala


Quote from: Tomcollins...sad is, that I wanted to do all that work with ant scripts, but I have problem with verifying ( I must
somehow go through problem:

preverify:
[exec] Error preverifying class de.kugihan.dictionaryformids.dataaccess.DictionaryDataFile
[exec] VERIFIER ERROR de/kugihan/dictionaryformids/dataaccess/DictionaryDataFile.initValues(Z)V:
[exec] Illegal type in constant pool
[exec] Result: 1

...I found just two links with solving of this problem by preverifying on google but without solution
maybe someone has Idea what it could be..

Peter


Quote from: adenin__Hi!

Thanks for your help.
Its just, that i couldn't find the wtk 2.5 (not beta release). I just can find the beta release. Sorry to bother you about this, but do you have a link where you can download the kit or something?

Thanks,
Sebastian


Quote from: Tomcollinsit works even with beta 2
...I have tried it now ...

I just take whole content of ktools.properties from wtk25 and pasted it to wtk25 beta2

put there this (content of old ktools.properties):
# @(ktools.properties 1.13 05/12/14

javac.encoding:utf-8
kjava.preverifier.command: bin\\preverify.exe
kjava.class.path: lib\\midpapi20.jar;lib\\cldcapi10.jar
file.extension: jad
obfuscator.runner.class.name: com.sun.kvem.ktools.RunPro
obfuscator.runner.classpath: wtklib\\ktools.zip
obfuscate.script.name:
com.sun.kvem.event_ui_1 = com.sun.kvem.midp.LocationEventGenPanel
com.sun.kvem.event_ui_2 = com.sun.kvem.midp.FileConnEventGenPanel
com.sun.kvem.event_ui_3 = com.sun.kvem.midp.TransactionPanel
com.sun.kvem.toolbar.aboutDialog.height = 266
#A flag indicating whether MIDlet-Permissions and MIDlet-Permissions-Opt
#attributes will be checked in JAR file if they are missing in JAD file
#com.sun.midp.installer.checkJarPermissions = true
# MMAPI Java 2 SE system properties
mmapi.soundPlayer:
mmapi.videoPlayer:
# MMAPI Java 2 SE system properties
mmapi.soundPlayer:
mmapi.videoPlayer:

.....that's all

Peter


Quote from: adenin__Thanks very much!!

Seems that everything works now. Great!

Sebastian

(Edit by Stefan1200: Made posts more readable)