Re: Unicode code points

2020-02-26 Thread Torsten Hämmerle
Freeman Gilmore wrote
> That is interesting, it is in the Private Use Area of Unicode, same area
> as
> Bravura.

Yup. In Emmentaler, there is one big exception I forgot to mention (but this
has nothing to do with accidentals):

The dynamic characters (f, m, p, etc.) are part of Emmentaler's text
encoding and can be found in their "proper" places (just as ordinary text)
so that you can use them directly by typing something like
  \markup { \dynamic sms }

The other glyphs are considered non-standard and therefore, all of them have
been stowed away into the Private Use Area, just one after the other. Mostly
encoding vector after encoding vector, sorted in alphabetical order (by
glyph name) or, more precisely, just as they are generated in
metafont/metapost:
  rests, accidentals, dots, arrowheads, scripts, trills, clefs, etc., etc.

Every time a new glyph joins the party, they all get shifted around from
release to release.
The accidentals in 2.20 will have moved compared to 2.18.2, because new rest
symbols (256th, 512th, 1024th rests!) have been shoved in in front of the
accidentals.  This way, the sharp glyph will have moved from U+E110 to
U+E113.  And that's just one out of many examples.

Cheers,
Torsten














--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html



Re: change postscript output size

2020-02-26 Thread Pierre Perol-Schneider
Hi Ming

Le mer. 26 févr. 2020 à 22:30, MING TSANG  a écrit :

> Pierre:
> Thank you for the \scale option,  but the text part did not scale. refer
> to below:
>

 Yes it does... Have you ckek the last line?


> On Wednesday, February 26, 2020, 03:43:02 p.m. EST, Pierre Perol-Schneider
>  wrote:
>
[...]

> \markup\scale #'(1 . 5)\ymt
>

Try:

\version "2.19.84"

ymt = \markup {
  \note #"16" #1
  " yMt"
  %\scale #'(.5 . .5)
  \postscript #"0.075 setlinewidth 0 -2.5 moveto -13.75 10 -10 -7 2.5 5
rcurveto stroke"
}

\markup\ymt
\markup\scale #'(.5 . .5)\ymt

Cheers,
Pierre


Question about collisions on multiple voices

2020-02-26 Thread Paolo Prete
Hello,

given two voices, for example:

\new Staff <<
  \new Voice = "first"
{ \voiceOne c'8[ c'^> c' c']}
  \new Voice= "second"
{ \voiceTwo \stemUp c''8[ c'' c'' c''] }
>>


... is it possible to make the script " ^>"  avoid collisions on the other
voice too?

Thanks!


Re: Unicode code points

2020-02-26 Thread Freeman Gilmore
On Wed, Feb 26, 2020 at 6:09 PM Torsten Hämmerle 
wrote:

> As far as I know, some special implementations are using SMuFL fonts, most
> notably Dorico's Bravura.  These implementations will definitely use
> explicit code points.
>
> But LilyPond's makam.ly is making use of Emmentaler (Feta) glyphs, and, as
> David pointed out, may change their code points each time a new glyphs is
> inserted somewhere.
>
> As Emmentaler is constantly growing, you'll probably find the accidentals
> in
> a different place depending on the LilyPond release you're using.
> For that reason, directly specifying code points is quite a bad idea and
> that's why you'll have to use glyph names (like
> accidentals.sharp.slashslashslash.stem).
>
> If you still need to know the specific Emmentaler code points regardless of
> this, you can have a look into the Emmentaler-20.otf font file (using
> *FontForge*, for instance).

That is interesting, it is in the Private Use Area of Unicode, same area as
Bravura.

> All the accidental glyphs available can be
> found in LilyPond's Notation Reference Manual, Appendix "A.8 The Emmentaler
> font", section  "Accidental glyphs"
> <
> http://lilypond.org/doc/v2.19/Documentation/notation/the-emmentaler-font.html#accidental-glyphs>
>
> .
>
> HTH,
> Torsten
>
>
>
> --
> Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
>
>


Re: LilyPond 2.19.84 installer on MacOS 10.15 (Hans Åberg)

2020-02-26 Thread Arle Lommel
Hans,

Thank you for providing this. It works great, except for one bug I found. It 
seems that when it’s installed it expects the file system to be using ISO Latin 
1 rather than UTF-8.  When I ran it on file names with non-ASCII characters in 
UTF-8, it returned fatal errors like this:

