> Neil Jennings writes:
> |
> | The abc 2.0 draft has the following
> |
> | %%abc-charset iso-8859-1 (or other iso code)
>
> Well, yes, but that doesn't seem to have a well-defined scope. Does
> it apply to the whole file? If I have a text that's mixed Russian and
> Yiddish (not a hypothetic cas
Neil Jennings writes:
|
| The abc 2.0 draft has the following
|
| %%abc-charset iso-8859-1 (or other iso code)
Well, yes, but that doesn't seem to have a well-defined scope. Does
it apply to the whole file? If I have a text that's mixed Russian and
Yiddish (not a hypothetic case), how do I indi
The abc 2.0 draft has the following
%%abc-charset iso-8859-1 (or
other iso code)
Neil
At 04:25 PM 4/29/04, you wrote:
Jack Campin wrote:
Would
not a charset specifier be a good addition? (if there is already
such, I shall be most embarrassed... as I am pretty much every
day).
A rule suc
Jack Campin writes:
|
| One problem: what if you want to mix character sets in a tune? -
| e.g. to have a Chinese song documented in English? (T: and w:
| fields in Chinese, N: and D: fields in English).
What I'd more likely want to do is: three T: fields (Chinese
characters, pinyin, an
Phil Taylor wrote:
> OK, I understand that. What was bothering me though, is how Steven B's
> parser is going to deal with regular ascii strings which include a
> space followed by a bracket. It's no problem when everything is
> unicode, or everything is ascii, but if we are to have ascii abc whi
Jack Campin wrote:
Would not a charset specifier be a good addition? (if there is already
such, I shall be most embarrassed... as I am pretty much every day).
A rule such as, if you use something specific to a charset, you must
specify it otherwise expect it to be 7bit ascii and display wrongly.
> Would not a charset specifier be a good addition? (if there is already
> such, I shall be most embarrassed... as I am pretty much every day).
> A rule such as, if you use something specific to a charset, you must
> specify it otherwise expect it to be 7bit ascii and display wrongly.
This is s
Phil Taylor wrote:
On 29 Apr 2004, at 08:34, Stephen Kellett wrote:
In message <[EMAIL PROTECTED]>,
Phil Taylor <[EMAIL PROTECTED]> writes
On 29 Apr 2004, at 00:32, Steven Bennett wrote:
According to Apple docs (I'll take their word for it... ;):
0x2028 -- Unicode line separator
0x2029 --
On 29 Apr 2004, at 08:34, Stephen Kellett wrote:
In message <[EMAIL PROTECTED]>, Phil
Taylor <[EMAIL PROTECTED]> writes
On 29 Apr 2004, at 00:32, Steven Bennett wrote:
According to Apple docs (I'll take their word for it... ;):
0x2028 -- Unicode line separator
0x2029 -- Unicode paragraph s
In message <[EMAIL PROTECTED]>, Phil
Taylor <[EMAIL PROTECTED]> writes
On 29 Apr 2004, at 00:32, Steven Bennett wrote:
According to Apple docs (I'll take their word for it... ;):
0x2028 -- Unicode line separator
0x2029 -- Unicode paragraph separator
Thank you Steve,
Pardon my ignorance, bu
On 28 Apr 2004, at 21:42, Steven Bennett wrote:
That said, the file contents in the ABC specifications (including the
2.0
draft) are assumed to be strictly ASCII compliant, and I believe case
sensitive everywhere. (Someone correct me if I missed something
there.)
I believe that the mode part of
On 29 Apr 2004, at 00:32, Steven Bennett wrote:
According to Apple docs (I'll take their word for it... ;):
0x2028 -- Unicode line separator
0x2029 -- Unicode paragraph separator
Pardon my ignorance, but how do you know that you're dealing with
Unicode
here, rather than the ascii " (" and
According to Apple docs (I'll take their word for it... ;):
0x2028 -- Unicode line separator
0x2029 -- Unicode paragraph separator
-->Steve Bennett
Stephen Kellett wrote:
> In message <[EMAIL PROTECTED]>, Steven Bennett
> <[EMAIL PROTECTED]> writes
>> line endings needing to match throu
In message <[EMAIL PROTECTED]>, Steven Bennett
<[EMAIL PROTECTED]> writes
line endings needing to match throughout the file, and will accept Unicode
line and paragraph endings
What values (in hex - 0x, please) do those two characters have?
Stephen
--
Stephen Kellett
Object Media Limitedhtt
> I'm just doublechecking since this conversation spun off of the
> universal parser conversation...
>
> This conversation, while interesting doesn't actually pertain to the
> parser does it? I've been trying to follow it in case it does.
>
> My understanding is that a parser will not do any fil
I'm just doublechecking since this conversation spun off of the
universal parser conversation...
This conversation, while interesting doesn't actually pertain to the
parser does it? I've been trying to follow it in case it does.
My understanding is that a parser will not do any file handling,
John Chambers wrote:
> Lest you think this is way off topic, I might mention that I've been
> involved in attempts to use non-ASCII char sets in my ABC tunes. I
> have a lot of "international folk dance" tunes, and it would be
> really nice to be able to spell the titles right. Also, I li
Martin Tarenskeen writes:
| On Tue, 27 Apr 2004, Stephen Kellett wrote:
| > John Chambers wrote:
| > >OSX presents an interesting portability challenge: The default file
| > >system has "caseless" file names. If you look around, you might not
| > >notice this, because mixed-case names abound. B
18 matches
Mail list logo
