[abcusers] The ABC homepage

[Christian M. Cepel]

Noticed that the address changed from
http://www.gre.ac.uk/~c.walshaw/abc to
http://staffweb.cms.gre.ac.uk/~c.walshaw/abc
When did that happen?
Btw... If Chris ever wants webspace hosted at abcnotation.org or 
abcmusicnotation.org, he's welcome to it for free.  I'm trying to get 
abcmusic.org as well, but haven't had much luck as of yet.

--
 //Christian
Christian Marcus Cepel| And the wrens have returned &
[EMAIL PROTECTED] icq:12384980  | are nesting; In the hollow of
371 Crown Point, Columbia, MO | that oak where his heart once
65203-2202 573.999.2370   | had been; And he lifts up his
Computer Support Specialist, Sr.  | arms in a blessing; For being
University of Missouri - Columbia | born again.--Rich Mullins
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Jon Freeman]

From: "John Chambers" <[EMAIL PROTECTED]>

> In fact, I've seen ABC embedded in HTML by using  the  ...
> tags,  and  then putting  at the end of each line.  The  tag
> means to preserve whitespace (including CR  and  LF)  exactly,  while
> processing  tags  in the data.  The  tag means to generate a line
> separator.  So such text is explicitly double spaced.  The writer may
> not have understood this, but software on the receiving end can't yet
> read the sender's mind.

Must admit I could have abc in threads that does that, not that we get many
abc submissions to threads. I just work on the princple that every CR/LF
thingy from a text edit box means a new line and don't bother checking
incase  is used - a  is exchanged regardless of whether or not it
sits within a pre tag.

Cases where that would affect abc are rare though as mostly a supplied abc
gets put into the song database to go with a song and I regard what gets
posted to a thread in the main as a means of a) visual communication and b)
mostly as material to go with a song. Similarly, if a correction was needed
to the abc, the song db would reflect that but info put in a thread for use
would not get updated.

Jon

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] Patents (was this tune intentionally left blank)

[Stephen Kellett]

In message <[EMAIL PROTECTED]>, John Chambers 
<[EMAIL PROTECTED]> writes
other  fora:  Microsoft has received a US patent on some of their XML
encodings generated by Word. This may not matter much yet outside the
US,  though  Europe is probably going to enable similar laws shortly.
In the  US,  decoding  such  files  with  software  not  licensed  by
Microsoft  is  not  only  a  patent  infringement;  it is also a DMCA
violation.
That is really excellent news. Why?
1) If proof were needed that patenting is now defeating the object it 
was intended to serve, this is a very fine example.

2) If MS do start prosecuting based on this, its a good reason for even 
more people to move away from Microsoft Office software. I'd have 
thought the Linux camp would be overjoyed by such a stupid move as 
patenting a document interchange format. Jef Raskin must be wondering 
why he bothers with his user interface work when its all thrown away 
because you can't even share the document you wrote.