Warnung: »(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-dAutoRotatePages=/None -dPrinted=false 
-sOutputFile=Bartók-Béla-Székely-friss.pdf -c.setpdfwrite 
-f/var/folders/64/hl6gpmy17994gn1w87__6yvcgn/T//lilypond-JSXs35)« 
gescheitert (256)

schwerer Fehler: gescheiterte Dateien: "/Users/fenevad/Dropbox/music 
scores/bartok/Barto�\x81k-Be�\x81la-Sze�\x81kely-friss.ly"
Exited with return code 1.

If I change the name of the file to use ASCII only, it works properly.

Hope that it helps you to know about this bug.

-Arle


> On Feb 20, 2020, at 15:27, lilypond-user-requ...@gnu.org wrote:
> 
> Message: 3
> Date: Thu, 20 Feb 2020 20:47:42 +0100
> From: Hans Åberg mailto:haber...@telia.com>>
> To: LilyPond User mailto:lilypond-user@gnu.org>>
> Subject: LilyPond 2.19.84 installer on MacOS 10.15
> Message-ID:  >
> Content-Type: text/plain; charset=us-ascii
> 
> I made a LilyPond 2.19.84 installer for use on MacOS 10.15 from MacPorts 
> lilypond-devel, available on the link below. It installs in /opt/lilypond/, 
> with the program in /opt/lilypond/bin/lilypond.
> 
> If you have already something installed in this directory, it may be prudent 
> to remove it first. This can be done by the command
>  sudo rm -r /opt/lilypond
> 
> https://web2.storegate.com/share/JPhrvtH 
> 
> 



Re: Unicode code points

2020-02-26 Thread Freeman Gilmore
On Wed, Feb 26, 2020 at 6:09 PM Torsten Hämmerle 
wrote:

> As far as I know, some special implementations are using SMuFL fonts, most
> notably Dorico's Bravura.  These implementations will definitely use
> explicit code points.
>
LilyPond converts the names to Unicode, the file can be found in
openLilyLib, smufldata,ily

>
> But LilyPond's makam.ly is making use of Emmentaler (Feta) glyphs, and, as
> David pointed out, may change their code points each time a new glyphs is
> inserted somewhere.
>
> As Emmentaler is constantly growing, you'll probably find the accidentals
> in
> a different place depending on the LilyPond release you're using.
> For that reason, directly specifying code points is quite a bad idea and
> that's why you'll have to use glyph names (like
> accidentals.sharp.slashslashslash.stem).
>
> If you still need to know the specific Emmentaler code points regardless of
> this, you can have a look into the Emmentaler-20.otf font file (using
> *FontForge*, for instance).

This helps i can do that .

> All the accidental glyphs available can be
> found in LilyPond's Notation Reference Manual, Appendix "A.8 The Emmentaler
> font", section  "Accidental glyphs"
> <
> http://lilypond.org/doc/v2.19/Documentation/notation/the-emmentaler-font.html#accidental-glyphs>
>
>
This also.
Thank you, ƒg

> .
>
> HTH,
> Torsten
>
>
>
> --
> Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html
>
>


Re: Unicode code points

2020-02-26 Thread Freeman Gilmore
On Wed, Feb 26, 2020 at 1:46 PM David Kastrup  wrote:

> Freeman Gilmore  writes:
>
> > What is the name of the file that converts the glyph accidental names
> used
> > in the makam.ly to Unicode code points?
>
> I don't think we are working with Unicode code points in our output and
> fonts.  At some point of time it might be interesting to employ the code
> points for input, like mapping \턞 to \clef "violin" or so.
>
Well you think correctly, i have been searching, Looks .From
Contributor's Gide:  LilyPond Contributor's Guide: 13.1 Overview of the
Emmentaler font  In LilyPond, glyphs are accessed by a ‘glyph name’, rather
than by code point. Therefore, the name of a glyph is significant.
Thank you, ƒg


> Or making "턞" an alias to "violin", so that you can write \clef 턞 for
> getting a violin clef.
>
> But font code points are not really Unicode I think.
>
> --
> David Kastrup
>


Re: Unicode code points

2020-02-26 Thread Torsten Hämmerle
As far as I know, some special implementations are using SMuFL fonts, most
notably Dorico's Bravura.  These implementations will definitely use
explicit code points.

But LilyPond's makam.ly is making use of Emmentaler (Feta) glyphs, and, as
David pointed out, may change their code points each time a new glyphs is
inserted somewhere.

As Emmentaler is constantly growing, you'll probably find the accidentals in
a different place depending on the LilyPond release you're using.
For that reason, directly specifying code points is quite a bad idea and
that's why you'll have to use glyph names (like
accidentals.sharp.slashslashslash.stem).

If you still need to know the specific Emmentaler code points regardless of
this, you can have a look into the Emmentaler-20.otf font file (using
*FontForge*, for instance).  All the accidental glyphs available can be
found in LilyPond's Notation Reference Manual, Appendix "A.8 The Emmentaler
font", section  "Accidental glyphs"

 
.

HTH,
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html



Re: change postscript output size

2020-02-26 Thread MING TSANG
 Pierre:Thank you for the \scale option,  but the text part did not scale. 
refer to below:
The note is now outside the fish.
Thank you,Ming
On Wednesday, February 26, 2020, 03:43:02 p.m. EST, Pierre Perol-Schneider 
 wrote:  
 
 Hi Ming,How about \scale?e.g.:\version "2.19.84"

ymt = \markup { 
  \note #"16" #1
  " yMt"
  \scale #'(.5 . .5)
  \postscript #"0.075 setlinewidth 0 -2.5 moveto -13.75 10 -10 -7 2.5 5
    rcurveto stroke"
}

\markup\ymt
\markup\scale #'(1 . 5)\ymt
Cheers,Pierre



Le mer. 26 févr. 2020 à 20:56, MING TSANG  a écrit :

dear lilyponders,
I have the following postscript code. How can I make it smaller or larger?
ymt = \markup {   \note #"16" #1  " yMt"  \postscript #"0.075 setlinewidth 0 
-2.5 moveto -13.75 10 -10 -7 2.5 5    rcurveto stroke"}
image after lilypond compilation:

Thank you for the help.Ming


  

Re: change postscript output size

2020-02-26 Thread Pierre Perol-Schneider
Hi Ming,
How about \scale?
e.g.:
\version "2.19.84"

ymt = \markup {
  \note #"16" #1
  " yMt"
  \scale #'(.5 . .5)
  \postscript #"0.075 setlinewidth 0 -2.5 moveto -13.75 10 -10 -7 2.5 5
rcurveto stroke"
}

\markup\ymt
\markup\scale #'(1 . 5)\ymt

Cheers,
Pierre



Le mer. 26 févr. 2020 à 20:56, MING TSANG  a écrit :

> dear lilyponders,
>
> I have the following postscript code. How can I make it smaller or larger?
>
> ymt = \markup {
>   \note #"16" #1
>   " yMt"
>   \postscript #"0.075 setlinewidth 0 -2.5 moveto -13.75 10 -10 -7 2.5 5
> rcurveto stroke"
> }
>
> image after lilypond compilation:
>
> [image: Inline image]
>
> Thank you for the help.
> Ming
>
>


change postscript output size

2020-02-26 Thread MING TSANG
dear lilyponders,
I have the following postscript code. How can I make it smaller or larger?
ymt = \markup {   \note #"16" #1  " yMt"  \postscript #"0.075 setlinewidth 0 
-2.5 moveto -13.75 10 -10 -7 2.5 5    rcurveto stroke"}
image after lilypond compilation:

Thank you for the help.Ming



Re: Unicode code points

2020-02-26 Thread David Kastrup
Freeman Gilmore  writes:

> What is the name of the file that converts the glyph accidental names used
> in the makam.ly to Unicode code points?

I don't think we are working with Unicode code points in our output and
fonts.  At some point of time it might be interesting to employ the code
points for input, like mapping \턞 to \clef "violin" or so.

Or making "턞" an alias to "violin", so that you can write \clef 턞 for
getting a violin clef.

But font code points are not really Unicode I think.

-- 
David Kastrup



Unicode code points

2020-02-26 Thread Freeman Gilmore
What is the name of the file that converts the glyph accidental names used
in the makam.ly to Unicode code points?
Thank you, ƒg


Specifying a font directly via a path?

2020-02-26 Thread Павел Буданов
How can I specify a font directly via a path?
For example, I want something like this to work:
\override LyricText.font-name = "./fonts/MyFont.otf"


Re: Unmerged accidentals

2020-02-26 Thread Leo Correia de Verdier
Thanks!

While not what I was expecting, it works well for me. (I was expecting them to 
have been merged into a single grob, not to be printed on top of eachother). If 
anyone was curious about it, my rather more aggressive hack was:
%
\version "2.19.84"
 {  <\tweak Accidental.alteration #1/2 fih' fis'> }
%

> 25 feb. 2020 kl. 16:25 skrev Pierre Perol-Schneider 
> :
> 
> Hi Leo,
> Since I don't know how you made it, here's what I'd do:
> 
> \version "2.19.84"
> {   }
> %% or
> {   }
> 
> So also a hack.
> Cheers, 
> Pierre
> 
> Le mar. 25 févr. 2020 à 14:46, Leo Correia de Verdier 
>  a écrit :
> Dear list!
> 
> Is there a neat way to achieve two (unmerged) accidentals of the same type in 
> front of an unison? I can produce the attached output by means of some 
> hacking, but am wondering if there is a way of preventing them being merged 
> in the first place.
> 
> 
> 
> Thanks!
> 
> /Leo