Karl Dallas wrote: > > No I'm a Human Shield volunteer. God bless you and keep you.
Karl Dallas wrote: > > So if I understand what you're saying about option 1: I display the abc > code (of a file called tune.abc) as text but if the user clicks on it, > instead of hearing proper abc, what they actually hear is tune.mid. > Seems a bit like cheating, but I suppose it'd work (and MIDI's not all > that bloated, compared with WAV or even MP3 or WMA). > Really it's not cheating. abc is neither a playing nor a display encoding system, but a descriptive encoding system. It so happens that nowadays computers have systems available designed to specifically encode information meant to be played (MIDI, Wave a.s.o.) or viewed/printed (PostScript, TeX) while abc, originally meant to communicate melodic information via ASCII-only-reliable media, has been extended so as to generate some kind of output or other (right now, I am planning yet another byproduct I need). > Chris commented: [skip lots] > 3. Send the ABC to the client and have it converted there. This only > works if the client has conversion software installed and has their > browser configured correctly, which is only feasible for a small > crowd who can coordinate their software. It can't be made to work for > a general public site. > [skip] > I've worked on a few projects that use approach 3. But there are some > major problems with this. One is that no sensible user will permit > downloaded code from a web site to run automatically on their > machine. This is how you get things like the email viruses that are > the plague of the Microsoft portion of the Net. [skip lots] I am selective about plugins myself. I get especially irritated with some promissing ones that simply cease to read code they usually did if you don't upgrade to whatever NEW!!! version they release every six or four months (each one generally 50% bigger in HD space requirements). However, some users might like a seamless integration of the rendering application with the browser and that means a plugin if the browser doesn't have built-in support (I think they'll hardly ever have for abc) or if the other options (server-side execution, pluriformat storage) don't apply. Netscape has a section on NS plugin writing at http://developer.netscape.com/docs/manuals/communicator/plugin/index.htm Those plugins might work with other browsers (Opera [http://opera.com], for instance, according to their documentation). Anyway, I think such a plugin would be of limited usability, as abc is a very loose standard (remember, it was conceived for human consumption with processed output as a byproduct) and a lot of the files available on the net use encoding features that do the task but must rely on specific software for that (and some may use custom features allowed by the standard but hard to be predicted by programmers; I'm in need of some to encode Gregorian Chant, for instance, and I think I'll have to add more variety to the already existent for that). This situation might be improved with the evolution of the abc standard itself and of initiatives such as The ABC Project [http://sourceforge.net/projects/abc] [http://abc.sourceforge.net/]. Once feasible, a plugin might be a solution, regardless of Chris's remarks, as far as the abc community is concerned (i.e., inside the abc world at least, the developers are known and trusted), but for the common surfer they would always apply, so that the option to download the source or a trusted format should still be provided. Paulo Eleut�rio Tib�rcio To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
