Recently in OOoCon 2007, I made a talk about the CJK (Chinese, Japanese and Korean) functions what I have been working on. I think it is better to show the progress to the world. If you have any hot issue about CJK functions, please let me know.

Here is the main CJK functions.

CJK functions that have been done:

• Text grid enhancement

• CJK font relevant stuff

• MS Word compatibility options enhancement

CJK functions that I am working on:

• Character/Line measurement unit and ruler

• Paragraph style default settings for CJK

CJK functions that I will work on:

• Punctuation compress

• Bullets and numbering enhancement

OK, I will make a summary for each CJK function so that you could get more knowledge. :-)

Text grid enhancement (i76247)

One of the main CJK functions is text grid which is wildly used in CJK environment. For example, Chinese government document must use text grid with 22 lines per page and 28 characters per line.

However, there are two types of paper mode for text grid. One is "squared" paper mode which OOo supports currently, the other is "Standard" paper mode which most CJK versions of office suite (including MS Word) support.

What's the difference between these two types of paper mode.

For "squared" paper mode, as shown in Figure 1, the page is divided in a fixed numbers of lines , and each line is divided into square cells . The number of lines per page depends on the line height ( i.e., the sum of grid base and ruby height), and the Asian characters per line also depends on the line height.

In this type of paper mode, if we change the "Lines per page" setting in the "Text Grid" tab page, the type are of the page will be changed. This type of paper mode is only used in limited case. Most CJK users have habit to the “standard” paper mode.

Figure 2 illustrates the "Standard" paper mode. As we can see, the lines per page depends on the base text size, while the characters per line depends on the character width. The ruby text is unavailable anymore. Moreover if the lines per page is changed, the type area is not changed yet.

Now, both types of paper mode are supported in ooo-build. In order to ensure only one type paper mode is used in the whole document, as shown in figure 3, a global setting option is provided in Writer tab page (Tools -> Options -> OOo Writer -> General).The codes are also up-streamed which is under QA so far.

CJK font relevant

There are some issues about CJK font in OOo.

Asian font list box ( i73003 )

The Asian font list box in the character property dialog lists all the available fonts even if they are not Asian font in OOo currently. It is better to only list the available CJK fonts.

CJK mess font ( i73003 )

The issue in current OOo is that the selected western font is applied to the CJK text even if the selected western font doesn't support CJK language. So I extend the usage of fontconfig to check whether the selected font supports CJK language before applying the selected font to the CJK text.

Chinese font size (i54603 )

China has his own unit to measure font size such as "五号". Of course, there is a conversion map between Chinese font size unit and western font size unit.

Font substitute (i54603 )

The fontconfig library is extended to use to find more suitable font when the desired font is missing. The patch is initialed by Caolan. We make it more better support Chinese.

Microsoft Word compatibility options enhancement (i78591 )

As we know, in MS Word, there are quite a lot of compatibility options which are used to control layout for different versions.

Now, OOo only supports a few of compatibility options. Most of them are not handled in WW8 filter, which may cause layout different when do .DOC-> OOo -> .DOC converter.

Of course, this is a common issue not just for CJK.

Actually, it is not necessay for OOo to handle all the compatibility options. But in order to improve the interoperability with MS Word, one alternative way is to store the unhandled compatibility options in document model when import a .DOC document, and save them out when export to .DOC document again.

Character/Line measurement unit and ruler (i72655 )

Character/line measurement unit and ruler is another important CJK function that OOo doesn't support now.

As shown in Figure 7 from MS Word 2003, character is used to measured the indentation of the paragraph, and the line is used to measure the paragraph spacing.

Also as shown in Figure 8 from MS Word 2003, the horizontal ruler can be measured by character, and the vertical ruler can be measure by line. Character/line ruler is always used in a document with text grid.

Paragraph style default settings for CJK (i54320 )

Currently, the paragraph style default settings are set for western users, some default values of the paragraph properties don't need the habit of CJK users.

For example, the default font size of western font size is 12pt, while it is 10.5pt for CJK. The current default tab spacing is 1.25cm, while it is too big in writing Chinese. It is better to use about 0.74cm in writing Chinese.

As shown in Figure 9, the current default setting of Asian typography is not suitable for CJK users yet.

