subject:"RE\: utf\-8"

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-06-14 Thread Jonas Hahnfeld via LilyPond user discussion

On Wed, 2022-05-25 at 13:24 -0600, David F. wrote:
> 
> > On May 25, 2022, at 11:21 AM, Jonas Hahnfeld  wrote:
> > 
> > On Sat, 2022-05-21 at 15:20 -0600, David F. wrote:
> > > System: Intel-based macOS
> > > 
> > > I make extensive use of UTF-8 characters in the filenames of my Lilypond 
> > > files.  This works in Lilypond up through version 2.22.  But Lilypond 
> > > 2.23 cannot handle UTF-8 characters in filenames.
> > > 
> > > Filename: tést.ly
> > > 
> > > \version "2.22"
> > > 
> > > { c' }
> > > 
> > > 
> > > Under v2.22, this file complies without problem.  With 2.23 (including 
> > > the just release 2.23.9) I get the following error:
> > > 
> > > Starting lilypond 2.23.9 [tést.ly]...
> > > warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
> > > fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
> > > Exited with return code 1.
> > > 
> > > I thought that this problem had already been reported, but I can’t find 
> > > any mention of it now.  So I’m reporting it.
> > > 
> > > David F.
> > 
> > Hi David,
> > 
> > I can indeed reproduce this on macOS, which I think is the critical
> > piece of information here. It would just be too boring if all operating
> > systems agreed on how to handle filenames with special characters... In
> > this case, it might also have to do with the file system because if I
> > do 'ls', I also get question marks (but this might also be because I'm
> > ssh-ing from Linux...)

No, it didn't have to do with the file system, the scripts for building
the binaries were just missing an environment variables so that libintl
was properly found on macOS, which is apparently required for some
locale settings. The problem should be fixed in the next release, see
https://gitlab.com/lilypond/lilypond/-/merge_requests/1410
(Actually, this will also fix localized messages on macOS which didn't
work so far.)

> 
> Thanks for looking into this Jonas.  As I said in my original message 
> Lilypond up to v2.22 handles UTF characters just fine.

LilyPond 2.22.x used Guile 1.8 with binaries produced by a different
system (called GUB).

Jonas


signature.asc
Description: This is a digitally signed message part

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-25 Thread David Wright

On Sat 21 May 2022 at 23:36:26 (-0600), David F. wrote:
> > On May 21, 2022, at 5:01 PM, Jean Abou Samra  wrote:
> > Le 21/05/2022 à 23:20, David F. a écrit :
> >> System: Intel-based macOS
> >> 
> >> I make extensive use of UTF-8 characters in the filenames of my Lilypond 
> >> files.  This works in Lilypond up through version 2.22.  But Lilypond 2.23 
> >> cannot handle UTF-8 characters in filenames.
> >> 
> >> Filename: tést.ly
> >> 
> >> \version "2.22"
> >> 
> >> { c' }
> >> 
> >> 
> >> Under v2.22, this file complies without problem.  With 2.23 (including the 
> >> just release 2.23.9) I get the following error:
> >> 
> >> Starting lilypond 2.23.9 [tést.ly]...
> >> warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
> >> fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
> >> Exited with return code 1.
> >> 
> >> I thought that this problem had already been reported, but I can’t find 
> >> any mention of it now.  So I’m reporting it.
> > 
> > This is actually not an issue with LilyPond, but with Frescobaldi,
> > when you have "run LilyPond with English messages" enabled in the
> > Preferences. This problem is known for some time already, but
> > I didn't see an issue in the Frescobaldi tracker, so I just
> > opened one:
> > 
> > https://github.com/frescobaldi/frescobaldi/issues/1438
> > 
> > The workaround is to uncheck "Run LilyPond with English messages"
> > in Edit > Preferences > LilyPond Preferences.
> 
> No, I get the same error running lilypond from the command line:
> 
> $ lilypond --png tést.ly 
> GNU LilyPond 2.23.9 (running Guile 2.2)
> warning: cannot find file: `t??st.ly'
> fatal error: failed files: "t??st.ly”

I didn't spot this until I read Hraban's post about MacOS, about which
I know almost nothing, but your two errors are not the same. Compared
in close proximity, you can more easily see:

  warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
  ↑
 warning: cannot find file: `t??st.ly'

So it looks as if the first error is a normalisation error: é has been
decomposed into e + ´, or rather e + COMBINING ACUTE ACCENT U+0301,
the latter being CC81 in utf-8, whereas the second error looks
like a composed é, which is C3A9 in utf-8. Each appears to generate
two question marks, but the first leaves the initial e in place,
so three chars in all.

>From glancing at pages like:
https://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenames/
https://news.ycombinator.com/item?id=14495823
and the article discussed in the latter (there's a link at the top),
I don't envy anyone supporting these filesystems.

Is Python's unicodedata.normalize("NFKC", … ) meant to handle all this?

Cheers,
David.

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-25 Thread David F.




> On May 25, 2022, at 11:21 AM, Jonas Hahnfeld  wrote:
> 
> On Sat, 2022-05-21 at 15:20 -0600, David F. wrote:
>> System: Intel-based macOS
>> 
>> I make extensive use of UTF-8 characters in the filenames of my Lilypond 
>> files.  This works in Lilypond up through version 2.22.  But Lilypond 2.23 
>> cannot handle UTF-8 characters in filenames.
>> 
>> Filename: tést.ly
>> 
>> \version "2.22"
>> 
>> { c' }
>> 
>> 
>> Under v2.22, this file complies without problem.  With 2.23 (including the 
>> just release 2.23.9) I get the following error:
>> 
>> Starting lilypond 2.23.9 [tést.ly]...
>> warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
>> fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
>> Exited with return code 1.
>> 
>> I thought that this problem had already been reported, but I can’t find any 
>> mention of it now.  So I’m reporting it.
>> 
>> David F.
> 
> Hi David,
> 
> I can indeed reproduce this on macOS, which I think is the critical
> piece of information here. It would just be too boring if all operating
> systems agreed on how to handle filenames with special characters... In
> this case, it might also have to do with the file system because if I
> do 'ls', I also get question marks (but this might also be because I'm
> ssh-ing from Linux...)
> 
> Jonas

Thanks for looking into this Jonas.  As I said in my original message Lilypond 
up to v2.22 handles UTF characters just fine.

David F.

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-25 Thread Henning Hraban Ramm


Am 25.05.22 um 19:21 schrieb Jonas Hahnfeld via LilyPond user discussion:

On Sat, 2022-05-21 at 15:20 -0600, David F. wrote:

System: Intel-based macOS

I make extensive use of UTF-8 characters in the filenames of my Lilypond files. 
 This works in Lilypond up through version 2.22.  But Lilypond 2.23 cannot 
handle UTF-8 characters in filenames.

Filename: tést.ly

\version "2.22"

{ c' }


Under v2.22, this file complies without problem.  With 2.23 (including the just 
release 2.23.9) I get the following error:

Starting lilypond 2.23.9 [tést.ly]...
warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
Exited with return code 1.

I thought that this problem had already been reported, but I can’t find any 
mention of it now.  So I’m reporting it.

David F.


Hi David,

I can indeed reproduce this on macOS, which I think is the critical
piece of information here. It would just be too boring if all operating
systems agreed on how to handle filenames with special characters... In
this case, it might also have to do with the file system because if I
do 'ls', I also get question marks (but this might also be because I'm
ssh-ing from Linux...)


MacOS uses decomposed Unicode in the file system, i.e. é is e + 
combining accent acute and not just one glyph.
(It also decomposes accented characters, at least umlauts, if you copy 
from a PDF – very annoying...)


Hraban

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-25 Thread Jonas Hahnfeld via LilyPond user discussion

On Sat, 2022-05-21 at 15:20 -0600, David F. wrote:
> System: Intel-based macOS
> 
> I make extensive use of UTF-8 characters in the filenames of my Lilypond 
> files.  This works in Lilypond up through version 2.22.  But Lilypond 2.23 
> cannot handle UTF-8 characters in filenames.
> 
> Filename: tést.ly
> 
> \version "2.22"
> 
> { c' }
> 
> 
> Under v2.22, this file complies without problem.  With 2.23 (including the 
> just release 2.23.9) I get the following error:
> 
> Starting lilypond 2.23.9 [tést.ly]...
> warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
> fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
> Exited with return code 1.
> 
> I thought that this problem had already been reported, but I can’t find any 
> mention of it now.  So I’m reporting it.
> 
> David F.

Hi David,

I can indeed reproduce this on macOS, which I think is the critical
piece of information here. It would just be too boring if all operating
systems agreed on how to handle filenames with special characters... In
this case, it might also have to do with the file system because if I
do 'ls', I also get question marks (but this might also be because I'm
ssh-ing from Linux...)

Jonas


signature.asc
Description: This is a digitally signed message part

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-25 Thread David Wright

On Tue 24 May 2022 at 20:59:18 (-0700), Curt McDowell wrote:
> I get that same error if running under Docker, if LANG is set to
> en_US.UTF-8, but where en_US.UTF-8 does not exist in the output of
> "locale -a".
> 
>./out/bin/lilypond scheme-sandbox /(Lilypond 2.23.0, Guile 2.2.7,
>Ubuntu 20.04)/
>(open-input-file "tést.ly")
>In procedure open-file: No such file or directory: "t??st.ly"
> 
> Changing LANG makes Guile happy
> 
>export LANG=C.UTF-8
>./out/bin/lilypond scheme-sandbox
>(open-input-file "tést.ly")
>$1 = #
> 
> but strangely it still does not make Lilypond happy
> 
>./out/bin/lilypond tést.ly
>warning: cannot find file: `t??st.ly'
> 
> I don't know why.

It might help for us to see your entire locale, in case something
is overriding LANG. Then again, it might not:

(first, my disclosures)

$ cat /etc/default/locale 
LANG=C.UTF-8
LC_CTYPE="en_GB.UTF-8"
$ 

which generates:

$ locale
LANG=C.UTF-8
LANGUAGE=
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=
$ 

Available locales:

$ locale -a
C
C.UTF-8
POSIX
en_GB.utf8
en_US.utf8
$ 

> Lilypond 2.20.0 works in the same environment and seems insensitive to LANG.

Yes, 2.22 also, to anything:

$ LC_ALL=de_DE.UTF-8 lily -s /tmp/wwéstärn.ly 
bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
GNU LilyPond 2.22.1
Processing `wwéstärn.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `wwéstärn.pdf'...
Success: compilation successfully completed
$ 

And 2.18.2 LP itself is unfazed, but locale trips up ghostscript:

$ LC_ALL=de_DE.UTF-8 lily -o /tmp/wwéstärn.ly 
bash: warning: setlocale: LC_ALL: cannot change locale (de_DE.UTF-8)
GNU LilyPond 2.18.2
Processing `wwéstärn.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `wwéstärn.ps'...
Converting to `./wwéstärn.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-sOutputFile=./wwéstärn.pdf -c.setpdfwrite -fwwéstärn.ps)' failed (256)

fatal error: failed files: "wwéstärn.ly"

$ 

OTOH, one might expect this problem:

$ LC_CTYPE=de_DE.UTF-8 lily /tmp/wwéstärn.ly 
bash: warning: setlocale: LC_CTYPE: cannot change locale (de_DE.UTF-8)
GNU LilyPond 2.23.9 (running Guile 2.2)
warning: cannot find file: `ww??st??rn.ly'
fatal error: failed files: "ww??st??rn.ly"

$ 

but perhaps not this one, as LC_CTYPE should override LANG
(I've made it explicit as well as being my default):

$ LANG=de_DE.UTF-8 LC_CTYPE=en_GB.UTF-8 lily /tmp/wwéstärn.ly 
GNU LilyPond 2.23.9 (running Guile 2.2)
warning: cannot find file: `ww??st??rn.ly'
fatal error: failed files: "ww??st??rn.ly"

$ 

But you should be able to get everything to work with LC_ALL:

$ LC_ALL=en_GB.UTF-8 LANG=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 lily 
/tmp/wwéstärn.ly 
GNU LilyPond 2.23.9 (running Guile 2.2)
Processing `wwéstärn.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `wwéstärn.pdf'...
Success: compilation successfully completed
$ 

Cheers,
David.

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-24 Thread Curt McDowell

I get that same error if running under Docker, if LANG is set to 
en_US.UTF-8, but where en_US.UTF-8 does not exist in the output of 
"locale -a".


   ./out/bin/lilypond scheme-sandbox /(Lilypond 2.23.0, Guile 2.2.7,
   Ubuntu 20.04)/
   (open-input-file "tést.ly")
   In procedure open-file: No such file or directory: "t??st.ly"

Changing LANG makes Guile happy

   export LANG=C.UTF-8
   ./out/bin/lilypond scheme-sandbox
   (open-input-file "tést.ly")
   $1 = #

but strangely it still does not make Lilypond happy

   ./out/bin/lilypond tést.ly
   warning: cannot find file: `t??st.ly'

I don't know why.

Lilypond 2.20.0 works in the same environment and seems insensitive to LANG.

-Curt

On 5/21/2022 10:36 PM, David F. wrote:

No, I get the same error running lilypond from the command line:
$ lilypond --png tést.ly
GNU LilyPond 2.23.9 (running Guile 2.2)
warning: cannot find file: `t??st.ly'
fatal error: failed files: "t??st.ly”

David F.

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-22 Thread David Kastrup

Thomas Morley  writes:

> Am So., 22. Mai 2022 um 07:36 Uhr schrieb David F. :
>>
>>
>>
>> > On May 21, 2022, at 5:01 PM, Jean Abou Samra  wrote:
>> >
>> > Le 21/05/2022 à 23:20, David F. a écrit :
>> >> System: Intel-based macOS
>> >>
>> >> I make extensive use of UTF-8 characters in the filenames of my
>> >> Lilypond files.  This works in Lilypond up through version 2.22.
>> >> But Lilypond 2.23 cannot handle UTF-8 characters in filenames.
>> >>
>> >> Filename: tést.ly
>> >> 
>> >> \version "2.22"
>> >>
>> >> { c' }
>> >> 
>> >>
>> >> Under v2.22, this file complies without problem.  With 2.23
>> >> (including the just release 2.23.9) I get the following error:
>> >>
>> >> Starting lilypond 2.23.9 [tést.ly]...
>> >> warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
>> >> fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
>> >> Exited with return code 1.
>> >>
>> >> I thought that this problem had already been reported, but I
>> >> can’t find any mention of it now.  So I’m reporting it.
>> >>
>> >> David F.
>> >
>> >
>> > This is actually not an issue with LilyPond, but with Frescobaldi,
>> > when you have "run LilyPond with English messages" enabled in the
>> > Preferences. This problem is known for some time already, but
>> > I didn't see an issue in the Frescobaldi tracker, so I just
>> > opened one:
>> >
>> > https://github.com/frescobaldi/frescobaldi/issues/1438
>> >
>> > The workaround is to uncheck "Run LilyPond with English messages"
>> > in Edit > Preferences > LilyPond Preferences.
>> >
>> > Best,
>> > Jean
>> >
>>
>> No, I get the same error running lilypond from the command line:
>>
>> $ lilypond --png tést.ly
>> GNU LilyPond 2.23.9 (running Guile 2.2)
>> warning: cannot find file: `t??st.ly'
>> fatal error: failed files: "t??st.ly”
>>
>> David F.
>>
>>
>
> Being on Ubuntu 20.04.4 all works fine with 2.23.9 and current master.

"Being on Ubuntu" tells a much less relevant story as

locale

does.  My own is comparatively weird with

LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=POSIX
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

and has few localisation problems.  Other settings, however, may exhibit
more problems under some circumstances.  Particularly non-US settings of
LC_NUMERIC can mess up number formatting (like when generating
PostScript) and localised settings of LC_CTYPE are what tends to mess
with file name recognition and other console communication.

-- 
David Kastrup

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-22 Thread Thomas Morley

Am So., 22. Mai 2022 um 07:36 Uhr schrieb David F. :
>
>
>
> > On May 21, 2022, at 5:01 PM, Jean Abou Samra  wrote:
> >
> > Le 21/05/2022 à 23:20, David F. a écrit :
> >> System: Intel-based macOS
> >>
> >> I make extensive use of UTF-8 characters in the filenames of my Lilypond 
> >> files.  This works in Lilypond up through version 2.22.  But Lilypond 2.23 
> >> cannot handle UTF-8 characters in filenames.
> >>
> >> Filename: tést.ly
> >> 
> >> \version "2.22"
> >>
> >> { c' }
> >> 
> >>
> >> Under v2.22, this file complies without problem.  With 2.23 (including the 
> >> just release 2.23.9) I get the following error:
> >>
> >> Starting lilypond 2.23.9 [tést.ly]...
> >> warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
> >> fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
> >> Exited with return code 1.
> >>
> >> I thought that this problem had already been reported, but I can’t find 
> >> any mention of it now.  So I’m reporting it.
> >>
> >> David F.
> >
> >
> > This is actually not an issue with LilyPond, but with Frescobaldi,
> > when you have "run LilyPond with English messages" enabled in the
> > Preferences. This problem is known for some time already, but
> > I didn't see an issue in the Frescobaldi tracker, so I just
> > opened one:
> >
> > https://github.com/frescobaldi/frescobaldi/issues/1438
> >
> > The workaround is to uncheck "Run LilyPond with English messages"
> > in Edit > Preferences > LilyPond Preferences.
> >
> > Best,
> > Jean
> >
>
> No, I get the same error running lilypond from the command line:
>
> $ lilypond --png tést.ly
> GNU LilyPond 2.23.9 (running Guile 2.2)
> warning: cannot find file: `t??st.ly'
> fatal error: failed files: "t??st.ly”
>
> David F.
>
>

Being on Ubuntu 20.04.4 all works fine with 2.23.9 and current master.

Cheers,
  Harm

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-21 Thread David F .




> On May 21, 2022, at 5:01 PM, Jean Abou Samra  wrote:
> 
> Le 21/05/2022 à 23:20, David F. a écrit :
>> System: Intel-based macOS
>> 
>> I make extensive use of UTF-8 characters in the filenames of my Lilypond 
>> files.  This works in Lilypond up through version 2.22.  But Lilypond 2.23 
>> cannot handle UTF-8 characters in filenames.
>> 
>> Filename: tést.ly
>> 
>> \version "2.22"
>> 
>> { c' }
>> 
>> 
>> Under v2.22, this file complies without problem.  With 2.23 (including the 
>> just release 2.23.9) I get the following error:
>> 
>> Starting lilypond 2.23.9 [tést.ly]...
>> warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
>> fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
>> Exited with return code 1.
>> 
>> I thought that this problem had already been reported, but I can’t find any 
>> mention of it now.  So I’m reporting it.
>> 
>> David F.
> 
> 
> This is actually not an issue with LilyPond, but with Frescobaldi,
> when you have "run LilyPond with English messages" enabled in the
> Preferences. This problem is known for some time already, but
> I didn't see an issue in the Frescobaldi tracker, so I just
> opened one:
> 
> https://github.com/frescobaldi/frescobaldi/issues/1438
> 
> The workaround is to uncheck "Run LilyPond with English messages"
> in Edit > Preferences > LilyPond Preferences.
> 
> Best,
> Jean
> 

No, I get the same error running lilypond from the command line:

$ lilypond --png tést.ly 
GNU LilyPond 2.23.9 (running Guile 2.2)
warning: cannot find file: `t??st.ly'
fatal error: failed files: "t??st.ly”

David F.

Re: UTF-8 characters in filenames with Lilypond 2.23

2022-05-21 Thread Jean Abou Samra


Le 21/05/2022 à 23:20, David F. a écrit :

System: Intel-based macOS

I make extensive use of UTF-8 characters in the filenames of my Lilypond files. 
 This works in Lilypond up through version 2.22.  But Lilypond 2.23 cannot 
handle UTF-8 characters in filenames.

Filename: tést.ly

\version "2.22"

{ c' }


Under v2.22, this file complies without problem.  With 2.23 (including the just 
release 2.23.9) I get the following error:

Starting lilypond 2.23.9 [tést.ly]...
warning: cannot find file: `/Users/david/Projects/Lily Scratch/te??st.ly'
fatal error: failed files: "/Users/david/Projects/Lily Scratch/te??st.ly"
Exited with return code 1.

I thought that this problem had already been reported, but I can’t find any 
mention of it now.  So I’m reporting it.

David F.



This is actually not an issue with LilyPond, but with Frescobaldi,
when you have "run LilyPond with English messages" enabled in the
Preferences. This problem is known for some time already, but
I didn't see an issue in the Frescobaldi tracker, so I just
opened one:

https://github.com/frescobaldi/frescobaldi/issues/1438

The workaround is to uncheck "Run LilyPond with English messages"
in Edit > Preferences > LilyPond Preferences.

Best,
Jean

Re: UTF-8 unicode use in \markup

2021-11-29 Thread ming tsang

Thank you very much. Helpful information.

Sent from my iPhone

> On Nov 28, 2021, at 7:39 PM, Valentin Petzel  wrote:
> 
> Just for clarification:
> 
> 00a7 is not a special code, but a hexadecimal number. Basically any unicode 
> char is linked with a number, and the „code” is just this number in 
> hexadecimal digits.
> 
> U+ is just a way to specify that a hexadecimal number stands for a 
> unicode 
> char. In our case that function is taken by char. #xSOMETHING is just a guile 
> way of entering numbers as hexadecimal. So instead of ##x00a7 you can also do 
> ##xa7 as well as simply 167 (which is the decimal numeric value for hex A7).
> 
> Thus char basically takes a number and gives us that unicode character.
> 
> Cheers,
> Valentin
> 
> Am Montag, 29. November 2021, 01:27:37 CET schrieb ming tsang:
>> Hi Valentin Petzel,
>> Thank you for your reply.  I found a
>> UTF-8 encoding table and Unicode characters
>> https://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=0x
>> Now I can look up the U+00a7 and then use \markup { \char ##x00a7 ) to
>> display it.
>> for \char I cannot use unicode  U+00a7. I was hoping \char could accept
>> U+00a7.  Now I can use ##x00a7.
>> Thank you for your info.
>> Shalom,
>> yMing.
>> 
>>> On Sun, Nov 28, 2021 at 5:16 PM Valentin Petzel  wrote:
>>> Hello Ming,
>>> 
>>> I do not understand your exact problem. If you want to have € in markup
>>> you
>>> can either directly put € in the markup, or use \char ##20ac.
>>> 
>>> Valentin
>>> 
>>> Am Sonntag, 28. November 2021, 22:42:47 CET schrieb ming tsang:
 Hi lilyponder,
 
 I would like to use \markup to display  € using  U+20AC. I can use
>>> 
>>> \markup
>>> 
 { \char  ##x2197 } to  display / print / output to pdf.  ##x2197 is
 [image: image.png]
 
 Your help is appreciated.
 
 Shalom,
 yMing

Re: UTF-8 unicode use in \markup

2021-11-28 Thread Valentin Petzel

Just for clarification:

00a7 is not a special code, but a hexadecimal number. Basically any unicode 
char is linked with a number, and the „code” is just this number in 
hexadecimal digits.

U+ is just a way to specify that a hexadecimal number stands for a unicode 
char. In our case that function is taken by char. #xSOMETHING is just a guile 
way of entering numbers as hexadecimal. So instead of ##x00a7 you can also do 
##xa7 as well as simply 167 (which is the decimal numeric value for hex A7).

Thus char basically takes a number and gives us that unicode character.

Cheers,
Valentin

Am Montag, 29. November 2021, 01:27:37 CET schrieb ming tsang:
> Hi Valentin Petzel,
> Thank you for your reply.  I found a
> UTF-8 encoding table and Unicode characters
> https://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=0x
> Now I can look up the U+00a7 and then use \markup { \char ##x00a7 ) to
> display it.
> for \char I cannot use unicode  U+00a7. I was hoping \char could accept
> U+00a7.  Now I can use ##x00a7.
> Thank you for your info.
> Shalom,
> yMing.
> 
> On Sun, Nov 28, 2021 at 5:16 PM Valentin Petzel  wrote:
> > Hello Ming,
> > 
> > I do not understand your exact problem. If you want to have € in markup
> > you
> > can either directly put € in the markup, or use \char ##20ac.
> > 
> > Valentin
> > 
> > Am Sonntag, 28. November 2021, 22:42:47 CET schrieb ming tsang:
> > > Hi lilyponder,
> > > 
> > > I would like to use \markup to display  € using  U+20AC. I can use
> > 
> > \markup
> > 
> > > { \char  ##x2197 } to  display / print / output to pdf.  ##x2197 is
> > > [image: image.png]
> > > 
> > > Your help is appreciated.
> > > 
> > > Shalom,
> > > yMing

signature.asc
Description: This is a digitally signed message part.

Re: UTF-8 unicode use in \markup

2021-11-28 Thread ming tsang

Hi Valentin Petzel,
Thank you for your reply.  I found a
UTF-8 encoding table and Unicode characters
https://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=0x
Now I can look up the U+00a7 and then use \markup { \char ##x00a7 ) to
display it.
for \char I cannot use unicode  U+00a7. I was hoping \char could accept
U+00a7.  Now I can use ##x00a7.
Thank you for your info.
Shalom,
yMing.

On Sun, Nov 28, 2021 at 5:16 PM Valentin Petzel  wrote:

> Hello Ming,
>
> I do not understand your exact problem. If you want to have € in markup
> you
> can either directly put € in the markup, or use \char ##20ac.
>
> Valentin
>
> Am Sonntag, 28. November 2021, 22:42:47 CET schrieb ming tsang:
> > Hi lilyponder,
> >
> > I would like to use \markup to display  € using  U+20AC. I can use
> \markup
> > { \char  ##x2197 } to  display / print / output to pdf.  ##x2197 is
> > [image: image.png]
> >
> > Your help is appreciated.
> >
> > Shalom,
> > yMing

-- 
ming (lyndon) tsang

Re: UTF-8 unicode use in \markup

2021-11-28 Thread Valentin Petzel

Hello Ming,

I do not understand your exact problem. If you want to have € in markup you 
can either directly put € in the markup, or use \char ##20ac.

Valentin

Am Sonntag, 28. November 2021, 22:42:47 CET schrieb ming tsang:
> Hi lilyponder,
> 
> I would like to use \markup to display  € using  U+20AC. I can use \markup
> { \char  ##x2197 } to  display / print / output to pdf.  ##x2197 is
> [image: image.png]
> 
> Your help is appreciated.
> 
> Shalom,
> yMing

signature.asc
Description: This is a digitally signed message part.

Re: utf-8 file name in lilypond

2019-01-30 Thread Hans Åberg


> On 30 Jan 2019, at 20:27, David Wright  wrote:
> 
> On Wed 30 Jan 2019 at 16:42:22 (+), MING TSANG wrote:
>> http://lsr.di.unimi.it/LSR/Snippet?id=197
>> 
>> I copy the above snippet and name it test_file-name_info.ly and run with 
>> fracobaldi3.01 + lilypond2.19.82 it produces desired file infomation.
>> Then I rename the file as test_中文.ly (UTF-8 Chinese characters) and execute 
>> and the following error occurs:
>> Starting lilypond-windows.exe 2.19.82 [test_中文.ly]...
>> warning: cannot find file: `C:/Users/yming/Documents/test_??.ly'
>> 
>> fatal error: failed files: "C:/Users/yming/Documents/test_??.ly"
>> 
>> Exited with return code 1.
>> 
>> Question: Window 10 support UTF-8 file name and lilypond does not. Is there 
>> any work around?
> 
> That snippet puts the filename into the score, doesn't it?
> Have you ever had this working or is this effectively a repeat of
> http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00325.html

FYI, on MacOS, the error is as below: Guile makes a translation error. If the 
second CJK character is deleted from the filename, then it compiles without 
this error.


--
$ lilypond 'test_中文.ly'
GNU LilyPond 2.19.82
Processing `test_中文.ly'
Parsing...
test_中文.ly:10:2: error: GUILE signaled an error for the expression beginning 
here
#
 (define siz  (object->string (stat:size (stat filen
No such file or directory: "test_中?\\x87.ly"
test_中文.ly:14:2: error: GUILE signaled an error for the expression beginning 
here
#
 (define modt (stat:mtime (stat filen)))
No such file or directory: "test_中?\\x87.ly"
test_中文.ly:15:2: error: GUILE signaled an error for the expression beginning 
here
#
…
--



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: utf-8 file name in lilypond

2019-01-30 Thread David Wright

On Wed 30 Jan 2019 at 16:42:22 (+), MING TSANG wrote:
> http://lsr.di.unimi.it/LSR/Snippet?id=197
> 
> I copy the above snippet and name it test_file-name_info.ly and run with 
> fracobaldi3.01 + lilypond2.19.82 it produces desired file infomation.
> Then I rename the file as test_中文.ly (UTF-8 Chinese characters) and execute 
> and the following error occurs:
> Starting lilypond-windows.exe 2.19.82 [test_中文.ly]...
> warning: cannot find file: `C:/Users/yming/Documents/test_??.ly'
> 
> fatal error: failed files: "C:/Users/yming/Documents/test_??.ly"
> 
> Exited with return code 1.
> 
> Question: Window 10 support UTF-8 file name and lilypond does not. Is there 
> any work around?

That snippet puts the filename into the score, doesn't it?
Have you ever had this working or is this effectively a repeat of
http://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00325.html

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8-aware backwards string searching in Guile, or: fixing centered lyrics ignoring punctuation

2018-10-31 Thread Alexander Kobel


Gosh,

once again I'm flabbergasted about the expertise and helpfulness of the 
folks on this list. Thanks a ton!


As far as I can tell, your corrected version works like a charm (and 
even fixed a minor misalignment of the "à" syllable that I did not spot 
earlier). And IIUC, the only drawback of the quick'n'dirty variant is 
that it does not actually do a canonicalization of the strings involved, 
so that two different representations of a glyph (e.g., using different 
combining characters) will not match. But this is extremely unlikely 
given that they should be usually entered by the same user in the same 
way, and that the set of characters to compare with is fairly limited 
and probably even has a unique encoding anyway.

So, problem solved for me.

I can only hope that you did not spend the 4.75 hours between your mails 
for the "quick fix"...



Cheers,
Alex


On 31/10/2018 05.23, Aaron Hill wrote:

On 2018-10-30 4:56 pm, Aaron Hill wrote:

On 2018-10-30 10:01 am, Alexander Kobel wrote:

Does anyone have a hint how to approach this one? (Or is the answer
just: be patient and hope for Guile v2?)


The only hint here is to replace the built-in functions with ones
which understand UTF8 encoding and can perform the work needed.  There
very well might be someone online who has already done this work,
which would save on having to do it yourself.

Otherwise, the basic strategy is to replace string->list with a
version that decodes UTF8 and returns a list of integers (essentially
UTF32).  Then, all of the string work is being done with these lists
of integers instead.  (The character set would also just be a set of
integers representing the unique Unicode code points.)  After you find
the subsets of the list that are interesting to measure, you'll then
need to convert the list back into a string.  This means encoding back
into UTF8 and emitting a string.


Here's a quick-n-dirty patch to address the issue.


\version "2.19.82"
\include "center-lyrics-ignoring-punctuation.ily"
{ d'4 4 4 }
\addlyrics { Å Ɓ† «Ḉ…» }


-- Aaron Hill

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user





smime.p7s
Description: S/MIME Cryptographic Signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8-aware backwards string searching in Guile, or: fixing centered lyrics ignoring punctuation

2018-10-30 Thread Aaron Hill


On 2018-10-30 9:23 pm, Aaron Hill wrote:

Here's a quick-n-dirty patch to address the issue.


\version "2.19.82"
\include "center-lyrics-ignoring-punctuation.ily"
{ d'4 4 4 }
\addlyrics { Å Ɓ† «Ḉ…» }



Agh, I goofed.  I forgot the logic is that you want to trim the "space" 
characters from the ends only.  Anything included within the "word" is 
okay.


So with two drop-whiles and reverses, here's the patch to my patch, 
including a new test document:



\version "2.19.82"
\include "center-lyrics-ignoring-punctuation.ily"
{ d'4 4 4 4 }
\addlyrics { Å Ɓ† «Ḉ…» ?Ḓ—Ḛ }


-- Aaron Hill\version "2.19.50"  %% and higher

%% https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00382.html
%% http://lsr.di.unimi.it/LSR/Item?id=888

%% Including UTF8 workaround - see the following...
%% http://lists.gnu.org/archive/html/lilypond-user/2018-10/msg00468.html

#(define (utf8->utf32 lst)
  "Converts a list of UTF8-encoded characters into UTF32."
  (if (null? lst) '()
(let ((ch (char->integer (car lst
  (cond
;; Characters 0x00-0x7F
((< ch #b1000) (cons ch (utf8->utf32 (cdr lst
;; Characters 0x80-0x7FF
((eqv? (logand ch #b1110) #b1100)
  (cons (let ((ch2 (char->integer (cadr lst
  (logior (ash (logand ch #b1) 6)
  (logand ch2 #b11)))
(utf8->utf32 (cddr lst
;; Characters 0x800-0x
((eqv? (logand ch #b) #b1110)
  (cons (let ((ch2 (char->integer (cadr lst)))
  (ch3 (char->integer (caddr lst
  (logior (ash (logand ch #b) 12)
  (ash (logand ch2 #b11) 6)
  (logand ch3 #b11)))
(utf8->utf32 (cdddr lst
;; Characters 0x1-0x10
((eqv? (logand ch #b1) #b)
  (cons (let ((ch2 (char->integer (cadr lst)))
  (ch3 (char->integer (caddr lst)))
  (ch4 (char->integer (cadddr lst
  (logior (ash (logand ch #b111) 18)
  (ash (logand ch2 #b11) 12)
  (ash (logand ch3 #b11) 6)
  (logand ch4 #b11)))
(utf8->utf32 (cr lst
;; Ignore orphaned continuation characters
((eqv? (logand ch #b1100) #b1000) (utf8->utf32 (cdr lst)))
;; Error on all else
(else (error "Unexpected character:" ch))

#(define (utf32->utf8 lst)
  "Converts a list of UTF32-encoded characters into UTF8."
  (if (null? lst) '()
(let ((ch (car lst)))
  (append (cond
  ;; Characters 0x00-0x7F
  ((< ch #x80) (list (integer->char ch)))
  ;; Characters 0x80-0x7FF
  ((< ch #x800) (list
(integer->char (logior #b1100 (logand (ash ch -6) #b1)))
(integer->char (logior #b1000 (logand ch #b11)
  ;; Characters 0x800-0x
  ((< ch #x1) (list
(integer->char (logior #b1110 (logand (ash ch -12) #b)))
(integer->char (logior #b1000 (logand (ash ch -6) #b11)))
(integer->char (logior #b1000 (logand ch #b11)
  ;; Characters 0x1-0x10
  (else (list
(integer->char (logior #b (logand (ash ch -18) #b111)))
(integer->char (logior #b1000 (logand (ash ch -12) #b11)))
(integer->char (logior #b1000 (logand (ash ch -6) #b11)))
(integer->char (logior #b1000 (logand ch #b11))
(utf32->utf8 (cdr lst))

#(define (string->utf32 s) (utf8->utf32 (string->list s)))
#(define (utf32->string l) (list->string (utf32->utf8 l)))

#(define space-set (string->utf32
  ".?-;,:ââââÂ«Â»â¹âºããããââââââ 
*/()[]{}|<>!`~&â¦â â¡"))
#(define (is-space? x) (member x space-set))

#(define (width grob text)
   (let* ((X-extent
   (ly:stencil-extent (grob-interpret-markup grob text) X)))
 (if (interval-empty? X-extent)
 0
 (cdr X-extent

#(define (remove-suspended-note-heads stem note-heads)
   (let* ((nc (ly:grob-common-refpoint stem (car note-heads) X))
  (stem-coord
   (ly:grob-relative-coordinate stem stem X))
  (half-stem-thick
   (/ (ly:grob-property stem 'thickness) 2))
  (stem-dir (ly:grob-property stem 'direction)))
 (remove
  (lambda (nh)
(if (positive? stem-dir)
(> (ly:grob-relative-coordinate nh nc X)
   stem-coord)
(< (ly:grob-relative-coordinate nh nc X)
   (- stem-coord half-stem-thick
  note-heads)))

#(define (make-center-on-word-callback grob center-on-chords)
   (let* ((text (ly:grob-property-data grob 'text))
  (syllable (markup->string text))
  (utf32 (string->utf32 syllable))
  (preword (utf32->string (take-while is-space?

Re: UTF-8-aware backwards string searching in Guile, or: fixing centered lyrics ignoring punctuation

2018-10-30 Thread Aaron Hill


On 2018-10-30 4:56 pm, Aaron Hill wrote:

On 2018-10-30 10:01 am, Alexander Kobel wrote:

Does anyone have a hint how to approach this one? (Or is the answer
just: be patient and hope for Guile v2?)


The only hint here is to replace the built-in functions with ones
which understand UTF8 encoding and can perform the work needed.  There
very well might be someone online who has already done this work,
which would save on having to do it yourself.

Otherwise, the basic strategy is to replace string->list with a
version that decodes UTF8 and returns a list of integers (essentially
UTF32).  Then, all of the string work is being done with these lists
of integers instead.  (The character set would also just be a set of
integers representing the unique Unicode code points.)  After you find
the subsets of the list that are interesting to measure, you'll then
need to convert the list back into a string.  This means encoding back
into UTF8 and emitting a string.


Here's a quick-n-dirty patch to address the issue.


\version "2.19.82"
\include "center-lyrics-ignoring-punctuation.ily"
{ d'4 4 4 }
\addlyrics { Å Ɓ† «Ḉ…» }


-- Aaron Hill\version "2.19.50"  %% and higher

%% https://lists.gnu.org/archive/html/lilypond-user/2016-12/msg00382.html
%% http://lsr.di.unimi.it/LSR/Item?id=888

%% Including UTF8 workaround - see the following...
%% http://lists.gnu.org/archive/html/lilypond-user/2018-10/msg00468.html

#(define (utf8->utf32 lst)
  "Converts a list of UTF8-encoded characters into UTF32."
  (if (null? lst) '()
(let ((ch (char->integer (car lst
  (cond
;; Characters 0x00-0x7F
((< ch #b1000) (cons ch (utf8->utf32 (cdr lst
;; Characters 0x80-0x7FF
((eqv? (logand ch #b1110) #b1100)
  (cons (let ((ch2 (char->integer (cadr lst
  (logior (ash (logand ch #b1) 6)
  (logand ch2 #b11)))
(utf8->utf32 (cddr lst
;; Characters 0x800-0x
((eqv? (logand ch #b) #b1110)
  (cons (let ((ch2 (char->integer (cadr lst)))
  (ch3 (char->integer (caddr lst
  (logior (ash (logand ch #b) 12)
  (ash (logand ch2 #b11) 6)
  (logand ch3 #b11)))
(utf8->utf32 (cdddr lst
;; Characters 0x1-0x10
((eqv? (logand ch #b1) #b)
  (cons (let ((ch2 (char->integer (cadr lst)))
  (ch3 (char->integer (caddr lst)))
  (ch4 (char->integer (cadddr lst
  (logior (ash (logand ch #b111) 18)
  (ash (logand ch2 #b11) 12)
  (ash (logand ch3 #b11) 6)
  (logand ch4 #b11)))
(utf8->utf32 (cr lst
;; Ignore orphaned continuation characters
((eqv? (logand ch #b1100) #b1000) (utf8->utf32 (cdr lst)))
;; Error on all else
(else (error "Unexpected character:" ch))

#(define (utf32->utf8 lst)
  "Converts a list of UTF32-encoded characters into UTF8."
  (if (null? lst) '()
(let ((ch (car lst)))
  (append (cond
  ;; Characters 0x00-0x7F
  ((< ch #x80) (list (integer->char ch)))
  ;; Characters 0x80-0x7FF
  ((< ch #x800) (list
(integer->char (logior #b1100 (logand (ash ch -6) #b1)))
(integer->char (logior #b1000 (logand ch #b11)
  ;; Characters 0x800-0x
  ((< ch #x1) (list
(integer->char (logior #b1110 (logand (ash ch -12) #b)))
(integer->char (logior #b1000 (logand (ash ch -6) #b11)))
(integer->char (logior #b1000 (logand ch #b11)
  ;; Characters 0x1-0x10
  (else (list
(integer->char (logior #b (logand (ash ch -18) #b111)))
(integer->char (logior #b1000 (logand (ash ch -12) #b11)))
(integer->char (logior #b1000 (logand (ash ch -6) #b11)))
(integer->char (logior #b1000 (logand ch #b11))
(utf32->utf8 (cdr lst))

#(define (string->utf32 s) (utf8->utf32 (string->list s)))
#(define (utf32->string l) (list->string (utf32->utf8 l)))

#(define space-set (string->utf32
  ".?-;,:ââââÂ«Â»â¹âºããããââââââ 
*/()[]{}|<>!`~&â¦â â¡"))
#(define (is-space? x) (member x space-set))

#(define (width grob text)
   (let* ((X-extent
   (ly:stencil-extent (grob-interpret-markup grob text) X)))
 (if (interval-empty? X-extent)
 0
 (cdr X-extent

#(define (remove-suspended-note-heads stem note-heads)
   (let* ((nc (ly:grob-common-refpoint stem (car note-heads) X))
  (stem-coord
   (ly:grob-relative-coordinate stem stem X))
  (half-stem-thick
   (/ (ly:grob-property stem 'thickness) 2))
  (stem-dir

Re: UTF-8-aware backwards string searching in Guile, or: fixing centered lyrics ignoring punctuation

2018-10-30 Thread Aaron Hill


On 2018-10-30 10:01 am, Alexander Kobel wrote:

This makes me wonder whether the problem is in the backwards
string-search in string-skip-right or in the substring routine used in
the make-center-on-word-callback; the only reason I can imagine why
this pops up is that some blind-to-Unicode slicing cuts some string in
the middle of a multi-byte Unicode character.


It's a little of both.

Near as I can tell, proper Unicode support was only added in Guile 2.0.  
So 1.8 only thinks of characters as 8-bit values.  While a UTF8-encoded 
string can be represented, none of the built-in character- or 
string-handling routines in 1.8 understand that encoding directly.


For instance, the code you posted contains a mistake in defining the 
character set for punctuation symbols.  string->list will convert a 
string into individual characters, but remember that 1.8 doesn't 
understand anything beyond ASCII.  As such, the following string:


.?-;,:„“‚‘«»‹›『』「」“”‘’–— */()[]{}|<>!`~&…†‡

gets converted into the following list:

(#\. #\? #\- #\; #\, #\: #\342 #\200 #\236 #\342 #\200 #\234
 #\342 #\200 #\232 #\342 #\200 #\230 #\302 #\253 #\302 #\273
 #\342 #\200 #\271 #\342 #\200 #\272 #\343 #\200 #\216 #\343
 #\200 #\217 #\343 #\200 #\214 #\343 #\200 #\215 #\342 #\200
 #\234 #\342 #\200 #\235 #\342 #\200 #\230 #\342 #\200 #\231
 #\342 #\200 #\223 #\342 #\200 #\224 #\space #\* #\/ #\( #\)
 #\[ #\] #\{ #\} #\| #\< #\> #\! #\` #\~ #\& #\342 #\200
 #\246 #\342 #\200 #\240 #\342 #\200 #\241)

The resulting character set is then just the unique individual bytes, 
not the original characters which may have been composed of two or more 
surrogates:


# #\? #\[ #\] #\` #\{ #\| #\} #\~ #\200
   #\214 #\215 #\216 #\217 #\223 #\224 #\230 #\231
   #\232 #\234 #\235 #\236 #\240 #\241 #\246 #\253
   #\271 #\272 #\273 #\302 #\342 #\343}>

The result is something that may at first glance appear to handle 
things, since what is happening is that the logic is stripping away 
individual bytes from the left and right ends of the string.  When you 
have a leading or trailing symbol that was in the list, then its 
individual bytes are stripped properly.  However, if you include a 
character that just so happens to begin with or end with one of these 
bytes, then it will be split improperly.


In your example, "à" is encoded as #\303 #\240.  But take note of #\240 
which is in the character set.  It was included in the set because of 
"†" which is encoded as #\342 #\200 #\240.  If you were to remove "†" 
from the list of symbols, you'd find that the warning will go away, 
because #\240 is no longer being stripped.



Does anyone have a hint how to approach this one? (Or is the answer
just: be patient and hope for Guile v2?)


The only hint here is to replace the built-in functions with ones which 
understand UTF8 encoding and can perform the work needed.  There very 
well might be someone online who has already done this work, which would 
save on having to do it yourself.


Otherwise, the basic strategy is to replace string->list with a version 
that decodes UTF8 and returns a list of integers (essentially UTF32).  
Then, all of the string work is being done with these lists of integers 
instead.  (The character set would also just be a set of integers 
representing the unique Unicode code points.)  After you find the 
subsets of the list that are interesting to measure, you'll then need to 
convert the list back into a string.  This means encoding back into UTF8 
and emitting a string.



-- Aaron Hill

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI Lyrics

2017-02-25 Thread karl

Joseph Austin:
> > From: Karl Hammar  > >
...
> >> But if we are going to use a "private standard", we might as well
> >> imitate the "official" standard and insert something like
> >> FF 05 07 { @ U T F 8 }
> >> And lobby AMEI/MMA to adopt an official UTF8 position.
> > 
> > Could be good, but why just not capitalize on the BOM and just use
> > utf8.
...
> OK, the UTF-8 BOM is 0x EF BB BF
> But given that the MIDI file is not a "text file" but a binary
> file with text fields scattered throughout,
> normally embedded in various MIDI Meta-events, where should the BOM
> be placed?
> 
> Interpreting your suggestion, we could add a Lyric Meta-Event with
> the BOM as the text field to Track 0 Time 0.  
> That should work for lyrics, but RP-26 indicates that lyrics
> "language encoding" should not extend to other types of text events.
> For other text events, it seems we would need to prefix every UTF-8
> text field with the BOM.

Unfortunately midi-file standard and rp26 doesn't help you with that.
The only fallback we have is the notice that you can use extended
charset, but you have to check that programs at the other end of the
pipe does something reasonable with it.

And all this boils down to how do programs out there interpret any
extended char, do they support utf8 BOM, do they support rp26 ?
Well, I don't know.

>From reading rp26, it only talks about latin (latin-1 I assume),
ms-kanji and utf16* (which has the boms "FFFE", "FEFF"), so I don't
think we can expect anything more. Utf16 points to MS-Windows, what
programs makes midi files on that os, how to they do it ?

Soo in the end, I think we should just use utf8 and wait and see if
any bug reports comes in about it.

But as you suggest, we could talk to the midi assosiation to amend
the standard. The easiest would be if they replaced the word "ascii"
with "utf8".

Regards,
/Karl Hammar

---
Asp� Data
Lilla Asp� 148
S-742 94 �sthammar
Sweden
+46 173 140 57



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI Lyrics

2017-02-25 Thread Joseph Austin


> On Feb 25, 2017, at 11:41 AM, lilypond-user-requ...@gnu.org wrote:
> 
> Date: Sat, 25 Feb 2017 17:34:54 +0100 (CET)
> From: Karl Hammar  >
> To: Joseph Austin >
> 
> 
> And,  rp26 clearly states in section 5:
> 
> In addition, if a byte order mark which specifies UNICODE such as
> 'FF FE' or 'FE FF' exists, the character code SET should be treated
>  as UNICODE.
> 
> There is such a "byte order mark" for utf8, see [2]. And then by
> extension, you just have to insert that BOM somewhere in the midi
> file (exists == not restricted to the lyrics meta event, preferable
> in track 0 at time 0) and it would be legal (according to the
> recommendation) to use utf8 straigth out the box.
> 
> [2] http://www.unicode.org/faq/utf_bom.html#BOM 
> 
> 
> 
> 
>> only ASCII chars between 0 and 127 are allowed.
> 
> Your wording is too hard. complete_midi_96-1-3.pdf, p.137 (or [1] 
> p.10) clearly says "should", but 
> 
> "other characters codes
> using the high-order bit may be used for interchange of files between
> different programs on the same computer which supports an extended
> character set. Programs on a computer   which  does not support
> non-ASCII characters should ignore those characters."

I stand corrected.

>> But if we are going to use a "private standard", we might as well
>> imitate the "official" standard and insert something like
>> FF 05 07 { @ U T F 8 }
>> And lobby AMEI/MMA to adopt an official UTF8 position.
> 
> Could be good, but why just not capitalize on the BOM and just use
> utf8.
> 
> Regards,
> /Karl Hammar

OK, the UTF-8 BOM is 0x EF BB BF
But given that the MIDI file is not a "text file" but a binary file with text 
fields scattered throughout,
normally embedded in various MIDI Meta-events, where should the BOM be placed?

Interpreting your suggestion, we could add a Lyric Meta-Event with the BOM as 
the text field to Track 0 Time 0.  
That should work for lyrics, but RP-26 indicates that lyrics "language 
encoding" should not extend to other types of text events.
For other text events, it seems we would need to prefix every UTF-8 text field 
with the BOM.
---
Joe Austin


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI Lyrics

2017-02-25 Thread karl

sorry, last mail wrong from header.

Joe Austen:
> > Am 24.02.2017 um 02:15 schrieb Joseph Austin:
> >> This raises another question.  I'm working with MIDI files,
> >> and it's not clear how to encode UTF-8 text in MIDI.
> >> There must be some convention, but I haven't found an official RP for it.
...
> I don't have a program that displays MIDI  files with lyrics, so I can't test 
> it.

Timidity will show the lyrics.
I have a simple program that dumps the midi as text:

 http://aspodata.se/git/musik/bin/midi.pl

$ midi.pl test.midi  | grep lyric | head
['lyric', 0, 'Sta'],
['lyric', 768, 'bat '],
['lyric', 768, 'Ma'],
['lyric', 768, 'ter '],
['lyric', 384, 'do'],
['lyric', 768, 'lo'],
['lyric', 384, 'ro'],
['lyric', 768, 'sa '],
['lyric', 384, 'sa '],
['lyric', 384, 'jux'],
$

> It appears that, when generating a MIDI file, LilyPond currently
> just puts UTF8 chars in the text fields as if they were ASCII.
> According the base MIDI spec, this is illegal;  only ASCII chars
> between 0 and 127 are allowed.

Your wording is too hard. complete_midi_96-1-3.pdf, p.137 (or [1] 
p.10) clearly says "should", but 

 "other characters codes
 using the high-order bit may be used for interchange of files between
 different programs on the same computer which supports an extended
 character set. Programs on a computer   which  does not support
 non-ASCII characters should ignore those characters."

[1] http://www.cdik.se/pdf/midiformat.pdf

Also, rp17.pdf, last paragraph gives you the set that are "accepted for use"
and that "it is best to avoid the use of these characters: \ [ ] { }".

And,  rp26 clearly states in section 5:
 
 In addition, if a byte order mark which specifies UNICODE such as
 'FF FE' or 'FE FF' exists, the character code SET should be treated
  as UNICODE.

There is such a "byte order mark" for utf8, see [2]. And then by
extension, you just have to insert that BOM somewhere in the midi
file (exists == not restricted to the lyrics meta event, preferable
in track 0 at time 0) and it would be legal (according to the
recommendation) to use utf8 straigth out the box.

[2] http://www.unicode.org/faq/utf_bom.html#BOM

> However, MIDI RP-17 and RP-26 introduce additional encodings for
> the  portion of the lyric meta-event FF 05  .

You do extrapolate a litte, rp17 tells you the "recommended" way to 
specify end of word/line/paragraph, and gives you a list of characters
that should give no compatibility problems.

> In particular, RP-26 specifies the "language" code  {@LATIN} to
> include 8-bit chars > 127.  It seems no code for "UTF8" has been
> officially defined, but a reasonable proposal might be language code:
> {@UTF8}.

You don't need that, see above about BOM. Also it would be interesting
to see which programs that actually support rp26. Since midi "standards"
just are recommendations, you have to know what works in the wild.

..
> So for LilyPond purposes, it would suffice to use a reversible
> encoding, that is, LilyPond would accept any MIDI file text format
> that LilyPond generates.  The apparently existing UTF-8 default
> should work for that.

Lilypond don't read midi files, you can convert midi files to ly files,
which then lilypond can read.

> But if we are going to use a "private standard", we might as well
> imitate the "official" standard and insert something like
> FF 05 07 { @ U T F 8 }
> And lobby AMEI/MMA to adopt an official UTF8 position.

Could be good, but why just not capitalize on the BOM and just use
utf8.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI Lyrics

2017-02-25 Thread Karl Hammar


Joe Austen:
> > Am 24.02.2017 um 02:15 schrieb Joseph Austin:
> >> This raises another question.  I'm working with MIDI files,
> >> and it's not clear how to encode UTF-8 text in MIDI.
> >> There must be some convention, but I haven't found an official RP for it.
...
> I don't have a program that displays MIDI  files with lyrics, so I can't test 
> it.

Timidity will show the lyrics.
I have a simple program that dumps the midi as text:

 http://aspodata.se/git/musik/bin/midi.pl

$ midi.pl test.midi  | grep lyric | head
['lyric', 0, 'Sta'],
['lyric', 768, 'bat '],
['lyric', 768, 'Ma'],
['lyric', 768, 'ter '],
['lyric', 384, 'do'],
['lyric', 768, 'lo'],
['lyric', 384, 'ro'],
['lyric', 768, 'sa '],
['lyric', 384, 'sa '],
['lyric', 384, 'jux'],
$

> It appears that, when generating a MIDI file, LilyPond currently
> just puts UTF8 chars in the text fields as if they were ASCII.
> According the base MIDI spec, this is illegal;  only ASCII chars
> between 0 and 127 are allowed.

Your wording is too hard. complete_midi_96-1-3.pdf, p.137 (or [1] 
p.10) clearly says "should", but 

 "other characters codes
 using the high-order bit may be used for interchange of files between
 different programs on the same computer which supports an extended
 character set. Programs on a computer   which  does not support
 non-ASCII characters should ignore those characters."

[1] http://www.cdik.se/pdf/midiformat.pdf

Also, rp17.pdf, last paragraph gives you the set that are "accepted for use"
and that "it is best to avoid the use of these characters: \ [ ] { }".

And,  rp26 clearly states in section 5:
 
 In addition, if a byte order mark which specifies UNICODE such as
 'FF FE' or 'FE FF' exists, the character code SET should be treated
  as UNICODE.

There is such a "byte order mark" for utf8, see [2]. And then by
extension, you just have to insert that BOM somewhere in the midi
file (exists == not restricted to the lyrics meta event, preferable
in track 0 at time 0) and it would be legal (according to the
recommendation) to use utf8 straigth out the box.

[2] http://www.unicode.org/faq/utf_bom.html#BOM

> However, MIDI RP-17 and RP-26 introduce additional encodings for
> the  portion of the lyric meta-event FF 05  .

You do extrapolate a litte, rp17 tells you the "recommended" way to 
specify end of word/line/paragraph, and gives you a list of characters
that should give no compatibility problems.

> In particular, RP-26 specifies the "language" code  {@LATIN} to
> include 8-bit chars > 127.  It seems no code for "UTF8" has been
> officially defined, but a reasonable proposal might be language code:
> {@UTF8}.

You don't need that, see above about BOM. Also it would be interesting
to see which programs that actually support rp26. Since midi "standards"
just are recommendations, you have to know what works in the wild.

..
> So for LilyPond purposes, it would suffice to use a reversible
> encoding, that is, LilyPond would accept any MIDI file text format
> that LilyPond generates.  The apparently existing UTF-8 default
> should work for that.

Lilypond don't read midi files, you can convert midi files to ly files,
which then lilypond can read.

> But if we are going to use a "private standard", we might as well
> imitate the "official" standard and insert something like
> FF 05 07 { @ U T F 8 }
> And lobby AMEI/MMA to adopt an official UTF8 position.

Could be good, but why just not capitalize on the BOM and just use
utf8.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI Lyrics

2017-02-25 Thread Joseph Austin

> On Feb 24, 2017, at 7:47 AM, lilypond-user-requ...@gnu.org wrote:
> 
> Am 24.02.2017 um 02:15 schrieb Joseph Austin:
>> This raises another question.  I'm working with MIDI files,
>> and it's not clear how to encode UTF-8 text in MIDI.
>> There must be some convention, but I haven't found an official RP for it.
> 
> Personally, I have no idea. Does Lily not do it right?
> Best, Simon

I don't have a program that displays MIDI  files with lyrics, so I can't test 
it.
Both Finale and MuseScore accept LilyPond generated midi files but ignore the 
lyrics.

It appears that, when generating a MIDI file, LilyPond currently just puts UTF8 
chars in the text fields as if they were ASCII.
According the base MIDI spec, this is illegal;  only ASCII chars between 0 and 
127 are allowed.

However, MIDI RP-17 and RP-26 introduce additional encodings for the  
portion of the lyric meta-event FF 05  . In particular, RP-26 
specifies the "language" code  {@LATIN} to include 8-bit chars > 127.  It seems 
no code for "UTF8" has been officially defined, but a reasonable proposal might 
be language code: {@UTF8}.
It's my impression that the largest body of MIDI files with lyrics are 
"Karaoke" files (extension .kar),
which may not be of interest to LilyPond.

I suppose that interest in using MIDI as a "score" language has waned in favor 
of MusicXML.
So for LilyPond purposes, it would suffice to use a reversible encoding, that 
is, LilyPond would accept any MIDI file text format that LilyPond generates.  
The apparently existing UTF-8 default should work for that.
But if we are going to use a "private standard", we might as well imitate the 
"official" standard and insert something like
FF 05 07 { @ U T F 8 }
And lobby AMEI/MMA to adopt an official UTF8 position.

Joe Austin

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI lyrics

2017-02-24 Thread karl

Simon Albrecht:
> Am 24.02.2017 um 02:15 schrieb Joseph Austin:
> > This raises another question.  I'm working with MIDI files,
> > and it's not clear how to encode UTF-8 text in MIDI.
> > There must be some convention, but I haven't found an official RP for it.


http://www.cdik.se/pdf/midiformat.pdf

 [...] Text events may also
 occur at other times in a track, to be used as lyrics, or descriptions
 of cue points. The text in this event should be printable ASCII
 characters for maximum interchange. However, other characters codes
 using the high-order bit may be used for interchange of files between
 different programs on the same computer which supports an extended
 character set. Programs on a computerwhich   does not support
 non-ASCII characters should ignore those characters.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 in MIDI lyrics

2017-02-24 Thread Simon Albrecht


Am 24.02.2017 um 02:15 schrieb Joseph Austin:

This raises another question.  I'm working with MIDI files,
and it's not clear how to encode UTF-8 text in MIDI.
There must be some convention, but I haven't found an official RP for it.


Personally, I have no idea. Does Lily not do it right?
Best, Simon

P.S. If you can, please don’t top-post, but reply below the quotation 
(as I now did). That makes it far easier to catch up with to what you 
were replying.



On Feb 23, 2017, at 4:36 PM, Simon Albrecht  wrote:

Am 23.02.2017 um 01:57 schrieb David Wright:

But why not do the Right Thing and dispose of this problem with
\addlyrics { “I am so lone- ly” said she }
and have yourself a proper set of 66 and 99 quotation marks
without needing to enclose them in quotes.

+1
Simon



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 chars in included filenames on Windows 10 revisited

2017-01-15 Thread David Wright

Reposted as Saturday night's email failed to post here and Sunday
morning's did. (Their Bccs have both crossed the Atlantic in a
timely manner.)

On Sat 14 Jan 2017 at 11:17:17 (+0100), Michael Gerdau wrote:

> it appears UTF-8 character in filenames on Windows seems to be a
> recurring theme.

I didn't know windows used UTF-8 at all in file names.
I was under the impression that it used UTF-16, though
I've no idea which endedness.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 chars in included filenames on Windows 10 revisited

2017-01-15 Thread David Wright

On Sat 14 Jan 2017 at 11:17:17 (+0100), Michael Gerdau wrote:

> it appears UTF-8 character in filenames on Windows seems to be a
> recurring theme.

I didn't know windows used UTF-8 at all in file names.
I was under the impression that it used UTF-16, though
I've no idea which endedness.

Cheers,
David.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: + utf-8 characters on file name

2014-03-19 Thread Wilbert Berendsen

Excuse me for top-quoing, my phone forces me. 

LilyPond intentionally changes non-alphanumeric characters to the underscore 
for the output-suffix. It doesn't do that for \bookOutputName, however. 

I recently got bitten by this too and changed Frescobaldi so that it recognizes 
the changed characters when looking for LilyPond-generated output files.


-- 
Wilbert Berendsen (www.wilbertberendsen.nl)

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: + utf-8 characters on file name

2014-03-19 Thread MING TSANG






On Wednesday, March 19, 2014 3:36:42 AM, Wilbert Berendsen wbs...@xs4all.nl 
wrote:
 
Excuse me for top-quoing, my phone forces me. 

LilyPond intentionally changes non-alphanumeric characters to the underscore 
for the output-suffix. It doesn't do that for \bookOutputName, however. 

I recently got bitten by this too and changed Frescobaldi so that it recognizes 
the changed characters when looking for LilyPond-generated output files.


-- 
Wilbert Berendsen (www.wilbertberendsen.nl)

Wilbert:
Thank you for the info. Is this problem solvable?
\version 2.19.3

\book {
\markup {This does generates a pdf file with +}
\bookOutputName test_utf-8_filename(3)+男中+
{d' d' }
}

After running the avoe .ly file the log below shows the correct .pdf file name 
created, but when browse by a file manager the .pdf display garbage. Please 
refer to screen print - the red text. Some log file entry display the right 
file name and some does not. Where is log file produced?

Starting lilypond-windows.exe 2.19.3 [test_utf-8_filename(男中).ly]...
Processing 
`C:/Users/Tsang/Dropbox/sample_lily-code/test_utf-8_filename().ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test_utf-8_filename(3)+男中+.ps'...
Converting to `./test_utf-8_filename(3)+男中+.pdf'...
Success: compilation successfully completed
Completed successfully in 1.2.attachment: 2014-03-19_141355.png___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: + utf-8 characters on file name

2014-03-18 Thread MING TSANG






On Tuesday, March 18, 2014 12:58:13 PM, MING TSANG tsan...@rogers.com wrote:
 
The attached .ly file generate two pdf files.  
1. test_utf-8_filename.pdf 
2. test_uft-8_filename-SA_TB.pdf

I was anticipating that the 2nd pdf file name to be 
test_utf-8_filename-SA+TB.pdf  Instead it generates 
test_utf-8_filename-SA_TB.pdf. 

Is it that lilypond cannot generate utf-8 character in the file name?
Any work around?
Emmanuel,
Ming 
Additional info:
I change the bookOutSuffix to utf-8 character 男女 and I got the following 
error:
Starting lilypond-windows.exe 2.19.3 [test_utf-8_filename.ly]...
Processing `C:/Users/Tsang/Dropbox/sample_lily-code/test_utf-8_filename.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing 
systems...C:/Users/Tsang/Dropbox/LilyPond/usr/share/lilypond/current/scm/framework-ps.scm:450:22:
 In procedure open-file in expression (open-file filename wb):
C:/Users/Tsang/Dropbox/LilyPond/usr/share/lilypond/current/scm/framework-ps.scm:450:22:
 Invalid argument: test_utf-8_filename-�__�_�.ps
Exited with return code 1.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: + utf-8 characters on file name

2014-03-18 Thread Fredrik Wallberg

Hi Ming,

someone with more knowledge about Unicode (and Windows) could perhaps
explain why that happens, but since you also asked for a workaround:

Instead of using \bookOutSuffix, you could try with \bookOutputName, like this:

\book {
\bookOutputName +中国曲子+

Which works fine over here (version 2.18, Mac OSX 10.8.4).

/ Fredrik

On 18 March 2014 18:16, MING TSANG tsan...@rogers.com wrote:

On Tuesday, March 18, 2014 12:58:13 PM, MING TSANG tsan...@rogers.com
wrote:
The attached .ly file generate two pdf files.
1. test_utf-8_filename.pdf
2. test_uft-8_filename-SA_TB.pdf

I was anticipating that the 2nd pdf file name to be
test_utf-8_filename-SA+TB.pdf Instead it generates
test_utf-8_filename-SA_TB.pdf.

Is it that lilypond cannot generate utf-8 character in the file name?
Any work around?
Emmanuel,
Ming

Additional info:
I change the bookOutSuffix to utf-8 character 男女 and I got the following
error:
Starting lilypond-windows.exe 2.19.3 [test_utf-8_filename.ly]...
Processing `C:/Users/Tsang/Dropbox/sample_lily-code/test_utf-8_filename.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing
systems...C:/Users/Tsang/Dropbox/LilyPond/usr/share/lilypond/current/scm/framework-ps.scm:450:22:
In procedure open-file in expression (open-file filename wb):
C:/Users/Tsang/Dropbox/LilyPond/usr/share/lilypond/current/scm/framework-ps.scm:450:22:
Invalid argument: test_utf-8_filename-�__�_�.ps
Exited with return code 1.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: + utf-8 characters on file name

2014-03-18 Thread Simon Albrecht



Am 18.03.2014 21:05, schrieb Fredrik Wallberg:

Hi Ming,

someone with more knowledge about Unicode (and Windows) could perhaps
explain why that happens, but since you also asked for a workaround:

Instead of using \bookOutSuffix, you could try with \bookOutputName, like this:

\book {
   \bookOutputName +中国曲子+

Which works fine over here (version 2.18, Mac OSX 10.8.4).
However, especially encoding issues are likely to depend on the 
operating system.

/ Fredrik


And Ming, please note that it is compulsory on bug-lilypond and strongly 
advised also on lilypond-user that you use Minimal examples 
http://lilypond.org/website/tiny-examples.html. It often makes 
understanding the problem and testing solutions much easier. So in the 
current case, the file could have been as short as


\version 2.19.3
\bookOutputSuffix SA+TB
{ c' }

, which by the way shows the same behavior on linux.

Best regards,
Simon
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: + utf-8 characters on file name

2014-03-18 Thread MING TSANG






On Tuesday, March 18, 2014 5:58:51 PM, Simon Albrecht simon.albre...@mail.de 
wrote:
 


Am 18.03.2014 21:05, schrieb Fredrik Wallberg:

Hi Ming, someone with more knowledge about Unicode (and Windows) could perhaps
explain why that happens, but since you also asked for a workaround: Instead of 
using \bookOutSuffix, you could try with \bookOutputName, like this: \book { 
\bookOutputName +中国曲子+ Which works fine over here (version 2.18, Mac OSX 
10.8.4).
However, especially encoding issues are likely to depend on the operating 
system.

/ Fredrik
And Ming, please note that it is compulsory on bug-lilypond and
strongly advised also on lilypond-user that you use Minimal examples. It 
often makes understanding the problem and testing solutions much easier. So in 
the current case, the file could have been as short as

\version 2.19.3
\bookOutputSuffix SA+TB

{ c' }

, which by the way shows the same behavior on linux.

Best regards,
Simon


Simon:
Thank you for your simple code to demonstrate my problem.  Is this a bug in 
lily? If it is how to submit to bug report?

Fredrik:

Thank you suggesting using \bookOutputName, I see on the log file indicating 
.ps file is converted to pdf, but I cannot find it 

Here is the revise lily code:
\version 2.19.3
%(1 ...)
\markup { This generate default pdf file with file name} 
{ c' d ' e' f' }
\book {
\markup { This generate pdf file with SA_TB instead of SA+TB }
\bookOutputSuffix SA+TB
{ c' }
}
%(2 ...)
\book {
\markup {This does not generates a pdf file}
\bookOutputName ab+中国曲子+
{d' d' }
}
%(3 .)
\book {
\markup {this generate error}
\bookOutputSuffix 男+女
{ e' e' e' e' }
}

And the log file:
' e' e' e' }

}
And here is the log file:
Starting lilypond-windows.exe 2.19.3 [test_utf-8_filename.ly]...
Processing `C:/Users/Tsang/Dropbox/sample_lily-code/test_utf-8_filename.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test_utf-8_filename-SA_TB.ps'...
Converting to `./test_utf-8_filename-SA_TB.pdf'...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `ab+中国曲子+.ps'...
Converting to `./ab+中国曲子+.pdf'...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing 
systems...C:/Users/Tsang/Dropbox/LilyPond/usr/share/lilypond/current/scm/framework-ps.scm:450:22:
 In procedure open-file in expression (open-file filename wb):
C:/Users/Tsang/Dropbox/LilyPond/usr/share/lilypond/current/scm/framework-ps.scm:450:22:
 Invalid argument: test_utf-8_filename-�___�_�.ps
Exited with return code 1.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: UTF-8 character - inverted quotation marks

2011-02-10 Thread James Lowe

Ralph,

From: lilypond-user-bounces+james.lowe=datacore@gnu.org 
[mailto:lilypond-user-bounces+james.lowe=datacore@gnu.org] On Behalf Of 
Ralph Palmer
Sent: 10 February 2011 12:02
To: lilypond-user Mailinglist
Subject: UTF-8 character - inverted quotation marks

Greetings -

I'm transcribing some Bartok for my personal use. Apparently, Hungarian uses 
inverted opening quotation marks, like ,,Title. I cannot find inverted double 
quotation marks in the UTF-8 character sets online. Can anyone tell me the code 
for inverted quotation marks?

http://en.wikipedia.org/wiki/Quotation_mark_glyphs

This says:

Low double curved quote, left

DOUBLE LOW-9 QUOTATION MARK

201E (8222)

But I looked this number up and either this Wikipedia article is wrong or I am 
not looking in the right list ☺

My reference was http://www.utf8-chartable.de/

I hope this helps in some way.

James
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 character - inverted quotation marks

2011-02-10 Thread Ben Finney

Ralph Palmer palmer.r.vio...@gmail.com writes:

 I'm transcribing some Bartok for my personal use. Apparently, Hungarian uses
 inverted opening quotation marks, like ,,Title. I cannot find inverted
 double quotation marks in the UTF-8 character sets online.

For these purposes I use the GNOME Character Set application. A search
for “quot” let me cycle through until I found the one you're asking for.

 Can anyone tell me the code for inverted quotation marks?

„ U+201E DOUBLE LOW-9 QUOTATION MARK

-- 
 \ “Dare to be naïve.” —Richard Buckminster Fuller, personal motto |
  `\   |
_o__)  |
Ben Finney


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 character - inverted quotation marks

2011-02-10 Thread Werner LEMBERG

 DOUBLE LOW-9 QUOTATION MARK
 
 201E (8222)

This number is correct.  The two quotation characters as used in
Germany are „ (U+201E) and “ (U+201C).

In X, on my GNU/Linux box, I get those characters by pressing

  Multi_Key quotedbl comma

and

  Multi_key quotedbl less

respectively.  However, I don't know where Multi_key, the compose
key, is mapped to by default.


Werner
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 character - inverted quotation marks

2011-02-10 Thread Susan Dittmar


Quoting Ralph Palmer (palmer.r.vio...@gmail.com):
 I'm transcribing some Bartok for my personal use. Apparently, Hungarian uses
 inverted opening quotation marks, like ,,Title. I cannot find inverted
 double quotation marks in the UTF-8 character sets online. Can anyone tell
 me the code for inverted quotation marks?

I do not know Hungarian, but maybe you are looking for U+201E (DOUBLE LOW-9
QUOTATION MARK)?

If not, I can recommend \url{http://www.unicode.org/ucd/} for a search. If
I remember correctly, it's in German, but the important information should
be usable nonetheless, especially as the naming for the glyphs stays in
english.

Hope tht helps,

Susan

___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: UTF-8 character - inverted quotation marks

2011-02-10 Thread Bertalan Fodor (LilyPondTool)

The two quotation marks used in Hungarian are „ and ” U+201E and U+201D, to
begin and end.

Bert

On Thu, Feb 10, 2011 at 1:40 PM, Werner LEMBERG w...@gnu.org wrote:

  DOUBLE LOW-9 QUOTATION MARK
 
  201E (8222)

 This number is correct.  The two quotation characters as used in
 Germany are „ (U+201E) and “ (U+201C).

 In X, on my GNU/Linux box, I get those characters by pressing

  Multi_Key quotedbl comma

 and

  Multi_key quotedbl less

 respectively.  However, I don't know where Multi_key, the compose
 key, is mapped to by default.


Werner

 ___
 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

72 matches

Mail list logo