Red Carpet, that is. Yes, that Red Carpet. I’ve taken some time lately to give some love to our old friends rcd and rug (the original rug, not the rewritten one). First I got everything building on a modern distro (openSUSE 10.2). This took more effort than I thought it would, but eventually things worked well. After that, I set out to make rcd more usable with yum services. Here is a list of the main changes:

• Add native yum support. I removed the ‘helix’ service support and replaced it with something that understands yum metadata. This means you can just do ‘rug sa repo_url name’ for any yum service. I used the excellent yum parser that Tambet wrote for the libredcarpet backend of zmd to accomplish this.


• Remove channel subscriptions. Since yum services don’t provide multiple channels, subscriptions aren’t really necessary. They have been replaced with the ability to disable a service.


• Add sleep ability. One of the main complaints against rcd was that it used too much memory. This was mostly because over time the heap would become fragmented. The ‘sleep’ feature avoids this by running the main rcd daemon only when necessary. After a period of inactivity (3 minutes by default), the main daemon replaces itself with a smaller daemon. This smaller daemon simply waits until a request comes in and launches the full daemon to respond.

With the above changes, rcd is once again a joy to use. I would like to get the GUI working again, but there is some kind of threading problem preventing it from running. I would also like to add ftp support, but that is not a top priority.

I know there are probably SUSE users reading this asking “Ok, sounds fine, but is it fast?”. While it may not be the fastest thing out there, I think you will be surprised at the results (I was). Here are a few simple benchmarks from normal usage scenarios:

First, lets look at the number of services I currently have added:

% rug sl

    
| Service URI                                           | Name       

—+———————————————————————————+——————

1  | http://go-mono.com/download-stable/suse-102-i586?r… | mono       

2  | http://software.opensuse.org/download/FATE/openSUS… | fate       

3  | http://ftp.suse.com/pub/suse/update/10.2/?name=upd… | updates    

4  | http://download.opensuse.org/distribution/10.2/rep… | suse-nonoss

5  | http://download.opensuse.org/distribution/10.2/rep… | suse-oss   

6  | http://packman.inode.at/suse/10.2?remote_only=1;na… | packman    

7  | http://software.opensuse.org/download/home:/cybero… | cyborg     

8  | http://software.opensuse.org/download/X11:/XGL/ope… | xgl        

9  | http://software.opensuse.org/download/Beagle/openS… | beagle     

10 | http://software.opensuse.org/download/games:/actio… | games      

11 | http://software.opensuse.org/download/Virtualizati… | virt       

12 | http://software.opensuse.org/download/home:/kraxel… | kvm

So 12 services, and the package count is almost 21000. 22500 if you also count the ones in the rpm database. How long does it take to load all of those?

Cold filesystem cache, daemon is sleeping:

% time rug ping > /dev/null

rug ping  0.17s user 0.02s system 1% cpu 13.735 total

14 seconds to respond isn’t terrible, considering the cold filesystem cache. Now that the kernel has it cached, though, how long does it take?

Warm filesystem cache, daemon is sleeping:
<blockquote

% time rug ping >/dev/null

rug ping > /dev/null  0.14s user 0.02s system 3% cpu 4.465 total

4.5, not bad. Definitely in the tolerable range, I’d say. Of course after the daemon is awake, commands respond immediately. That is maybe the only good thing about rcd being a daemon — subsequent commands are instant, where other tools (yum, smart, etc) have to load the package metadata again. Memory usage after rcd wakes up is about 28MB, so that is not too bad either (it is a little over 1MB when sleeping).

Packages for recent SUSE distros are available in the build service. It has had a hard time keeping up recently, though, so you may run into a problem or two with rug. Sources can be found in gnome svn in the yummy branch of the various modules (rcd, rug, libredcarpet).

Also, yes, I am sick sick person.

