Re: problems with german umlauts
In message [EMAIL PROTECTED], Jonathan Henkelman [EMAIL PROTECTED] writes Mats Bengtsson mats.bengtsson at ee.kth.se writes: You are mistaken. ASCII only defines character codes up to 127, see for example http://www.asciitable.com/. What your table shows is probably Latin1 (ISO 8859-1). /Mats Mats: FYI I am using an ascii table in my little black pocket ref. which does not differentiate between standard and extended table. Also I use the one provided in MS Word. It allows you to pick between Unicode (various subsets) ASCII hex and decimal, but it also does not differentiate between extended and basic. What I am hearing hear in the larger context is that the basic ASCII set is only 127 characters while what I am used to using is actually one of a number of extended character sets... Exactly. What you call basic ASCII is the character set that everybody agrees about - for example 32=space, 65=A. The problem with extended ASCII, ie between 128 and 255, is that *nobody* *agrees* what those characters mean. In other words, it's NOT A STANDARD. UTF-8 is the only way to write both in danish AND french on the same text... On my machine I can write a single ascii text document (using the full table) that is in german, spanish, danish, norwegian, french, english. What character set are you using? It's all very well saying you can *write* a document in those languages, but there is NO GUARANTEE that anybody else will be able to READ that document! (Not unless you use something like UTF-8, that is ...) Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
well it was an approximation (due to the previously mentionned lack of vocabulary) Do you mean that your English isn't sufficient to describe the things correctly or that the issue itself is difficult to describe? ISO 2022 (as well as SHIFT-JIS and other japaneses encoding of the same type) use indeed artificial 8bit characters. `Artificial'? Not at all! Almost all of the registered 8bit character sets have been in use sometime and somewhere. The same for the 16bit encodings. Note that even Unicode (encoded as UTF8) has been registered, and there exist proper escape sequences to switch from ISO 2022 to Unicode and back to ISO 2022.[1] The 0-127 range is always almost compatible with ASCII Uh, oh, you are entering muddy waters. In old times, people haven't actually used ASCII but officially approved variants of ISO-646. IIRC, about 10 characters in the range 0x20-0x7F are variable. and there is 2 escaping character which work like double quotes. Inside quotes, character are multibyte (indeed it's impossible to store so many kanjis into only 128 slots) Hmm, `double quotes' is perhaps a bad analogy. The one escape character (followed by a character set ID) activates a different encoding for the next character only, the other does the same permanently. But this option raises more issues than it brings solutions... even if it is still widely used in japan (ISO 2022 is still their default encoding for e-mailings) The very problem is that you can encode a single character like `á' in many ways; for example, you could switch to latin1, or to latin2, or... Additionally, ISO 2022 is stateful, this is, if you encounter a bad or missing byte, the rest of the document might be corrupted. For this reason it has become standard to switch back the encoding at the end of a line and restart it at the beginning of the next line. Werner [1]: Just to make clear how ISO 2022 works (slightly simplified): The byte range 0-255 is split into four areas: The `control code' areas C0 (0x00-0x1F) and C1 (0x80-0x9F), and the left and right `graphic code' areas (GL and GR, code ranges 0x20-0x7F and 0xA0-0xFF). Three character codes are always at the same position: ESC (0x1B), SPACE (0x20), and DELETE (0x7F). In the following, I ignore C0 and C1. In a first step, registered character sets are assigned to GL and GR. Normally, GL holds the standard version of ISO-646 (which is equal to ASCII if combined with C0), but national variants exist. For example, in Japan you'll often find that the backslash (at position 0x5C) is replaced with the Yen sign. GR then gets the `extended' character sets with either 96 characters (latin1, for example) or 96x96 characters (JIS X 0208 for Japanese, GB 2312 for Chinese, etc.) or even 96x96x96 (CCCII, a Chinese encoding, now defunct). It's even possible to not use GR at all: The above-mentioned Japanese email encoding is using only the bytes 0x00-0x7F (since in former times not all email clients supported 8bit cleanly), switching forth and back between encodings which share the range 0x20-0x7F. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Ok ;-) Please do a replace-all for non-ascii to accented and special :-) Bert Go ahead: http://lilypond.org/web/devel/participating/documentation-adding - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Hello, I began with lilypond (2.11.12) last sunday (21.01.07) and I also had some trouble with accents à la française and deutsche Umlaute. On Linux : (x)emacs was too difficult (for me) to configure utf-8 output, [xemacs it is the editor whose short cuts I know the best] but it is easy to configure kate in order to obtain utf-8 output. So I edited, with kate, a file with the needed letters in french and german ; using (x)emacs I proceed by copy/paste. Des wärs fir heit. Tschss .. .. but if someone could explain me how to configure xemacs, it would be fine. -- René Bastian http://www.musiques-rb.org http://www.pythoneon.musiques-rb.org ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
You could also try jEdit (http://www.jedit.org). It doesn't need configuration, and has the LilyPondTool plugin (installable from Plugin Manager) There is also an emacs emulation package for jEdit: http://www.clapper.org/software/jedit/ if you'd like to get the same shortcuts. Bert ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
On Linux, the easiest way to get UTF-8 output in xemacs is to simply start it from a shell where you have specified the locale using export LANG en_GB.utf-8 (or 'setenv LANG en_GB.utf-8' if you use (t)csh). Of course, for you living in France, you may want fr_FR.utf8 instead of en_GB.utf-8. Depending on your Linux distribution it's probably possible to do some global setting of the locale using a nice GUI somewhere. Last time I looked, it was unfortunately not that simple if you want to use xemacs in Windows, since the unicode support isn't added there by default. However, ordinary Gnu Emacs has good multilanguage support both in Linux and Windows. /Mats René Bastian wrote: Hello, I began with lilypond (2.11.12) last sunday (21.01.07) and I also had some trouble with accents à la française and deutsche Umlaute. On Linux : (x)emacs was too difficult (for me) to configure utf-8 output, [xemacs it is the editor whose short cuts I know the best] but it is easy to configure kate in order to obtain utf-8 output. So I edited, with kate, a file with the needed letters in french and german ; using (x)emacs I proceed by copy/paste. Des wärs fir heit. Tschss .. .. but if someone could explain me how to configure xemacs, it would be fine. -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
In message [EMAIL PROTECTED], Bertalan Fodor [EMAIL PROTECTED] writes Because most accented European characters can not be accessed within ascii My ascii table shows all French, Norwegian, Danish characters as well as most spanish, and german (can't profess to be an expert there) see characters 191- 255 (xBF - xff). Are these accessable in a non-unicode document? AFAIK you must use UTF-8. (It is not the same as 'unicode' in general.) The documentation should be clearer. Bert ps: Anyway, my note was because of Central and Eastern European Languages - Polish, Slovakian, Czech, Slovenian, Croatian, Romanian etc, even users of cyrillic alphabets: Serbian, Russian, Bulgarian, and more. I must also mention Greece. There are even 27 countries in the EU now, and only 10 or such of them are handled fully by ASCII. Now it's time for editor softwares to handle this new situation ;-) Even English isn't handled properly by ASCII - after all, the A stands for American, don'cher'no :-) Although rarely used (and invariably got wrong), English has a 27th letter that is often seen, namely the (I think) thorn. Pronounced th, it's a Y with a bar through it (think Japanese Yen symbol here), and is usually seen in signs saying things like Ye olde coffee shoppe. (Which is why ye is NOT an archaic *pronounciation* of the, it's a corruption of an old *spelling* of the.) Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Mats Bengtsson mats.bengtsson at ee.kth.se writes: You are mistaken. ASCII only defines character codes up to 127, see for example http://www.asciitable.com/. What your table shows is probably Latin1 (ISO 8859-1). /Mats Mats: FYI I am using an ascii table in my little black pocket ref. which does not differentiate between standard and extended table. Also I use the one provided in MS Word. It allows you to pick between Unicode (various subsets) ASCII hex and decimal, but it also does not differentiate between extended and basic. What I am hearing hear in the larger context is that the basic ASCII set is only 127 characters while what I am used to using is actually one of a number of extended character sets... The manual is plenty clear about using utf-8 for non-latin alphabets. Where I get confused in the manual is this: PDF version 2.10.0 pg. 112 paragraph 4: To enter lyrics with characters from non-English languages, or with non-ASCII characters (such as the heart symbol or slanted quotes), This could be changed to ... non-English languages, or with extended ASCII characters (accented or special characters such as the heart symbol or slanted quotes), ... However on the same page paragraph 7: A word in Lyrics mode begins with: ... , any 8-bit character with ASCII code over 127, ... This is simply not true (I just tried it and upper ascii codes do not work in lyric mode (10.2.0) even when starting a word. This reference should be deleted if LP is not going to support it. If the docment is UTF-8 encoded then it really isn't an ASCII code over 127 anyway. :) For the sake of completeness other manual references which will need to be updated: pg 158, para. 2: delete ... non-ascii text (such as characters from other languages), ... and insert ... extended ASCII text (such as accented and special characters or characters from other languages), ... pg 227, sec 10.1.7, para 1: delete ... non-ASCII ..., and insert ... extended ascii characters (such as accented and special characters or characters from other languages) ... Do not change the reference on pg 288! as it refers to ABC not LP. The reference on pg 332 seems fine and is part of GNU license. That being said, can anyone answer what happens in LP when upper ascii characters are encountered. Is there any reason they can't just be mapped to whatever the upper ascii table is on that machine (or some standard within the LP community)? It would make it much easier for english speakers who only occasionally use accented characters. I edit using xemacs and am not looking forward to trying to get it save in UTF-8. UTF-8 is the only way to write both in danish AND french on the same text... On my machine I can write a single ascii text document (using the full table) that is in german, spanish, danish, norwegian, french, english. Thanks J ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
On Fri, 26 Jan 2007 17:31:24 + (UTC), Jonathan Henkelman wrote: On my machine I can write a single ascii text document (using the full table) that is in german, spanish, danish, norwegian, french, english. Jonathan - the whole point of what he was just telling you is that what you're calling the full table isn't ASCII, whatever it may claim. Only the first half (the easy stuff) is ASCII - the rest is arbitrary additions that nobody agrees on. The fact that it's on your machine or in your reference book means nothing to anybody else. There already is a standard within the LP community to solve this problem - it's UTF-8. Extra add-on standards would just make trouble for everybody, since nobody's files would match anymore, and everybody would be getting and giving wrong instructions because of it. David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
David Gippner davidgippner at googlemail.com writes:
I've got problems with german umlauts in Lilypond 2.11.13-1. Wherever
there is one, I just get blanks.
Would something like:
\markup { \override #'(word-space . 0) \line {(f \char #252 r 1 oder 2
Manuale)} }
solve your problem.
BTW I don't understand all this unicode business. Most european characters
can be accessed within ascii. Why should we have to go to unicode to get them?
J
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
BTW I don't understand all this unicode business. Most european characters can be accessed within ascii. Why should we have to go to unicode to get them? Because most accented European characters can not be accessed within ascii :-) It greatly simplifies things, you know that everything is UTF-8, so don't have to care with encodings. Bert ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Jonathan Henkelman wrote: BTW I don't understand all this unicode business. Most european characters can be accessed within ascii. Why should we have to go to unicode to get them? If you search the mailing list archives from the time before we introduced unicode support, you will be surprised how many questions there are related to Russian or Hebrew or Mandarin or ... /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Mats Bengtsson mats.bengtsson at ee.kth.se writes: If you search the mailing list archives from the time before we introduced unicode support, you will be surprised how many questions there are related to Russian or Hebrew or Mandarin or ... /Mats It wasn't intended to be a stupid question. I'm all over unicode for languages that use other character sets - cyrillic, hebrew, asian etc. I was just surprised at how difficult it was to put an umlaut on a u for a german peice I was typesetting. Perhaps the problem lies in the documentation. It suggests that if you want to use non-ascii characters you have to save the document as unicode - fair enough. (In fact it implies you can use any 8-bit ascii pg. 112, last paragrph, PDF version 2.10.0) But I wanted to use ascii 252 (presumably similar to David in the original post) and I just inserted it into my document - and it compiled to a space. Here I am trying to use an ascii character and hence expect not to have to do anything special, but would I still have to save it as unicode? When I used \char, I had to find the tweak to get rid of the spaces before and after that character... Because most accented European characters can not be accessed within ascii My ascii table shows all French, Norwegian, Danish characters as well as most spanish, and german (can't profess to be an expert there) see characters 191- 255 (xBF - xff). Are these accessable in a non-unicode document? Thanks, J ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
You are mistaken. ASCII only defines character codes up to 127, see for example http://www.asciitable.com/. What your table shows is probably Latin1 (ISO 8859-1). /Mats Quoting Jonathan Henkelman [EMAIL PROTECTED]: Mats Bengtsson mats.bengtsson at ee.kth.se writes: If you search the mailing list archives from the time before we introduced unicode support, you will be surprised how many questions there are related to Russian or Hebrew or Mandarin or ... /Mats It wasn't intended to be a stupid question. I'm all over unicode for languages that use other character sets - cyrillic, hebrew, asian etc. I was just surprised at how difficult it was to put an umlaut on a u for a german peice I was typesetting. Perhaps the problem lies in the documentation. It suggests that if you want to use non-ascii characters you have to save the document as unicode - fair enough. (In fact it implies you can use any 8-bit ascii pg. 112, last paragrph, PDF version 2.10.0) But I wanted to use ascii 252 (presumably similar to David in the original post) and I just inserted it into my document - and it compiled to a space. Here I am trying to use an ascii character and hence expect not to have to do anything special, but would I still have to save it as unicode? When I used \char, I had to find the tweak to get rid of the spaces before and after that character... Because most accented European characters can not be accessed within ascii My ascii table shows all French, Norwegian, Danish characters as well as most spanish, and german (can't profess to be an expert there) see characters 191- 255 (xBF - xff). Are these accessable in a non-unicode document? Thanks, J ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Because most accented European characters can not be accessed within ascii My ascii table shows all French, Norwegian, Danish characters as well as most spanish, and german (can't profess to be an expert there) see characters 191- 255 (xBF - xff). Are these accessable in a non-unicode document? AFAIK you must use UTF-8. (It is not the same as 'unicode' in general.) The documentation should be clearer. Bert ps: Anyway, my note was because of Central and Eastern European Languages - Polish, Slovakian, Czech, Slovenian, Croatian, Romanian etc, even users of cyrillic alphabets: Serbian, Russian, Bulgarian, and more. I must also mention Greece. There are even 27 countries in the EU now, and only 10 or such of them are handled fully by ASCII. Now it's time for editor softwares to handle this new situation ;-) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Well, since charsets issue is my hobby ... I can write a short explanation (try to... my shortage of english vocabulary could be an issue) After having defined a 128 character table (0 -127 on 8 bits, well one zero + 7bits) covering only the English characters and some signs, called the ASCII table; has been defined many extended tables using the 128 - 255 range to store some regional character. There are around 10 extended tables to fit with either the french, the danish, the Greek specificities (but not all at the same time) : http://en.wikipedia.org/wiki/Category:ISO_8859 Japaneses and Chineses had some strange way to store their 36 000 ideograms and there it started to be a mess. Unicode consortium defined a HUGE table aiming to store every character (well almost, but it's another problem) on 32 bits. But the devilish ASCII was always here, hidden in the dark. So they ended to design UTF-8 encoding system which is only an amazing trick to store the unicode table : - all the characters of the former 0 - 127 range of the ascii table are stored on 8bits... so a pure ascii file is also a genuine UTF-8 file ^^ - To store other characters they use an ingeniously designed system of drawers using the characters from 128 to 255 (and some more bytes if necessary) UTF-8 is the only way to write both in danish AND french on the same text... and it is fully compatible with ASCII files... nice isn't it ? Yota hope it's clear... hips I could explain this more easily, in french, with a whiteboard and a cup of coffee On 1/25/07, Mats Bengtsson [EMAIL PROTECTED] wrote: You are mistaken. ASCII only defines character codes up to 127, see for example http://www.asciitable.com/. What your table shows is probably Latin1 (ISO 8859-1). /Mats Quoting Jonathan Henkelman [EMAIL PROTECTED]: Mats Bengtsson mats.bengtsson at ee.kth.se writes: If you search the mailing list archives from the time before we introduced unicode support, you will be surprised how many questions there are related to Russian or Hebrew or Mandarin or ... /Mats It wasn't intended to be a stupid question. I'm all over unicode for languages that use other character sets - cyrillic, hebrew, asian etc. I was just surprised at how difficult it was to put an umlaut on a u for a german peice I was typesetting. Perhaps the problem lies in the documentation. It suggests that if you want to use non-ascii characters you have to save the document as unicode - fair enough. (In fact it implies you can use any 8-bit ascii pg. 112, last paragrph, PDF version 2.10.0) But I wanted to use ascii 252 (presumably similar to David in the original post) and I just inserted it into my document - and it compiled to a space. Here I am trying to use an ascii character and hence expect not to have to do anything special, but would I still have to save it as unicode? When I used \char, I had to find the tweak to get rid of the spaces before and after that character... Because most accented European characters can not be accessed within ascii My ascii table shows all French, Norwegian, Danish characters as well as most spanish, and german (can't profess to be an expert there) see characters 191- 255 (xBF - xff). Are these accessable in a non-unicode document? Thanks, J ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
After having defined a 128 character table (0 -127 on 8 bits, well one zero + 7bits) covering only the English characters and some signs, called the ASCII table; has been defined many extended tables using the 128 - 255 range to store some regional character. There are around 10 extended tables to fit with either the french, the danish, the Greek specificities (but not all at the same time) : http://en.wikipedia.org/wiki/Category:ISO_8859 Actually, there are much more. If I'm not mistaken, the ISO 2022 registry has designed IDs to over 100 different 8bit character sets! Japaneses and Chineses had some strange way to store their 36 000 ideograms and there it started to be a mess. This isn't true in general. For handling those languages separately, 16bit character sets work just fine. Emacs demonstrates that, within the ISO 2022 framework, multilingual work can be done quite efficiently. BTW, the value `36000' is not correct: The CNS 11643 character set defines around 55000 Chinese characters, and the defunct CCCII character set covered around 7 characters (I have the books at home -- it's almost a half meter on my bookshelf). Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Actually, there are much more. If I'm not mistaken, the ISO 2022 registry has designed IDs to over 100 different 8bit character sets! `assigned', of course. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
well it was an approximation (due to the previously mentionned lack of vocabulary) ISO 2022 (as well as SHIFT-JIS and other japaneses encoding of the same type) use indeed artificial 8bit characters. The 0-127 range is always almost compatible with ASCII and there is 2 escaping character which work like double quotes. Inside quotes, character are multibyte (indeed it's impossible to store so many kanjis into only 128 slots) But this option raises more issues than it brings solutions... even if it is still widely used in japan (ISO 2022 is still their default encoding for e-mailings) Yota On 1/25/07, Werner LEMBERG [EMAIL PROTECTED] wrote: After having defined a 128 character table (0 -127 on 8 bits, well one zero + 7bits) covering only the English characters and some signs, called the ASCII table; has been defined many extended tables using the 128 - 255 range to store some regional character. There are around 10 extended tables to fit with either the french, the danish, the Greek specificities (but not all at the same time) : http://en.wikipedia.org/wiki/Category:ISO_8859 Actually, there are much more. If I'm not mistaken, the ISO 2022 registry has designed IDs to over 100 different 8bit character sets! Japaneses and Chineses had some strange way to store their 36 000 ideograms and there it started to be a mess. This isn't true in general. For handling those languages separately, 16bit character sets work just fine. Emacs demonstrates that, within the ISO 2022 framework, multilingual work can be done quite efficiently. BTW, the value `36000' is not correct: The CNS 11643 character set defines around 55000 Chinese characters, and the defunct CCCII character set covered around 7 characters (I have the books at home -- it's almost a half meter on my bookshelf). Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Bertalan Fodor wrote: Because most accented European characters can not be accessed within ascii My ascii table shows all French, Norwegian, Danish characters as well as most spanish, and german (can't profess to be an expert there) see characters 191- 255 (xBF - xff). Are these accessable in a non-unicode document? AFAIK you must use UTF-8. (It is not the same as 'unicode' in general.) The documentation should be clearer. Go ahead: http://lilypond.org/web/devel/participating/documentation-adding - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Re: Problems with german umlauts
No, it is not. Is there another possibility than just encode the whole thing as UTF-8? Yours, David Gippner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with german umlauts
It's nothing difficult, just a matter of telling your text editor to save the file using UTF-8 encoding. If you cannot figure it out yourself, just send a question to the mailing list, telling what text editor you are using. /Mats David Gippner wrote: No, it is not. Is there another possibility than just encode the whole thing as UTF-8? Yours, David Gippner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with german umlauts
When using any convert option of WinEdt with UTF-8, the File cannot be compiled and is corrupted. Yours, David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with german umlauts
then you should go shopping for a better editor IMO /S On 1/24/07, David Gippner [EMAIL PROTECTED] wrote: When using any convert option of WinEdt with UTF-8, the File cannot be compiled and is corrupted. Yours, David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with german umlauts
I have very good experience with Jedit. It runs on any platform. Together with the excellent Lilypond Tool for Jedit from Bertalan Fodor you get very nice features like syntax checking etc. And it can save the file UTF-8 encoded. All about the editor and the newest version of the plug-in is given in the following thread. Just download, install and enjoy. http://www.nabble.com/LilyPondTool-2.10.3-released-tf3035317.html#a8438263 http://www.nabble.com/LilyPondTool-2.10.3-released-tf3035317.html#a8438263 Of course there are many other editors available (like emacs, ...) that do the same job. Best regards Uwe Nagel David Gippner wrote: When using any convert option of WinEdt with UTF-8, the File cannot be compiled and is corrupted. Yours, David ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- View this message in context: http://www.nabble.com/problems-with-german-umlauts-tf3065236.html#a8571510 Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with german umlauts
Now a good version of LilyPondTool is released in the Plugin Manager of jEdit, so you can safely install from there. So just download jEdit 4.3pre9 (http://www.jedit.org - get the latest development version), go to Plugin Manager Install LilyPondTool. Check the Plugin options after install and there you are. Bert ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with german umlauts
Is your .ly file UTF-8 encoded? Uwe Nagel David Gippner wrote: Dear list, I've got problems with german umlauts in Lilypond 2.11.13-1. Wherever there is one, I just get blanks. What can I do against that? Yours sincerely David Gippner P.S.: If this is useful, I can provide a PDF of what I mean. Requests to [EMAIL PROTECTED] please. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- View this message in context: http://www.nabble.com/problems-with-german-umlauts-tf3065236.html#a8526497 Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
