Non-latin1 characters (was: Lyricsto skips notes with melisma's in 2.2)

[Michał Dwużnik]

On Wed, 12 Jan 2005 14:42:37 +0100, Mats Bengtsson
<address@hidden> wrote:
> I don't remember from the top of my head what version of LilyPond
> you use. In version 2.2, it was possible to set the input and
> font encoding using
> \header{
>    fontencoding="..."
>    inputencoding="..."
> }
> 
That _was_ nice :), and let me do some tricks with latex intermediate
file, after willingly crashing lilypond by not defining the encoding and
using non-latin1 characters inside the piece :)

> If you use version 2.4, don't spend too much energy on solving these
> problems since a new solution is already (almost) implemented in
> the latest development versions and it seems that the release of
> the next stable version 2.6 is not in the very far future.
> 
I found my solution (involving sed) after some struggle, and to avoid
that struggle
I proposed adding something to the docs, like an example
of what strange glyphs different people  use in their own languages.
You may be sure that I will be one of the first people to try 2.6 utf
features :).

Of course if 2.6 is due in something like 1 month,
we can leave it, but if it's 6 months I would consider adding some hints or
expanding "embedded TeX" example.

> > to have a more generous example on "TeX" encoding for the use of
> > non-fully-latin alphabet
> > users ? And a clear remark, that  one should probably not try to write 
> > his/her
> > national characters "normally" (like latin2 encoding), or preprocess
> > the file to produce TeX
> > equivalents before running lilypond.

That's the part I feel is missing in 2.4 documentation - that if you really
want something in e.g. latin2 - use TeX encoding. I really have spent
lots of time getting my test files processed with no errors,
and seeing completely messy output afterwards, regardless
of defining
> \header{
>    fontencoding="..."
>    inputencoding="..."
> }
This applies to section 7.4.1 of the 2.4 documentation - 
trying both cp1250 and latin2 for the inputencoding (Linux and Windows
install) , T1 for
fontencoding, general \encoding "latin2" gave me only completely messy output, 
the only usable encoding being "TeX" and writing the Polish glyphs 
by \k{a}, \\'c and so on.

In my private mail I keep a discussion with two other Polih guys, who
hadn't ever managed
to get fontencoding and inputencoding working for version 2.4 and in
the same time
reporting that it works within 2.2. 
 
For version 2.4 example of getting Polish glyphs follows:

---
\encoding "TeX"
\header{
title = "\k{a}\\'c\k{e}\l\\'n\\'o\\'s\.z\\'zi"
composer = "\k{A}\\'C\k{E}\L\\'N\\'O\\'S\.Z\\'ZI"
}

\transpose  c c' {
<<
 {c d e f g a b c' cis' c d e f g a b c' cis' }
\addlyrics { "\k{a}" "\\'c" "\k{e}" "\l" "\\'n" "\\'o" "\\'s" "\.z" "\\'z"
"\k{A}" "\\'C" "\k{E}" "\L" "\\'N" "\\'O" "\\'S" "\.Z" "\\'Z"
}
>>
}
-----

This lets us use all the needed glyphs (and many others), but is far
from comfortable,
version 2.2 example with :

\header{
inputencoding = "cp1250" 
fontencoding = "T1"
}

was reported to work perfectly, and used the encoding "natural" for windows
(latin2 for linux I suppose) .

In version 2.4.2 
---
\header{
nputencoding = "cp1250"
fontencoding = "T1"
}

\transpose  c c' {
<<
{c}
\addlyrics { ą }
>>
}
----
yields the following .log


---
This is TeXk, Version 3.14159 (Web2C 7.4.5) (format=latex 2005.1.13) 
13 JAN 2005 11:40
 %&-line parsing enabled.
**\nonstopmode \input test.tex
(./test.tex (/usr/share/lilypond/2.4.2/tex/lilyponddefs.tex
\lytempdim=\dimen102
\outputscale=\dimen103

(/usr/share/lilypond/2.4.2/tex/lily-ps-defs.tex))
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo
File: size10.clo 2001/04/21 v1.4e Standard LaTeX file (size option)
)
(...)

(/usr/share/texmf/tex/latex/base/inputenc.sty
Package: inputenc 2001/07/10 v0.99a Input encoding file 

(/usr/share/texmf/tex/latex/base/latin1.def
File: latin1.def 2001/07/10 v0.99a Input encoding file 
)) 
----

so it clearly tries to use latin1 encoding, where it shouldn't.


Shall we have an update like "Non latin1 (or maybe just latin2) inputencodings 
are deprecated in version 2.4, use TeX encoding and type the TeX
equivalents of your
national characters. If you do not feel comfortable with 
TeX equivalents please do some preprocessing replacing the needed characters 
by their TeX prefix represantation." in section 7.4.1 ?


Best regards, and thanks for Graham and Mats for their infinite will 
of help.

Michal