Another example is the default value of automatic text indent. The automatic text indent is used to specify the leave spacing for the first line of a paragraph. The current default value is one-character while it is better to use two-characters in writing Chinese as shown in Figure.

Punctuation compress

As shown in Figure 10 , if two Chinese punctuation are close, the first one should be compressed to occupy only half spacing of a Character, not full spacing of a character.

Butters and numberings (i70031 , i69855 )

I have heard many CJK users to complaint that the bullets and numbering are not so good.

For example, OOo can only automatic recognize Arabic numbers or alphabets. Most CJK numbers can not be automatic recognized.

In the end, some important CJK functions are listed in the following wiki. http://wiki.services.openoffice.org/wiki/CJK_Group
If you have any good idea or suggestion about CJK functions, you are welcome to discuss in the wiki.

I can't start KDE4 any more - it fails to start dbus. To be more exact, qdbus gives this error message when it is run:

Could not connect to D-Bus server: org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute dbus-launch to autolaunch D-Bus session


But when I run dbus-launch it works fine. I'm sure it's probably something simple, but I'm about ready to give up.

On Sunday, Alma and I brewed a small batch of ginger ale. We roughly followed the directions at http://www.wikihow.com/Make-Ginger-Ale. We deviated from the recipe a little bit in using limes instead of lemons. Hey, we're in Mexico — what do you expect?

It finished brewing this morning (by our estimation). We let it refrigerate during the day, and just now opened and tried it. It was pretty good.

Next time, we'll probably use fewer limes, so it's less citrusy; more ginger; and more yeast, so it comes out fizzier.

Not bad at all for a first try!

Another milestone in the journey of Evolution mail client - 2.12 is released. This is srag's (Srinivasa Ragavan - Hope I got your name right, this time - Srini) maiden release and it rocks. Good job, Srini. A preview of what it provides is here.

This release is special, personally, as:

This is the best release made after the initial 1.x days of Ximian Connector. It all started from the days of SLED Betas - getting Beta customers to test and report issues, fix and provide packages to reverify. Exchange connector has become quite stable and just like other softwares, with some bugs. Connector has a better summary support, optimized n/w bandwidth usage, majorly rewritten folder loading/refreshing techniques, on-demand-public folder loading and newly implemented mail/calendar delegation feature that enables your colleague to handle your mail/appointments when you are away from office .

Thanks to all the customers/community users who provided test accounts to debug complex issues that are otherwise not possible to debug and fix. Remarkable improvement has gone into Connector in this release, especially in a state where people started recommending to use IMAP to access their Exchange mails instead of Connector.

Special thanks to Dan Winship for his time and help in answering my libsoup and connector related questions.

Okay. I haven't yet mentioned why this is a special release to me. ;-) This is my maiden release as Exchange Connector Maintainer. I took up the task with solving performance and stability issues as number-one-priorty than adding features and with much pride I declare this to be one of the best releases of Exchange Connector.

Some of the performance work that has gone into this release, for your joy.
[1] - Folder loading optimization
[2] - On demand loading of folders (esp. public folders)
Watch out for more optimization work to be done in Exchange connector module.

Onething, I tried hard to accomplish is the Exchange 2007 support - which will be a part of 2.14 release of Evolution.

Back from the OpenOffice.org Conference 2007 in Barcelona

Good to meet people in person.

Talked at lot about

• Harmonization between ODF and OOXML,
• Trade-off between Standardization and Innovation and
• Interoperability wrt. ODF<->ODF and ODT<->.DOC
  

Some pics from the conference:

(Thanks Peter for great evening.)

(Thanks to the people at the ODF Camp)

(Thanks to Kohei, Hubert and Noel for the great time at the XXVII MOSTRADA DE VINS I CAVES DE CATALUNYA)

I hope I can find some time to go into more details.

Let's change today, Talk Like A You-know-what Day, into a mere hour.

Seriously. Talk Like A Pirate Hour: it's the new hotness.

Free Software driver for RadeonHD released

Last night we have pushed out the initial developers release of the RadeonHD driver for ATI's RADEON R5xx and R6xx chipsets. After a long dark period of no specifications AMD has decided to not only make code but also specifications available to the free software community.

