♩ ScoreRender ♫

After several nights of hair pulling, Windows support is there, as well as support for yet another notation: Philip’s Music Writer.

Let me talk about Windows support first. It took me way too much time to finish it than I anticipated. There are a couple of scaring problems for using PHP on Windows.

Command execution on Windows

Under PHP documentation of system() function, people have been talking about PHP incapable of executing any command line with more than 2 double quotes, since PHP 4.3.x. So the following command line:

"C:\Program Files\ImageMagick\convert.exe" "C:\Temp Folder\1.gif" C:\1.png

Produces an instant failure (because there are 4 double quotes). And adding insult to injury: it’s not limited to system(), any other program execution functions like exec(), popen() are affected as well. Now the newest stable version is 5.2.6, guess what? Nothing changed. And people simply invented schemes to circumvent the bug, the most obvious one being using batch file, and that’s what I end up doing as well.

tempnam() stupidity on Windows

So this is an undocumented feature: tempnam() on Windows only uses 3 letter prefix and a sequentially increasing counter as suffix! Now compare with the Unix counterpart — people have been complaining how this temp file creation is a security problem on Unix, but it’s suddenly not a security problem anymore on Windows! Fantastic!

Other people have been bragging programmers not to invent their own schemes, and use native functions instead. But no way, I won’t listen to such “recommendations”!

For Philip’s Music Writer support, it is also not as straight forward as it should be, the main problem being on image conversion. No matter how I indicated sheet size in PMW source, ImageMagick invariably insists image size is 612×792 (which translates to 8.5" × 11" under 72 DPI)! And the final resulting PNG file is a 1×1 pixel dot.

Probably the problem is on PMW’s side. Normally within PostScript preamble part there is at least a declaration of %%BoundingBox, specifying its size (some even go as far as specifying %%DocumentPaperSizes and %%HiResBoundingBox); yet nothing like that exists in PostScripts produced by PMW. Anyway, that problem is temporarily fixed by forcing paper size using ImageMagick -page option.

ScoreRender have been put aside for some time, but right now I think it’s time for momentum again. The code still needs some scrutiny, but mostly works, as this site has been using development code for more than a year and there are no obvious breakage (yet).

The most problematic part is interaction of ImageMagick and various PostScript files generated by the programs. They constantly change, that’s the reason development is more difficult.

• Only recently did I discover ImageMagick no more creates alpha channel with -channel alpha or -channel rgba options; it must be explictly created with -alpha activate. Yet this change is only added to ImageMagick 1 year ago. What about compatibility with older web servers? Probably I need to sacrifice something this time. No wonder some web apps supports GraphicsMagick too, though IMO that’s more like a failure than success.
• And abcm2ps changed too. Old testing score fragments no more work on development version of abcm2ps. Urgh.
• I decided I was fed up with PHP 4.x. Specifically it’s about the incompatibility between PHP 4.x and 5.x, it is no more beneficial to support classes used in 4.x. Thus next version will be PHP 5 only. During the old days PHP 4 end of life still haven’t been declared, but right now it makes more sense. Not to mention I don’t have any machine with PHP 4 now, so testing will be difficult.

That’s about it. Hopefully there will be a new release in these few days, when typhoon is storming here.

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!

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.

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

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.

OK, this rule is always true: one can only discover bugs after letting the cat out of the bag. I immediately discover 2 problems after 0.1 release (but never before that):

1. With transparency turned on (it is on by default), lilypond fragments will be rendered in a wrong way — the notes become transparent.
2. This plugin conflicts with the “WordPress should correct invalidly nested XHTML automatically” option under Options → Writing.

While the first one can be easily fixed, I can’t see how the second problem can be properly addressed except turning off the corresponding option. Despite removing most filtering hook in plugin, balanceTags() is STILL called within get_the_content() and can’t be dropped with any remove_filter() call.

So for now please turn off this option if you choose to enable the plugin. A new release will be done soon to address the above 2 problems.