Found some hiking companions. Sadly not for the Wicklows, but the Franconian Switzerland which isn't bad either. Had a good start. Didn't find our way and went to the opposite direction. Some pub visits helped us to reach our final destination. Continued my walking excercises in Olpe. What an enchanting landscape! Maybe I should move here, get myself a dog and settle down. They even started building a cinema! Missed the second hike to the right direction. Was too early for me. Booked the flight to Paris for mouse and me. Mouse has to get ready for the big fight as soon as he's back from Australia.

Smart Documents.

Yesterday I started the evaluation of the Microsoft's ISmartDocument interface for Office2003.
I started in a clean VM. I installed:
* Windows XP
* Office2003 and
* DevEnv 7.1 (C#)

Then I downloaded and installed the Office 2003 Smart Document Software Development Kit (SDK)

Next I tried to compile the “SimpleSampleCS” from the SDK.

It failed.

Some research showed that I had also to install the Office 2003 Update: Redistributable Primary Interop Assemblies.

Finally I was able to compile the project.

Next I tried to activate the smart document by simply opening the “SimpleSample.doc” in Word 2003. I ran the “setpolicy.bat” script and then the “DisableManifestSecurityCheck.reg” file. Then I opened the “SimpleSample.doc” and was asked to “Download the XML expansion pack”. After answering the security question with “no” I was able to get the sample working. (Other orders of invoking the scripts lead to the failure of loading the expansion pack”. I took me quite a while to figure that out. I even installed the .NET 3.0 Runtime Environment --- but I believe that is not required.).

Finally I was able to see the following “SimpleSampleCS”:



The overall architecture of “ISmartDocument”s is based on custom schemata to which actions can be attached. Quite simple but I gives custom schemata a meaning of the end.

The question I'm interested in:
* How is this work related to alien attributes and metadata in ODF? And
* what do we have to do to provide a competitive environment in OOo and ODF?

The prototype of text grid enhancement is available and the patch is under review now. Anybody who is interested in it could check out the patch from the cws cjksp1.

Today, I happen to find that there are quite many text grid issues open in Issuezilla. I will look at them one by one and try to fix them. :)

Some issues wrt. text grid in issuezilla:

i53425:more flexibility in the grid layout
i73011:Chinese layout incorrectly with text grid
i40768:CJK:Register-true not activated for frames when importing; Grid layout
i53464:Word table reformatted shorter on import due to Grid layout
i15251:"Snap to Grid" doesn't work correctly
i29543:WW8: paragraph with "snap to grid" invisible in table
i15424:baseline in grid
i55461:snap to grid doesn't work correctly inside frame
i54864:WW8: Different treatment of tables in page due to active CJK Grid
i72657:A single line on Word got converted to two lines on Writer due to Text Grid
i68204:option "Print grid" becomes inactive when reopening Page dialog
i35684:[Text Grid] Vertical alignment for different font sizes differ from MS Word
i49214:CJK: Line spacing interpretation is different between Word and Writer due to text grid
i24195:WW Import: Cell height is too big when opened in OOo 1.1.1a (due to CJK-Grid)
i56820:Ruby in vertical text in grid wrongly moves original text sideways

Please let me know if anybody has question about text grid layout. :)

I've had several requests for my RPM for freetype2 including sub-pixel rendering for openSUSE 10.2. So here are instructions on how to build your own, including my modified SPEC file. If you're in the USA it might be illegal to download my file, so this file is only for people who live in free countries. Or at least semi-free countries, like the UK.

1. Download freetype2 source rpm from http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/src/ - it might be a newer version by the time you come to download this.
2. Download freetype-2.3.3.tar.bz2 and freetype-doc-2.3.3.tar.bz2 from freetype.org.
3. Download freetype2.spec if your government will let you.
4. Install the source rpm: sudo rpm -ivh freetype2-2.3.1-7.src.rpm
5. Put the tar.bz2 files in /usr/src/packages/SOURCES
6. Put the spec file in /usr/src/packages/SPECS
7. Build the rpm: rpmbuild /usr/src/packages/SPECS/freetype2.spec
8. The built rpms will be in /usr/src/packages/RPMS/i586

