♩ ScoreRender ♫

With the upcoming version (0.2), it should be possible to set image width so that the image may not overflow blog content area width, thus content layout would not be ‘broken’. However, since TeX does not provide any control for arbitrary page width, any TeX-using music rendering applications (the most prominent one being PMX, M-Tx and MusixTex) inherits such problem, and images rendered by them can’t perform any control on image width. So I’m temporarily postponing the support until 0.3.x.

Right now I can think of several solutions, of which none is perfect:

1. Resize image: the simplest and most obvious method. But won’t work if people change theme frequently — after each theme change images have to be regenerated or images might overflow again. Not to mention tall images may not be very visible again after resizing.
2. Clipped to fit width: again, what happens after each theme change?
3. Installing extra TeX package: I’m told that Vmargin TeX package allows arbitrary page size. I’m also told that package is exotic and not included in most TeX systems by default; but it looks like Vmargin is more widespread than I’ve thought. At least on Linux — Vmargin belongs to default LaTeX package for RPM-based distributions, and belongs to some LaTeX extra package for Debian-based ones. I’ll give it some more thinking later.
4. Use CSS overflow property: looks like the best solution so far, but still has its own problem, namely old browser compatibility. Though I wouldn’t care too much about browsers without proper CSS support…

Please leave message here if anybody has good solution!

Neat, isn’t it? This example is taken from the one contained in Debian package, albeit the package itself is terribly outdated and unmaintained until Debian Etch comes. Even though the example was supposed to be usable during Lilypond 2.2.x days only (!), with some changes (specifically, filtered with convert-ly to remove obsolete constructs), it runs happily with newest Lilypond.

But — this absolutely isn’t for the faint of heart.

• It took 35+ minute to render! Yes, 35+ minute 100% CPU time on Celeron 2.4GHz. Very likely due to embedding chinese font glyph outline into postscript file.
• One has to tweak fontconfig configuration file under Linux. Fontconfig has been notoriously bad at choosing CJK fonts. Default config prefers Japanese fonts, and imagine what it looks like when a mixture of Japanese fonts and Chinese fonts are used in lyrics.
• Installing Chinese fonts — actually this is the easy part. The score fragment in this post is rendered with Kai face (楷書) from CJKUnifonts, which is readily available in all major Linux distributions if Chinese support is enabled. Rendering Japanese and Korean requires fonts for corresponding language, of course.

Since last night I start to consider writing more complete documentation inside the plugin itself. Of course it’s just API documentation, which is NOT a replacement of how to use the plugin. (Hey, I know, I know, this plugin has no public API, it is just for converting posts and comments, and not intended to be used for themes and templates)

The immediate solution found by googling is phpDocumentor. Not a very brilliant solution, but enough to get the job done, especially good because it parses PHP files quickly and is easy to learn. For example:

/**
 * Error constant used when content is known to be invalid or dangerous.
 *
 * Dangerous content means special constructs causing
 * inclusion of another file or command execution, etc.
 */
define('ERR_INVALID_INPUT', -1);

/**
 * Generate HTML content from error message or rendered image
 * @param string $input Music fragment to be rendered
 * @param object $render PHP object created for rendering relevant music fragment
 * @return string $html The HTML content
 */
function scorerender_process_content ($input, $render)
{

phpDocumentor has a quick start guide on how to install itself through Pear. After getting the doc done, the hardest part is over; generating document is relatively easy. Just a single command:

phpdoc -o HTML:frames:earthli -f *.php -t docs

And voila! Documents are readily available under docs/ directory for your browsing pleasure. Generally this step just takes a few seconds for small project with several small PHP files. What does it look like? See the pic on the right.

Here is just some old fragment used for demonstration purpose in my personal site; as usual, click on the image to view the source.

Guess I should try to write some tips about how to use mup. But mysteriously my subscription to mup-users mailing list was terminated long time ago and I’m unable to contact Mup people ever since.

Subject pretty much says it all
Apparently the change in 2.2 is not radical enough to make this plugin malfunction.

When compared with 0.1.2 release, this one only contains 2 lines of change, but still worths it, since these 2 lines add a bit of security using nonce — which is basically a random number designed to forbid direct submission of form without entering admin page. As usual, zip file and gzip’ed tarball are available.

In the older days I thought popup window was a good idea, but then… it’s not. IE trimmed html form GET values to 2000 characters, so submitting the whole music source in GET method will be disastrous. Thus today I replaced javascript popup window with another thing instead: <form target="…">, which submits via POST method instead and opens it in new browser window or new tab. Creating cross-browser webpage is really a headache…

But then, another obstacle comes. To make the show source window more convenient, a button is added to copy content to clipboard (idea taken from LatexRender). That’s trivial to do in IE, but a completely different story in Mozilla/Firefox.

Even though relevant script exists for Mozilla based browsers, it requires that javascript signing thing, which is so 1998′ish — I barely remembered fooling around javascript signing at that time and wondered what it was. Surprised to see such thing still existed today. Anyway, it is impractical to show dialog asking people to accept the authority of javascript, or even telling user to modify their own browser setting.

Though somebody came up with ingenious way to bypass security setting (using flash to access clipboard), I’m not sure if I really want such thing bundled with the plugin.

BTW, people are free to check if the show source function works in my previous post, by clicking on the image.

Received email from Chris Lamb a couple of days ago. In short, I got his nod to continue the life of FigureRender in current form.

I have branched ScoreRender for 0.1.x maintenance releases, and started 0.2 release hacking. Right now not much has been done — mainly dropping support for configurable tag markup (I suspect people don’t change it, if anybody is using this plugin at all ), and allows setting the upper limit of length per fragment.

Here are some of the things I want to achieve in 0.2 release:

1. Allows configurable image width limit
2. Lilypond chroot support (it really hurts when some Lilypond fragments don’t work because of security issue)
3. Allows setting limit of no. of fragment in comment
4. Supports more syntax, like MusiXTeX, Philip’s Music Writer and lilypond-book format
5. Add button in option page to clear image cache

One thing not quite sure is whether I should implement the feature of covering up error with blank or blanket images. This helps on security side (leaking less info), but blog authors will find it harder to trace error. Still not decided how this can be achieved while satisfying both flexibility and security.

ScoreRender 0.1.2 is out there. This maintenance release contains only very minor changes:

Add +repage option to ImageMagick convert, in order to make sure no white edge exists in images after trimming. Otherwise, some images will retain layer info and render at an offset from origin (0,0).