Atte writes: | Dafydd Monks wrote: | | > I was thinking of a GIF/MIDI parser really - andone that dose not need the | > backed of abc(m)2ps. | | Ok, I see. Would be very cool indeed.
Recently I got my ands on a BlackBerry 7280 (cool geek toy ;-), and of course I had to see if I could make it work with my Tune Finder. The browser worked OK. It can display images, so I started converting tunes to GIF and PNG. If they're too big, they get converted to the screen size (240x160 pixels). The result invariably was that some of the horizontal and vertical lines came out a fuzzy smudge. Most were quite unreadable. No problem, you might think; just tell the ps2gif and ps2png image converters to create a 240x160 image. Nope. The only converters that I've been able to find refuse to deal in pixels, as does PS. The best converter that I've found is the one that comes with ghostscript, and it has a "resulution" arg that is a number without unit. A simple test shows that it is definitely not a pixel count. Resolution is usually measured in pixels/unit-of-lenght, of course, so I calculated the nnumbers for the screen, using inches, mm and cm as the unit-of-length. All were wildly wrong. I eventually found, after hours of experimenting, that a horizontal resolution of 32 and a vertical resolution of 36 produces GIF and PNG images with solid vertical and horizontal lines. The image is a few pixels narrower than the screen, but close enough. The numbers 32 and 36 don't seem to be close to any nuumber that could be called "resolution" on this screen. Meanwhile, my wife got a Palm Tungsten, which comes with wifi and a real browser. I tried the Tune Finder on it, downloaded a GIF - and it came out about 2.5 times as wide as the screen. Working a tiny little scrollbar while trying to read a line of music isn't the most practical thing in the world. So I'll probably spend some more time writing code to detect that client and discovering the magic numbers that makes the image come out readable on that (320x320) screen. I'll guess that the numbers won't resemble any relating to the 320x320 size of the screen. Now, GIF and PNG are scan-line formats, and deal basically in pixels. What I'm tempted to try is digging into my abc2ps clone and adding some new output formats. Actually, unix systems come with this huge library that converts images to/from the "ppm" format, so that might be the best to use. Writing copies of the PS output routines that draw in a 2D array of pixels shouldn't be all that difficult; not much worse than what the PS routines are doing. Maybe the next time I'm unemployed I'll tackle this. Meanwhile, I wonder if there's any usable scheme to discover the screen size of a web client. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
