星期四 2007年03月15日
JDK 6 API doc Simplified Chinese version published! JDK 6 API doc 简体中文版新鲜出炉！
HTML:
http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/html/zh_CN/api/
HTML zip:
http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/builds/latest/html_zh_CN.zip
Windows CHM version:
http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/chm/JDK_API_1_6_zh_CN.CHM
星期五 2007年01月26日
JDK API online translation tools from James Gosling Currently, we are working with James Gosling on an online translation tool, see:
https://docweb.dev.java.net/
This tool is very cool:
1. Support 30+ languages.
2. Through this tool, the community translators could translate/read the JDK API on the website, also he/she can vote the translations.
Now, we are working to fix some bugs, and will add more features on it, such as:
1. import CMNT files from existing Chinese/Japanese/Brazilian Portuguese projects.
2. export to CMNT files.
3. Add statistics for untranslating string.
4. sort classes by package name.
...
JDK 6.0 API 中文版已完成99%， 欢迎审校。
今天发现翻译人员checkin非常多的更新。 一检查log, 发现已完成99%的翻译。 离全部翻译完成仅一步之遥。接下来还要做很多的审校工作。
详情请见：https://jdk-api-zh-cn.dev.java.net
星期一 2006年01月02日
Plans For 2006 So long not update my blog. 
In the first day of 2006, I stayed at home, quietly. but still some mixed feeling springed up.
Maybe it is good time to wrap up what had be done in 2005, and begin to plan what to do in 2006.
Achievements in 2005:
1. Finished IIIMF project on JDS for Linux. and launched OpenSolaris and Solaris 11.
2. Finished Java Enterprise System 4.0. and launched 5.0.
3. Work on Chinese localization for Java SE 5.0 API documents. Currently we have publish two batches on SDN (http://gceclub.sun.com.cn/chinese_java_docs.htm), and receive a lot of reviews from community(http://gceclub.sun.com.cn/NASApp/sme/jive/forum.jsp?forum=3)
Plans in 2006:
1. Continue on Java Enterprise System 5.0. mainly focus on Identity Manager/Access Manager/Directory Server/Outlook Connector.
2. Continue on Chinese localization on Java SE 5.0 API documents. will finish all in June 2006.
3. Setup one team to begin on a localization tool (which is called ULA) to simpify the l10n processes, hope we can open it in 2006 and deploy it for open communities, such as: Solaris/Java/Netbeans/OpenSolaris/OpenOffice/Gnome/Mozilla.
Anyway, Happy New Year, my friends!
星期一 2005年05月30日
Proposal for IIIM GIMLET enhancement To improve the usability, I'd like to propose a big enhancement with gimlet which based on significant redesign of gimlet, instead of bug fix.
We can make Gimlet act as an iiim desktop service agent, and have the following features:
1. Support PreFilter modules to do some preprocess for the keyevent before send to iiim server, such as:
a). Hotkey filter, different engines/different users/defferent locales may have different hotkeys.
b). keymapping filter.
2. Support common GUI modules, such as:
a). common status/preedit/candidates window
b). common configuration window
c). virtual keyboard.
d). should be scalable to support different window system, such as gtk/qt/Windows.
e). should be scalable to support iiimcf/user defined GUI(status/preedit/candidates) modules.
3. Provide interface to support local input modules, such as:
a). handwriting
b). voice recognization.
c). character lookup table.
d). user defined input engine.
e). user defined characters for specific input engine.
f). user defined keymapping.
4. Provide interface to support PostFilter modules to do some conversion for the commit result from iiim server, such as:
a). encoding converters, such as UTF-8 <-> big5
b). phrase converters, such as Simpified Chinese phrase <-> Traditional Chinese phrase.
c). others, such as, hagual<->hanja ...
d). user defined postfilters.
Each filtering should be registered whether or not they are needed so that the process can be ommitted.
5. Provide overall configuration panel to support:
a). input methods disable/enable
b). input method properties setting.
c). GUI styles switching.
d). Hotkey definition.
e). local input engine definition.
6. Support systray as Windows.
Event flow:
Two scenarios:
A). Fontend mode
gimlet can implement as a desktop service agent for iiim clients and server.
1. iiim client register gimlet for iiim desktop services. if not register, the iiim client events will be sent to iiim server directly.
2. iiim client sent events to gimlet first.
3. gimlet do prefilter process for the events.
4. gimlet sent prefilter result to iiim server.
5. iiim server send status/preedit/candidate/commit info back to gimlet.
6. if status/preedit/candidate info, gimlet use common GUI modules to show them.
7. if commit info, gimlet call postfilter modules and commit the result.
B). Backend mode
gimlet can implement an additional capability as a mini-cascaded server so that a possible optimization is possible, so that this significant modification proposal is a part of bigger picture.
gimlet is still on the desktop, however event is first sent to the server, then forwarded to gimlet, then gimlet perform pre-filter, then send back to the server and LE, then send to gimlet for post filtering.
星期二 2005年05月10日
Cairo Postscript Backend Cairo will be the next generation rendering engine for Unix/Linux. it use uniform architecture for display and printing, just the same as Windows GDI/GDI+. These days I discussed about the current status of cairo postscript backend with Owen Taylor. As Owen said, currently, The PDF backend is closer to working "right". It currently has some bugs in embedding fonts, but should work almost OK for CJK TrueType fonts, though not for Type1 fonts (especially CID fonts.) But for PS backend, it just generates a big image. and Kristian Høgsberg is starting to work on a "real" PS backend. The first piece of work needed for that is cairo infrastructure ... a way of figuring what areas of drawing can be drawn with Postscript primitives and what areas need to be drawn with images. (Because of alpha transparency, for example.) There will be lots of work after that to fix up embedding of different types of fonts into Postscript files. That's a good chance to plug ourselves into this project and do some contributions.
( 2005年05月10日, 10:17:57 上午 CST )
Permalink
评论 [0]
IIIMF 12.2 is released and IRC meeting for 12.4 On 2nd May, which is a day of golden week in Japan and China, IIIMF version 12.2 was released.
The announcement see: Leon Ho's announcement
That is a really a great milestone that we added so many features in this release.
Now, we are moving forward to next release 12.4.
Today, IRC meeting (irc.freestandards.org/#iiimf) is opening to discuss the following topics:
* Schedule
* Feedback on feature implementation
* Feedback from users on usability
* Things that we need to keep on doing
* Things that we need to improve
* QA
* Release engineering
Welcome to join!
( 2005年05月10日, 08:49:23 上午 CST )
Permalink
评论 [0]
星期四 2005年04月21日
CJK Type1 printing for firefox 1.0.2 on JDS3 The Chinese/Japanese/Korean Type1 printing patch still not integrated in firefox 1.0.2 and 1.0.3, although it is already in firefox trunk for several months.
Last week, I spent one day to backport the CJK printing patch to JDS3 firefox workspace. so the CJK printing will be fine for JDS3.
Now, very interesting things happened that different printing technologies are used for different applications in JDS3.
1. firefox use Type1 fonts.
2. mozilla use CID-keyed fonts, which defined as Type9.
3. Gnome use Type42 fonts.
4. Starsuite8 use Type42 fonts.
5. Starsuite7 use Type3 fonts
( 2005年04月21日, 10:20:53 上午 CST )
Permalink
评论 [2]
星期二 2005年03月29日
TODO lists for IIIMF from 03/04 - 12/04 TODO lists for IIIMF from 03/04 - 12/04
I am on vacation this week (28/03 - 01/04). next week I will begin to do the following works:
* Documentation.
* port charmap/symbol lookup auxiliary window from Solaris 9.
* m17n language engine.
* memory leak checking in leif/IME/auxiliary window.
And for documentations, need collect the user manuals for the following input methods:
* SunPinYin.
* Chewing.
* Dayi.
* Boshiamy.
( 2005年03月29日, 06:46:43 上午 CST )
Permalink
评论 [0]
星期日 2005年03月27日
A very good website about Traditional Chinese I18N/L10N processing Just read one very good website about Traditional Chinese I18N/L10N processing, see:
http://wiki.debian.org.tw/index.php/ChineseInformationProcessing
I got it from Jserv's blog:
http://blog.linux.org.tw/~jserv/archives/001084.html
Thanks jserv and some other people's hard work to collect so many good Chinese processing informaiton.
( 2005年03月27日, 11:49:41 下午 CST )
Permalink
评论 [0]
Reply James Su 答苏哲书: Reply for James Su's comments: http://blogs.sun.com/roller/comments/eyan/Weblog/what_s_difference_between_iiimf#comments In your comments, too many subjective, unproven statements would just create confusion and not beneficial, so I would stay just correcting the misunderstandings. It is wasteful to split precious resource into two projects especially if as James says SCIM can support thin client to rich client as IIIMF do. SCIM does not have a scalability of distributed framework and IIIMF does not have simplicity of library. It's just the design difference. You do not have to attack by using emotional groundless arguments like James> In my view, IIIMF is more like a commercial/close source James> product. It's not a good opensource project. It would be ideal to work together instead of splitting the resources. We all better understand that every medal has two sides. Then you can see so many minunderstandings you have: * James> 1. IIIMF must use namespace storage api, It makes almost impossible to use 3rd input method library in IIIMF LEs, because those libraries always handle files/databases themselves. -> SCIM does not provide namespace, LE has to handle by themselves. * James> 2. IIIMF must handle multi-user issue It makes LEs much complex than single user model.I always don't understand why input method should be a system wide service. Why input method can't be an user application just like firefox OOo or something else. -> Acturally not correct, IIIMF can also use vmseperator for single user model. -> SCIM is not capable of multi_user, so serious LEs who WANT to handle multi_user won't work. * James> 3. Must implement aux object to get better GUI Implementing. aux object is nightmare for input method developers, at least for me. -> Actually not correct. -> SCIM is not capable of per AUX/LE, so serious LEs who WANT to handle AUX won't fit well. * James> 4. Very few utility functions to help development LEIF is just an API interface, it lacks a library which contains utility functions to help LE developement. -> very subjective * James> 5. LEIF interface is very hard to use Just as jserv said before, he spent several weeks(days?) to hack iiimf-chewing but couldn't get it work. But only spent half of a day to get scim-chewing work. -> LEIF interface provides multiple levels for flexibility. Should choose right level of interface. There is also one chewing module in IIIM tch_le_sun LE, totally ONLY 600 lines of source codes, but support all the features of chewing, including customizable preedit/candidate windows, user perference for chewing input method properties(developers need only specify the properties arguments and need NOT write any GTK/QT sources to implement it), warning beep for wrong input sequence, keyboard layout displaying for 8 kinds of different keymappings, support hundreds of users with different preferences at the same time in ONE single backend thread, etc. While SCIM chewing module spend 1200 lines, and still some of the above features are not supported in SCIM chewing module. -> SCIM LE interface is not flexible to keep ABI due to C++. * James> 6. Many design/implementation issues for example: James> a) Doesn't support multiple input methods in one LE very well. -> Not true. James> b) Doesn't support Key Release event (has it been fixed?) -> This is true for the moment. Will be fixed. James> c) xaux is tightly binded to X Window -> This is true, as SCIM's helper is also tightly binded to X Window. -> Don't forget AUX is originally designed for Java object. * James> Otherwise there wouldn't be so many additional wrapers on top of James> IIIMF, eg. Unihan, ThizInput etc. -> They are not wrappers. Anyway, both IIIMF and SCIM have their advantages, and disavantages, if we put precious resources together on input methods improvement, I think, the community and end users will applause for the cooperation of IIIMF and SCIM. ( 2005年03月27日, 08:55:56 下午 CST ) Permalink 评论 [2]
星期四 2005年03月24日
IIIMF Common GUI Framework IIIMF Common GUI Framework.
We need a cross-platform implementation for IIIM GUI
components, to avoid extra costs and efforts to maintain multiple
UI implementations for different platforms, unix, mac and windows.
Therefore, we can use XUL (XML-based User Interface
Language) to describe UI components, and use JavaScript and XPToolkit
to provide implementation (appearance and behavior) of the
UI components.
These UIs includes:
* Preedit
* Status Indicator
* Input Mode Selector
* Lookup Choice
* Character map/Character Palette
* On-Screen keyboard
* Preference Editor
* Hotkey Editor
* Help
Need implement one prototype recently.
Some useful websites for XUL:
XUL project website: http://www.xulplanet.com
XUL Alliance website: http://xulalliance.org
( 2005年03月24日, 09:23:24 上午 CST )
Permalink
评论 [0]
星期一 2005年03月21日
What's difference between IIIMF and SCIM Someones discusse such article on Linuxsir website, see:
http://www.linuxsir.org/bbs/showthread.php?t=180826 (IIIMF 相对 SCIM 有何优势，FC 要选择它？)
I thinks the differences as follow:
1. different design philosophy (设计哲学)
SCIM: KISS (Keep It Simple and Stupid) and 20-80 (use 20% resource to finish 80% features).
IIIMF: 100% meet the input method developer's requirement.
2. different priority on FrontEnd and Backend:
SCIM: High priority on GUI and user experience.
IIIMF: High priority on input method control and backend services.
From the view of MVC (Module/View/Control) model, IIIMF more focus on Control side, while SCIM more focus on View side.
3. different professional level for the design of API (Application Programming Interface)/SPI (Service Provider Interface)
IIIMF provide professional IIIMCF (IIIM client framework) APIs so that all kinds of applications can call IIIMCF APIs to get input methods services from IIIM server. that's one possible that we can replace XIM with IIIMF in the low_level implementation in X11 and applications (such as StarOffice).
SCIM have no such kind of designs.
4. different market target.
IIIMF focus on market with enterprise system environment, for example, thin client system.
And end users more like SCIM.
from the development view of input method architecture, I think, in the long run, IIIMF have more possibility to survive and become one industry standard because it is more scalable that it can accommodate itself to input system with different complexity, from most simple to most complex.
if IIIMF developers put more resources on the GUI enhancement, then IIIMF will everywhere. X11, GTK, Qt, Windows ...
I think, That's why FC choose IIIMF.
( 2005年03月21日, 11:31:59 下午 CST )
Permalink
评论 [2]
A good article about how to install Debian Just read one good article about how to install Debian system. blog it for share. http://apt.nc.hcc.edu.tw/docs/debian_X/ 前言 VMware Workstation 下載 網路安裝光碟映像檔下載 新增 Virtual Machine Debian GNU/Linux 基本系統安裝 基本系統設定 ( 2005年03月21日, 10:33:42 下午 CST ) Permalink 评论 [0]
