♩ ScoreRender ♫

Looks like another half year has passed without any significant improvement on ScoreRender… actually not really. There is some work behind the scene, but not announcement yet.

1. A certain user has been facing problem with hosted web sites, so it looks like there IS need to make it work with web hosts — to be specific, ScoreRender needs to cope with the case when PHP functionas are disabled due to security reasons. It shouldn’t be hard. The hardest part is how it can work with older ImageMagick and other related software. I don’t see any solution yet.
2. IE6 PNG image transparency seems not as dead-end as I thought. With the image filter published by TwinHelix, it looks trivial to add the support for IE6. At least way better than the big fat warning with current releases.

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.