Bryan writes:
| Jack Campin says -
|
| >Existing software, or future software for that matter, is hardly going
| >to remove pages from the web, is it?
|
| No, but can't we try and stop it getting any worse? This is where I came in
| many months ago with an appeal to developers to exercise a bit of restraint.
| Innovate, but do so with care and consideration for the consequences.
|
| >We need some way of dealing with this, and validation isn't it.
|
| Why not?
Well, this would be useful, but it does have its limits. For
instance, look at a web page that my tune finder's search bot found a
few months back:
http://shiva.di.uminho.pt/~jj/musica/html/baratamoura-comAPrendaDoPadrinho.html
The gif image here was derived from an abc file, and with a bit of
poking around, it's not difficult to find it:
http://shiva.di.uminho.pt/~jj/musica/abc/baratamoura-comAPrendaDoPadrinho.abc
This /abc/ directory is, as you'd expect, full of abc files. None of
them has a T: line. Some files (including some of mine ;-) uses P:
for a sort of secondary title to get it at the left margin. My code
looks for this, and these files don't contain P: lines, either. There
are simply no titles to these tunes in the abc.
I've sent some email to the owner of this collection, José João Dias
de Almeida, and this isn't going to get fixed any time soon. Why not?
Well, look at the first page again. Note that there's a title in that
page, inside an <H2> tag. From an html viewpoint, this is the correct
way to do it. The site owner's reasoning is that, if he puts a T:
line in the abc file, it will then appear in the gif file, and the
web page will have two copies of the title. This is unaesthetic, of
course. So, rather than futz with the black magic that it would take
to trim it away from the gif files, he simple got rid of the titles
in the abc files.
The result is incorrect abc, but in his mind, this is irrelevant. His
web page looks like he wants it to look. Adding T: lines will make
his web page come out wrong (to his eyes). And the title IS there,
with a proper html tag, so web software and users can identify it.
Why should he listen to complaints?
This is one of the gotchas that we are facing. Jose knows pretty well
what he wants. He found abc tools that do a good job of providing
what he wants. He has violated the official abc syntax. So what? If
he follows the official syntax, he doesn't get what he wants. He
probably isn't going to use any syntax validator. In fact, it looks
like he is using abc2ps, and if so, he is probably getting some
warning messages, which he just ignores. He knows that he has some
incorrect abc. His attitude is "So what? It's my web site."
I'd say that what Jose has done a pretty good job with his web site.
His tunes aren't in my index, because the search bot can't figure out
his web site and can't get the titles for the abc tunes. But my tune
finder isn't any concern of his. He has set up a small site to share
music with a small crowd of traditional Portuguese musicians. It does
a good job of what he wants it to do. If he ever decides he would
like my tune finder to find his tunes, he may change things, but for
now, he has what to him are good reasons to use "incorrect" abc.
What I think would be a solution to this is: Whatever program he is
using (and I should verify that it's abc2ps) needs an option saying
to suppress the titles. Most users would think this is pointless. But
we have an example here where, if Jose had such an option, he would
likely use it, and could then add titles to the abc files. I don't
think he's trying to hide his tunes; he's just trying to get his web
pages to show them the way he wants. So I may add just such an option
to my jcabc2ps clone and offer it to him.
I could use such an option myself. Why? Well, one thing that current
abc tools aren't very good at is dealing with fragments of abc. Most
people don't want this, and probably haven't even thought of it. But
I've been working on some abc tutorial docs. For such text, it would
be really handy if I could use tiny fragments of abc and get tiny PS
or GIF or PNG files out that don't fill up the whole screen.
Thus, the current abc2ps, like most tools, insists that a single line
of music have a clef and time signature. This makes sense for a full
piece of music. It doesn't make sense if what you want is one or two
measures of music as an example in the middle of a block of text.
Sure, I can use some complex graphical tools to chop out the excess
junk. But this is very time consuming, and prone to errors. It would
be a lot nicer if I could just have a tiny file with:
M:none
L:1/8
K:C clef=none
| DG {c}BA |
I can then write a Makefile entry that feeds this to abc2ps, and then
feeds the output to my ps2gif script, and have my example. This
should produce just the one measure, with no clef, no time signature,
no title, nothing but the one measure. Note that an "ignore title"
option would be useful here. If abc2ps had this, I could add a title
like:
T: Example of ...
This title would then show up in indexes like mine, and people could
use my tune finder to find them. This would be useful.
I have in fact started working on this. My jcabc2ps clone now does
the M:none correctly. It almost does the clef=none, but it still
insists on leaving space for a clef at the start of the staff, and
this isn't acceptable for my uses. I'm not too close to understanding
the code that positions that first bar line.
If we want people to produce "correct" abc, it will help a lot if our
software does the Right Thing for cases like these. Otherwise, we
will continue to see people "abusing" parts of abc to get what they
need. Telling them that their abc is incorrect is not going to
persuade such users. Understanding their needs and incorporating them
into abc tools will make them a lot more cooperative.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