The ecommerce company I work for will not accept purchase orders in 
Microsoft format because Microsoft keep changing the document format and 
thus force an upgrade on you. We insist on PDF because Adobe provide a 
free reader (I've recently noticed MS now provide a free Word reader). 
No going back, we're sticking with Adobe.

I don't dislike Microsoft - the MSDN programme is superb, OSDN doesn't 
come close. I do dislike enforced upgrades of software, burning of 
customers. Microsoft Office policy fits this nicely, from what I've 
seen.

Taking the above patent idea a bit further: Patenting a data format, 
thats a bit like patenting DNA (pointless, we all own it) or patenting 
the alphabet. Patenting the use of such ideas is also pointless (reading 
is a public domain activity as is the mammalian response to various DNA 
sequences and enzymes, etc).

Sorry, end rant. I'm surprised I haven't seen the above patent mentioned 
on Slashdot, although I could've missed it.

Stephen
--
Stephen Kellett
Object Media Limitedhttp://www.objmedia.demon.co.uk
RSI Information:http://www.objmedia.demon.co.uk/rsi.html
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[John Chambers]

Jack Campin comments:
|
| Where you *are* going to get a problem is if the input file uses a
| mixture of linebreak characters and HTML tags to indicate ABC line
| ends.  Could anybody really be that stupid?... er, well...

In fact, I've seen ABC embedded in HTML by using  the  ...
tags,  and  then putting  at the end of each line.  The  tag
means to preserve whitespace (including CR  and  LF)  exactly,  while
processing  tags  in the data.  The  tag means to generate a line
separator.  So such text is explicitly double spaced.  The writer may
not have understood this, but software on the receiving end can't yet
read the sender's mind.

| > An emerging requirement for HTML is that ALL tags be paired win
| > an  .
|
| Really?  I thought  was deprecated?

Heh.  This is a case of the  old  quip  that  the  nice  thing  about
standards  is  that we have so many to choose from.  You'll find some
very confusing comments on this in the W3C HTML standards,  depending
on  just which you happen to read.  And some commercial vendors (most
notably Microsoft, but they're not the only culprits)  show  a  great
deal  of contempt for the official standards.  In any case, if you're
writing a search program, you have to deal with what's out there, not
what the standards may say.

A contrary pressure is coming from the growing tendency to  use  XML,
and  that  standard  makes an unambiguous statement that closing tags
are always required. There is the shorthand that combines them, as in
, but that doesn't really effect much.

The new Fiddler's Companion is an interesting case.  If you  look  at
http://www.ibiblio.org/fiddlers/AA_ABEL.htm,  for example, you'll not
only see some HTML loaded down with style information (some of  which
is off in other files), but you'll also see several  ...  
sections. So there are at least three different markup schemes in use
here. The header says it was generated by Microsoft Word 10, so lotsa
luck finding any  software  except  Microsoft's  that  can  correctly
decode  it.   The  fact  that different browsers display the ABC with
different spacing is not at all surprising.

Actually, this reminds me of a discussion  that  I've  seen  in  some
other  fora:  Microsoft has received a US patent on some of their XML
encodings generated by Word. This may not matter much yet outside the
US,  though  Europe is probably going to enable similar laws shortly.
In the  US,  decoding  such  files  with  software  not  licensed  by
Microsoft  is  not  only  a  patent  infringement;  it is also a DMCA
violation.  As such, it is a federal felony, and can get you a 5-year
jail  sentence and a $500,000 fine.  Since the above file was encoded
with authorized software, Andrew is probably safe  from  prosecution.
But  anyone  who  reads  it inside the US with non-Microsoft software
could well be committing a felony.  It's only been a few months since
MS  got  the patent, and they haven't yet prosecuted anyone.  But you
might wonder why they applied for the patent if they don't intend  to
enforce it.

There has been a suggestion that non-MS  software  add  a  check  for
MS-Word docs.  What they'd probably do is pop up a little window with
a warning, and ask you if you  want  to  accept  the  legal  risk  of
reading the contents. If you click Yes, that would probably exonerate
the authors of the software, since it would then be your decision  to
violate the MS patent.

I'm considering adding a check for such headers to my search bot, and
simply abort the processing of any such file, to keep myself out of a
federal prison.

Isn't "Intellectual Property" a fun topic?

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Jon Freeman]

From: "Jeff Szuhay" <[EMAIL PROTECTED]>
> >  1. remove all CR and LF characters.
> > 2 remove all 
> > 3 change all  to CR/LF
> > 4 change all  to CR/LF
>
> While I recognize this is a "first stab" heuristic, it fails because of
> too many assumptions.
> For line endings:
>Windows/DOS use CR/LF
>Unix/Linux/Mac OS X use  LF
>Mac classic uses CR

> Also HTML should be _parsed_ and not just willy-nilly remove  info.

I think you are reading more into this than was inteded. As far as I
uderstood the problem, we were looking at a program that is trying to
recognise and extract abc from web pages. CR and LF would have to be removed
separately for the reasons you gave but I don't see it would have mattered
which choice of line ending was used as long as the program recognised it (I
think abc programs are supposed to cater for all 3 BTW). As long as the abc
portions turned out OK with consistant endings, I don't really see the need
for full parsing of the HTML or whether the HTML became mangled as being an
issuse - no-one would be viewing it.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Jack Campin]

>> 1 remove all CR and LF characters.
>> 2 remove all 
>> 3 change all  to CR/LF
>> 4 change all  to CR/LF
>
> While I recognize this is a "first stab" heuristic, it fails because
> of too many assumptions.
> For line endings:
>   Windows/DOS use CR/LF
>   Unix/Linux/Mac OS X use  LF
>   Mac classic uses CR

Doesn't matter.  The idea is to generate a valid ABC file with the text
line breaks marked by *some* consistent choice of those.  Translating
for some client elsewhere is a separate problem - and one solved by the
designers of the FTP protocol about 30 years ago.  I wonder if there is
a site somewhere that represents ABC tune lines internally by 80-column
card images in EBCDIC? - if so there's no reason any user outside should
ever know or have it cause a problem.

Where you *are* going to get a problem is if the input file uses a
mixture of linebreak characters and HTML tags to indicate ABC line
ends.  Could anybody really be that stupid?... er, well...


> An emerging requirement for HTML is that ALL tags be paired win
> an  .

Really?  I thought  was deprecated?

-
Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760
 * food intolerance data & recipes,
Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro".
--> off-list mail to "j-c" rather than "abc" at this site, please <--


To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Jeff Szuhay]

 1. remove all CR and LF characters.
2 remove all 
3 change all  to CR/LF
4 change all  to CR/LF
While I recognize this is a "first stab" heuristic, it fails because of 
too many assumptions.
For line endings:
  Windows/DOS use CR/LF
  Unix/Linux/Mac OS X use  LF
  Mac classic uses CR

What is worse, many email servers "munge" line endings as they 
store/forward messages.

Also HTML should be _parsed_ and not just willy-nilly remove  info. 
An emerging
requirement for HTML is that ALL tags be paired win an  .
Parsing is still required if the HTML is malformed.

