Archive for November 2005

Finally, I really made up my mind. In the end I can only use mup despite its limitations. Typesetting music in lilypond is like writing program — although lilypond is more flexible, it takes a tremendous effort even to typeset a single passage, not to mention multi-stave music. I’ll try to summarize the pros and cons for using lilypond and mup on orchestral work:

1. In lilypond, the accidental of each note is automatically handled; what you type is what it would sound like in c major, and lilypond would automatically add/subtract sharp or flat sign for each note according to current major/minor. In contrast, mup purely takes care of the visual appearance; you would typeset according to how it appears in score. If there is a sharp on the sheet, you add a sharp. Lilypond has an advantage here, as it allows changing accidental style readily (20^th century music, cautionary accidental etc).
2. Mup input is entered in a per-bar basis; this is the same for multi-stave work. Enter all the staves and voices for one bar, group them together, then enter the 2^nd bar. In contrast, lilypond handles it in a per-voice way — yes, even polyphonic passage in single staff is entered voice by voice. No, I didn’t mean you are forced to do so; what I mean is you would find it even more clumsy and time wasting to enter it bar by bar in lilypond.
   I find mup’s treatment much more convenient, as it is way more easy to debug non-fatal errors when something goes wrong. With lilypond, especially when using relative octave mode, changing one note may affect the whole score’s layout and note positioning (all notes may increase or decrease 1 whole octave, sometimes even 2). That’s very hard to trace. But lilypond’s treatmeat isn’t always that bad — treating the whole passage of a voice as a unit allows cross-bar beaming easily, and that’s why I want to try out lilypond in the first place; just that I realized lilypond style isn’t my cup of tea.
3. As a result of per-voice handling, lilypond allows a per-stave setting for virtually every attribute, like time signature, key signature and so on. This is a big plus. As of Mup 5.1 there is still no such thing as per-stave time signature yet, one has to do some hack to get it done, and it’s really painful to get it work in multi-stave scores (think about changing time signature for every stave but one).
4. Vertical collision detection between staves — basically lilypond has no such thing, while mup handles it almost perfectly. Bad for me.
5. Another sore point — dynamics (e.g. sfz) between staves. Again, mup handles it readily. Well, there is a ‘hack’ documented in lilypond user guide that does this. But guess what? Dynamics is treated as an empty stave containing only spaces and dynamics themselves, in between 2 staves. Weird huh? This shows the flexibility of lilypond, as well as the sutpidity. Besides it is really hard to merge the hack into the score, it’s complex. For orchestral work this is Pain In The Ass ™.

So based on the last 2 points I decided I can’t use lilypond at all, since it may take me many years (literally) to typeset a whole concerto. It takes me 3 days to figure out how to adjust the vertical position of a dynamics mark. I’m not really willing to work like a programmer in order to typeset something.

This is not to say lilypond is bad though. Its flexibility and the scheme support allows it to do quite a lot of unusual layout, which is not possible with mup (unless you know PostScript internals). However, it really was using too much time for me to learn, and time is what I am lacking of.

Well, this sudoku puzzle isn’t really that special; just that it requires 2 ways of analysis to get one single digit right (highlighted in green circle). Most computer generated puzzles should be relatively straight forward, and just require a ‘linear’ way of analysis; but for this particlar ‘5′ it isn’t.

When analysed vertically, it is obvious the possibility 5’s can only be located on top right corner (5 in brown color) and bottom right corner (5 in green circle) of the 3×3 grid. When analysed horizontally, I marked the possibilities of 5’s in red square. The upper 2 pairs of red square can only be either 5 or 7, thus in the 3×3 grid the only choices of 5’s are located at bottom row. Bingo!

Of course there are lots of interesting sudoku puzzles as well, such as those providing only 17 digits yet still solvable (like this one); I have tried some, and surprisingly they are not particularly hard. To quote wikipedia:

Perhaps surprisingly, the number of givens has little or no bearing on a puzzle’s difficulty. A puzzle with a minimum number of givens may be very easy to solve, and a puzzle with more than the average number of givens can still be extremely difficult to solve.

Just reinstalled Ubuntu, and I almost forgot to take a screenshot before tuning my own Ubuntu desktop. No wonder why even my workmates are urging me to do something about Chinese support in Ubuntu. It’s quite ugly by default, and needs some significant amount of time to adjust.

1. The font looks like Japanese one, sometimes intermixed with a few glyphs from Chinese font; that’s somewhat “normal” given that Japanese font has a higher priority in fontconfig. Probably fontconfig needs a per-locale font ordering?
2. The glyphs look irregular; will be better after disabling automatic hinting.
3. The default font is way too small for CJK environment, so that some glyphs with more strokes looks just like a dark square. Why must it be so for EVERY Linux distro?

These are the issues immediately popping up in my head after first impression; but certainly there are lots more (e.g. gnome-games not playable, many of the applets crashing under dual-head Xorg config). I’ll need some time filing bugs and get the work done…

Why is it so difficult to have a partition table usable under both Linux and Windows? While Windows reports correct CHS values, it is so fragile when handling partition tables with errors. Partition Magic can be useful sometimes, but for me it usually just refuse to start. Damn it.

