I. Oppenheim wrote:
...
>
> I do not agree with this approach.
> A standard should document advisable behaviour, not all
> the possible errors that people make when writing ABC.
I'd say both yes and no to that.
The new standard should certainly do far more than just document common
ABC use.
On Thu, 3 Jul 2003, John Chambers wrote:
> All we need now is a non-abc2ps-clone program that is
> as liberal, and we can state in the standard that
> such lines can go anywhere
I do not agree with this approach.
A standard should document advisable behaviour, not all
the possible errors that peo
Buddha Buck writes:
|
| Maybe adopting the IETF policy that there has to be at least two
| independent interoperable implementations of something before it becomes
| "standard". Or something similar.
Good idea.
We might go over the multi-voice implementations with this
in mind. One that mi
Jeff Bigler wrote:
There's been a lot of traffic on this topic already. Two things I'd
like to emphasize:
I'd recommend that in general, we try not to add features to the
standard unless:
a) there is consensus (or at least an overwhelming majority opinion)
as to what the feature sh
Jeff Bigler writes:
|
| 2) We seem to be in danger of falling into the trap of "everything that
|any known ABC-related application does has to be included in the
|standard." This runs the risks of
|
|a) making the standard too difficult to interpret and/or implement,
| and
|
|
In message <[EMAIL PROTECTED]>, Jeff Bigler
<[EMAIL PROTECTED]> writes
>There's been a lot of traffic on this topic already. Two things I'd
>like to emphasize:
>
>1) I agree that the standards committee should have a chairman, but I
> think the committee needs to elect him/her.
>
>2) We seem to
There's been a lot of traffic on this topic already. Two things I'd
like to emphasize:
1) I agree that the standards committee should have a chairman, but I
think the committee needs to elect him/her.
2) We seem to be in danger of falling into the trap of "everything that
any known ABC-rel
From: "Bernard Hill" <[EMAIL PROTECTED]>
> For graphical score editor (wysiwyg) and soon to support abc you
can try
> Music Publisher (www.muspub.com) but if open source=free then No.
I have
> a living to make.
"open source" means that you publish the source code for free for
people to edit as t
In message <[EMAIL PROTECTED]>, Donald
White <[EMAIL PROTECTED]> writes
>I am using runabc.tcl (or runabc.exe) on both my PC and on Linux as a front end
>to abcm2ps and gsview, and it is extremely easy to use. To a novice user, once
>it is setup, you hit "display" and it generates a pdf file di
On Wed, 2 Jul 2003, [iso-8859-1] Forgeot Eric wrote:
> Does someone know if it's possible to "hack" a
> ghostscript version to have only the PDF export
That's possible. When compiling, you can select the
output devices you're interested in. But it won't make
ghostscript much smaller, because most
I am using runabc.tcl (or runabc.exe) on both my PC and on Linux as a front end to abcm2ps and gsview, and it is extremely easy to use. To a novice user, once it is setup, you hit "display" and it generates a pdf file directly and launches gsview32.exe (on Windows).
I think the biggest thing l
>At least partly because the prospect of setting it up, installing
>ghostscript to view graphics. etc. it just too daunting for them.
>What these users (probably the majority of PC users) want is
something
>that is easy to use and works on thier system
it's true I often recommended Abc to sever
From: "Gerry McCartney" <[EMAIL PROTECTED]>
> What I should like to know, therefore, is where exactly is the
debate going
> in terms of importance.
This is the important thing. :-)
I see four main desiderata as far as language goes (over and above
the 1.7.6 standard):
A way to include more th
Jon Freeman wrote:
>>I think you are taking a pretty narrow view here. Yes, abcm2ps is
excellent but it is pretty well useless to many people I know who may like
to use abc.What you see in the abcusers list tends to be the "geeks", the
ones that are
quite happy to run command line programs, are qu
From: "I. Oppenheim" <[EMAIL PROTECTED]>
> Applications that write ABC files, could indicate in
> the ABC version field which ABC modules they used, e.g.
> 2MG for "ABC version 2.0.0 with guitar module and
> microtonality module."
Yes something like that might be useful - even if those writing a
On Wed, 2 Jul 2003, David Webber wrote:
> An application would have to parse the file it anyway to find out
> what it uses. But all the application could do is put up a message
> saying "this abc file contains elements from abc module ... and so I
> can't read all (any?) of it".
Applications tha
From: "I. Oppenheim" <[EMAIL PROTECTED]>
> On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
>
> > I fundamentally disagree with this. I believe that
> > it is imperative that the standard and the software
> > that uses it should be isolated.
>
> I agree with you. I had already a bit of argument about
In message <[EMAIL PROTECTED]>, I. Oppenheim
<[EMAIL PROTECTED]> writes
ABC software should be able to implement a
minimal amount of ABC in a well defined way that is
still standard compliant. The software developer is
then able to clearly indicate which ABC modules are
supported and which not.
St
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
> I fundamentally disagree with this. I believe that
> it is imperative that the standard and the software
> that uses it should be isolated.
I agree with you. I had already a bit of argument about
this with Phil. The standard should define an abstract
Emerging from a long hibernation to say how glad I am to see that a great
deal of sense is being talked about the possibilities for a new standard;
especially by some of the newer members of this list.
I am not am abcm2ps user but, as far as I understand it, Jean-François is
doing brilliant wor
20 matches
Mail list logo