Note that you will need to have any required libraries and tools installed in order to build this. It should just be the basic development tools I think.

Finally, I have sub-pixel antialiasing in openSUSE 10.2. For some reason, it was turned off in the 10.2 release because of something being broken. I haven't been able to find out what. But yesterday I got tired of waiting for it to be fixed, so I downloaded the alpha freetype package from 10.3, only to find that it also has sub-pixel antialiasing turned off. No problem - I just installed the source package, replaced the tar files with version 2.3.3 ones, edited the spec file to enable sub-pixel rendering, disabled the freetype2-bitmap-foundry patch (because it wouldn't compile with it in there), rebuilt the rpm and installed it. Hey presto - sub-pixel rendering!

Last time I blogged about getting fonts to look better in 10.1, I had a load of comments telling me I should just turn of antialiasing because text looks better without it. Well, I like antialiasing, and especially sub-pixel antialiasing. On my 1900x1200 display it looks great. So there!

Had to say good-bye to mouse. He'll travel to Australia. Again. Tried to smuggle myself into the luggage but I was too big. Hope mouse will at least send me a postcard. He is such a lucky mouse. My friend even bought chocolate for him.

There has been issues reported by GW users that Evolution hangs/suspends for a while when composing mails. We weren't able to reproduce the issue and respective gdb traces didn't give enough information. Lately, I started hibernating my laptop and when I resume from hibernation, I noticed that EDS started taking 100% CPU and when gdb is attached to the process... voila!!!.. EDS was running with 264 threads and most of it are waiting to update GW addressbook and rest are waiting to update GW calendars.

A little further investigation revealed that it was because of the combination of g_timeout_add()+hibernation. GLib stores the last processed time for g_timeout_add and when hibernated, the memory image is stored and restored, when resumed from hibernation. When restored, callbacks registered with g_timeout_add() gets called - as the difference in time during hibernation and resume satisfies the g_timeout_add() timeout value and that too in multiples of 100. Harinath (of Mono fame) helped me understand the GLib part and the fixes have gone in for GW and webcal provider.

The following user scenarios of text grid are under investigation.

1. When user creates a text document, the default paper mode of text grid is read from user preference settings. User can switch the default paper mode of text grid in text document options tab page. (Tools --> Options --> Text Document --> General) by clicking the check box "Use squared paper mode for text grid".

2. When import a Ms Word 97/2000 file (.doc), the default paper mode is treated as "standard paper mode".

3. When import a text document of the previous version of OO.org (.odt, .sxw), the default paper mode is treated as "squared paper mode"

4. When user is editing a text document with text grid.
if he switchs the paper mode from "squared" to "standard", the following behavior is used:
* line height = Max base text size + Max ruby text size
* lines per page = type area height / line height
* Max ruby text size = 0

if he switch the paper mode from "standard" to "squared", the following behavior is used:
* line height = type area height / lines per page
* Max base text size = line height * 2 / 3
* Max ruby text size = line height / 3

As mensioned before, there are two kinds of text grid layout which are used in CJK users. One is "squared page mode", the other is "standard (rectangle) page mode".

Per the text grid prososal approved by ODF TC, the style:layout-grid-standard-mode property is added to specified which kind of text grid is used for the document.

In order to ensure that either “sqaured mode” or “standard mode “is used for the whole document, the style:layout-grid-standard-mode property can only be set for the default style of the “page-layout”. When the style:layout-grid-standard-mode attribute appears inside a style:page-layout definition, then the attribute MUST be ignored.

Global setting entry for selection of which kind of text grid layout is used for the whole document. (Tools-->Options-->OpenOffice.Org Writer-->General)


When the "Use squared page mode for text grid" is checked, the original tab page of text grid is used.


When the "Use squared page mode for text grid" is unchecked, the following tab page of text grid is used.