--
   You take your life in your own hands, and what happens?
   A terrible thing: no one to blame.
-- Erica Jong, writer (1942- )
--
   You take your life in your own hands, and what happens?
   A terrible thing: no one to blame.
-- Erica Jong, writer (1942- )
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[John Chambers]

| From: "Jon Freeman" <[EMAIL PROTECTED]>
| > I've just had another thought. Every tune starts X: A further replace of
| X:
| > for CR/LF X: might do the trick as I don't suppose you care how many blank
| > lines end up between tunes.
| >
| > Still, whatever you did, I'm sure you are right that there will be cases
| > that fail and a simple approach like this would never deal with something
| > like the http://www.ibiblio.org/fiddlers/AA_ABEL.htm example you gave.
|
| And yet another thought. I can't claim to understand it but I gather you
| work with Perl. How about something like this
| http://www.perldoc.com/perl5.6/lib/HTML/Parser.html?

Yeah; that's one of several HTML parsers that I've  looked  at.   The
problem  with all of them is that after they do a parse, you get back
an "object" that is the parsed version of the HTML.  Getting the data
out  of  it  is  MUCH more difficult than just attacking the original
text.  It's a fully tree-structured version of the document, and  the
data  you're looking for will be at a different place in the tree for
every document.  You can't just look for some giveaway char  strings;
your code has to understand the structure of the document. And no two
are ever the same.

I've played around with a number of these parsers.  I've always given
up,  and  written  my  own  semi-parser in less time than I'd already
wasted trying to understand the parser's output.  After all, if  what
you're  after  is  just the plain text that's hidden in the HTML, the
problem isn't all that difficult.  Most tags you just  discard.   You
look for a few that are line terminators and replace them with one or
more newlines.  You reduce strings of white space to a single  space.
The result is usually readable.

The main problem with ABC that has been HTMLized is that the newlines
often come out wrong.  You get runtogether lines, or the text ends up
double spaced. Sometimes both.  (There's one goofy site where you get
the  X:  and  T: lines single spaced, and the rest of the tune double
spaced.  ;-)

And this brings us back to the original question of what you do about
ABC  that  is double spaced.  The best I've found so far is to send a
note to the site's owner describing the problem, and if they fix  it,
fine.   If  not, then their tunes will require human editing when you
want to feed them to any software.

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] BarFly version 1.55 available

[Phil Taylor]

I have just uploaded a new version of BarFly.
Version 1.55 features:
* A new utility command to change the default note length in a single 
tune, or a whole file of tunes.
* Progress display for utilities which operate on whole files.
* Transpose routine has been re-written (no longer makes enharmonic 
errors when transposing tunes with accidentals).
* Options set in the Line Ends sub-menu are now saved in the %%Bfly 
line when you record options in a tune.
* The Line Ends sub-menu has been moved to the View menu where it 
should always have been.
* Many bug fixes (please see the "New in this Version" file for 
details).

Get it here:

Phil Taylor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Jon Freeman]

From: "Jon Freeman" <[EMAIL PROTECTED]>

> I've just had another thought. Every tune starts X: A further replace of
X:
> for CR/LF X: might do the trick as I don't suppose you care how many blank
> lines end up between tunes.
>
> Still, whatever you did, I'm sure you are right that there will be cases
> that fail and a simple approach like this would never deal with something
> like the http://www.ibiblio.org/fiddlers/AA_ABEL.htm example you gave.

And yet another thought. I can't claim to understand it but I gather you
work with Perl. How about something like this
http://www.perldoc.com/perl5.6/lib/HTML/Parser.html?

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

Re: [abcusers] this tune intentionally left blank

[Jon Freeman]

From: "John Chambers" <[EMAIL PROTECTED]>

> | 1. remove all CR and LF characters.
> | 2 remove all 
> | 3 change all  to CR/LF
> | 4 change all  to CR/LF
> |
> | I've probably missed something but it's a thought...
>
> That would work for some files, and fail for others. The main problem
> is  that  a  lot of ABC-in-HTML tunes use  to terminate lines and
>  to terminate the tune.

I've just had another thought. Every tune starts X: A further replace of X:
for CR/LF X: might do the trick as I don't suppose you care how many blank
lines end up between tunes.

Still, whatever you did, I'm sure you are right that there will be cases
that fail and a simple approach like this would never deal with something
like the http://www.ibiblio.org/fiddlers/AA_ABEL.htm example you gave.

Jon

To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html

[abcusers] Re: BUS. OPP

[I. Oppenheim]

On Thu, 3 Jun 2004, Wilson Li, Marketing Dept. (Skygain) wrote:

> SKY GAIN has been approved by the ISO 9002
> certification.

I guess this is the first ISO 9002 certified SPAM
mailing I have ever received...

I thought I honourable mail list admin would do
something against these kind of messages...


 Groeten,
 Irwin Oppenheim
 ~~~*

 ABC Standard: http://abc.sourceforge.net/standard/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html