So far we have seen specifications to do mode setting and possibly a little bit of video overlay. The specs cover most of what is needed to enable different outputs (VGA DAC, TMDA for DVI and LVDS for panels) TV out is not yet on the plate.
Also they allow to implement video overlays (classical color key overlays).

People are wondering if AMD's move was a one time PR blitz to muffle their biggest critics in the free software community.
My personal take on this is: I don't think so.
AMD has a long history of successful cooperation with the free software community. This cooperation was crucial for the success of their x86-64 project (we are only beginning to see versions of MS Windows appear which are 64bit capable).

In the past 4 month our X Developer Team at SUSE has worked extensively with AMD to make these things happen. We have only been dealing with people form AMD with technical background  - no marketing people were involved.
Everyone involved has shown a great willingness and worked hard during long hours to do whatever it takes to open up the
specs and provide whatever it takes to get a free driver going.

Yes, we did encounter delays. Most of them were due to fact that what has happened here is a novelty in the graphics chipset
industry. Tools had to be implemented, processes had to be created, legal issues had to be resolved.

How did it all start?

Around mid of April (4 1/2 month ago) I have been contacted by AMD and asked to put together a proposal how an open source driver for the latest generation of ATI hardware could become reality. Our team wrote a proposal which included as two major goals:

• involving the free software community in the development process early on  
• make chipset documentation available to the community with no strings (read NDA) attached.
  

Following this AMD and SUSE started talks about developing an initial driver to get the community process going. After the details were agreed upon we received the first set of documentation (then still under NDA) in late July and and have been hacking on this driver since then.

Linux Vendors

To most Linux OS vendors like us at SUSE the unavailability of  a free driver has created a huge burden. At SUSE we have made the conscious decision to not ship any non free software with out base product (even without this policy  in place the GPL violation issue in the kernel would have prevented us as an OS vendor to ship the proprietary driver with our base product).

This however meant we were not able to ship a proper driver for a widely used range of hardware with our product.

We at Novell as a company we worked extensively with ATI and later on with our partner AMD to explain the dilemma and find ways to change this situation. Most of these discussions have not taken place in the public eye. After all it be bad style if business partners gave each other advice in public on how to do business.

Why did it happen right now?

Changes in paradigms like what we have seen here don't happen over night. As for any commercial entity there needs to be some business justification as such steps require effort and thus cost money.
Business justifications evolve either when the business model of a company or the business environment changes.
Here both things have happened:

•  ATI has been purchased by AMD. AMD had a different business model in the Linux and free software market than ATI had.
• The business environment has changed: the b2b market (and this has been the market where conclusive data existed in terms of how much it is paying the bills) requires a free driver more than before.
  

The opportunity

To me AMD's move looks like a great opportunity. For the first time in many years graphics chipset documentation is made available to a broad public without the requirement of any NDA.

In fact I have a hard time to remember when I was able to download graphics chipset specs from a manufacturers web site without having to go through a pile of paper work.

AMD puts itself somewhat ahead of other graphics chipset vendors: In contrast to other free drivers for which only code but no documentation exists this approach allows a broad development community to poke bits and registers in crazy new ways to try out crazy things things that are not on the plate of those who are paying for the driver development.
Even if we won't see all results from these hacks appear immediately in the next release of the driver I expect it to kick off a lot of new development.
For a long time our community was somewhat cut off from the the information what state-of-the-art hardware was capable of. New features were limited to what hardware manufacturers - even those who developed free software drivers - considered to be a must-have for their drivers. This all is going to change now.

We openSUSE GNOME people are updating what will become openSUSE 10.3 to GNOME 2.20.0.

So far, it's proving to be rather light work, and really not all that frantic, although we do intend to finish this update very soon. The mail Gary sent last week has the details.

The fine work done by the GNOME release team makes this relatively easy, so many thanks to them.

An interesting interview with author Haruki Murakami. (In Spanish.)

Office 2.0 conference

I'm just back from the Office 2.0 conference in San Francisco. I was participating in a panel discussion about Document Formats:



Very nice crowd the Office 2.0 guys. They really taught me to think more about collaboration.

Many thanks for the nice presentations. (And for the insight that most of you use OpenOffice.org to convert between HTML and the other file formats ;-))

Ahh -- and almost forget. I will look into OpenSAM. Promised. Sounds really like a good idea for OpenOffice.org supporting it.