It is not much better in Linux. It is always assumed there are 255 heads, while the correct number for my harddisk is 240. Besides fdisk simply won’t allow me to grow extended partition. Finally it is cfdisk that saved my life, otherwise I may need to waste many hours/days for merely moving partitions around without achieving anything useful.

For such administrative issues, I’m just a simple user that wish to have things that Just Work™.

Finally, the last package is uploaded before quitting Mandriva contribution:


Name: libtool Distribution: Mandriva Linux
Version: 1.5.20 Vendor: Mandriva
Release: 4mdk Build date: Sat Nov 19 03:42:52 2005
......
Fri Nov 18 2005 Abel Cheung 1.5.20-4mdk
- Revert previous crappy revert that make people's life difficult


While it was Gwenole Beauchesne’s ongoing insults that triggered my determination to leave (sometimes it’s due to my fault, sometimes just he want to insult others), the real reason was actually there long time ago. It looks like some of the core employees in Mandriva have their private gardens — they can do whatever they want, without considering users and contributors’ feeling. Under such environment, contributors can never do much even if they want to help. But probably THIS is the real intention from Mandriva, since those people in inner circle should have already reacted if they think this is a problem. Who knows?

Besides, under such environment, it is really becoming uncomfortable to do any contribution, since this is like dancing on sword edge — a wrong step and you will see reaction like “Damn you!”, “Don’t touch my private property!” etc.

I’m still not sure yet where to contribute, but most likely it will be Ubuntu. This recent startup has gained lots of momentum recently, especially when IBM certifies it with DB2. Besides, since Jeff Waugh has sent mail to me, so hopefully he recognizes me and lift the barrier of entrance a little bit…

Finally, with Funda Wang’s help, I’m uploading unifont to Mandriva repository — that means it will be the default font for Chinese in Mandriva 2007 release. And it looks like the progress is good on Debian and RedHat’s side too: Debian is unquestionable, as Arne is debian user (developer too? I don’t know). Leon Ho is active for RedHat’s I18N issues, so he will surely follow up too. It won’t be long for other distros to pick up.

But I found it absurd when I knew those CLE people are still pushing Firefly’s bitmap fonts. While I know Firefly has put a lot of effort on it (and deserves praise), I don’t think fonts not usable globally by all Chinese can be the solution, right now. This used to be so, when there exists no unified font for Chinese, and for various languages as well (Code2001 is ahead in this area, but doesn’t support CJK, and 2002 doesn’t come close); but right now why do they still push solutions that’s only usable by themselves? Even Wen Quan Yi recognized the need, and included Firefly’s bitmap fonts with Hong Kong freefonts as well.

I learned something, which is a rule rather than exception — discussion with perfectionist often leads to nowhere. Of course, no discussion at all is also bad, and I hate those kind of person really much, like some certain people killing my job in Mandrake build cluster repeatedly without telling me, and simply yell when I approach him. But the result of discussing with people with only perfection in mind (in particular, several such persons) is only: discussion. No result, no conclusion, no action, no whatsoever. So I will upload the fonts first, and let people to sort out license in the future — the only possible outcome for unifont can only be APL or GPL or duel license, there should not be any other choice. The license for these fonts has already generated enough discussion, and as usual, nobody has a conclusion for anything. I don’t want to waste my time anymore.

Cue sheets (those small text files with .cue extension) was not very popular under Linux (and all Unices), but it was popular among Windows users. Yes, flac has cuesheet support (with the cuesheet embedded inside flac metadata block), and mplayer has it too (though very buggy) — but that’s it. All other tools are just cue sheet manipulation tools, not media players supporting cue sheet natively.

To add more trouble to this mess, cue sheet syntax has never been documented well enough. So far the best (and authorative) reference is appendix A from cdrwin’s user guide. (Too bad that Golden Hawk doesn’t allow people to download its document anymore.) However this reference is not released openly. Various other information about cuesheet syntax scattered around the net, including this link and this one. I’m not quite sure why wikipedia made no attempt to document it. Probably so-called IP again? I don’t think this can be considered as private info, since so many media players and CD remastering programs are implementing cuesheet support (especially Windoze ones), and apparently Golden Hawk has not asked anybody for license fee for supporting cuesheet.

Cue sheet spec has some problems:

• Since it is originated from Windows programs, no effort is spent on how to manipulate files under other platforms (Unix, Mac etc), nor does it discuss issues on other platforms.
• It just say cue sheets are text files. But in which text encoding? I have personally seen cue sheets in GB2312 (simplified Chinese) encoding, which is rendered as garbled text on my machine. Yet another “English is the only language in the world” bastard. Why can’t people spend some time to think about how their products are used on other places in the world?
• Some of the cuesheet commands are not as well documented as they should be, e.g. CDTEXTFILE and FILE. Where should they occur? For how many times?

But regardless of the problems, cuesheet is still a very popular way of specifying CD metadata; probably it’s not popular among Linux users simply because the origin is from Windows.