Re: Format of -dshow-available-fonts output

[Federico Bruni]

Il giorno mer 25 lug 2018 alle 8:19, Urs Liska  
ha scritto:





[~]$ /opt/lilypond/usr/bin/fc-list --version
fontconfig version 2.8.0

[~]$ fc-list --version
fontconfig version 2.13.0



I'm not sure this is really relevant. The fact is that the libraries 
are *different*, so there's a difference. In my case the fc-list 
version from inside the LilyPond installation is 2.12.1


What *would* be interesting is to see the output from that "LilyPond 
fc-list", but that fails with "Fontconfig error: Cannot load default 
config file". Any idea how I can get that to run?




Can you find the fonts.conf file in that installation?

I can run the fc-list in these two installations without any problem:

$ find /opt/lilypond* -name fonts.conf
/opt/lilypond-2.16/usr/etc/fonts/fonts.conf
/opt/lilypond-2.18/usr/etc/fonts/fonts.conf

Perhaps you set the path manually?
What do you get from this command:

env | grep FONTCONFIG_PATH




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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 12:41 schrieb Federico Bruni:



What *would* be interesting is to see the output from that "LilyPond 
fc-list", but that fails with "Fontconfig error: Cannot load default 
config file". Any idea how I can get that to run?




Can you find the fonts.conf file in that installation?

I can run the fc-list in these two installations without any problem:

$ find /opt/lilypond* -name fonts.conf
/opt/lilypond-2.16/usr/etc/fonts/fonts.conf
/opt/lilypond-2.18/usr/etc/fonts/fonts.conf

Perhaps you set the path manually?
What do you get from this command:

env | grep FONTCONFIG_PATH



OK, we're getting closer. There is a *substantial* difference in the 
results of fc-list | grep TeX when run from the system fontconfig and 
the one packaged with LilyPond:


$ fc-list | grep TeX
/usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreadventor-bold.otf: TeX 
Gyre Adventor:style=Bold
/usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreadventor-italic.otf: TeX 
Gyre Adventor:style=Italic
/usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreadventor-bolditalic.otf: 
TeX Gyre Adventor:style=Bold Italic
/usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreadventor-regular.otf: 
TeX Gyre Adventor:style=Regular

~/lilypond/usr/bin$ FONTCONFIG_PATH=~/lilypond/usr/etc/fonts ./fc-list | grep 
TeX
/usr/share/fonts/X11/Type1/qagr.pfb: TeXGyreAdventor:style=Regular
/usr/share/fonts/X11/Type1/qagbi.pfb: TeXGyreAdventor:style=BoldItalic
/usr/share/fonts/X11/Type1/qagri.pfb: TeXGyreAdventor:style=Italic
/usr/share/fonts/X11/Type1/qagb.pfb: TeXGyreAdventor:style=Bold

(I've manually deleted all the lines referring to the other TeX Gyre 
families, but the situation is the same.)


I'm becoming more and more confused, thinking that LilyPond finds 
completely other fonts than the system's fontconfig.


What makes me wonder even more is that in a LilyPond file the following 
two are possible (i.e. call the right font):


\override TextScript.font-name = "TeX Gyre Adventor Bold Italic"
\override TextScript.font-name = "TeXGyreAdventor Bold Italic"

but not this:

\override TextScript.font-name = "TeX Gyre Adventor BoldItalic"
\override TextScript.font-name = "TeXGyreAdventor BoldItalic"

So the style *as reported by LilyPond* does not work. OTOH, I can't 
simply write a routing to "un-camel" the style name because in other 
cases "SemiBold" must *not* be separated but taken as-is.


In the verbose log output I only find one of the following references:

[texgyreadventor_bold_italic_3.8662109375]
[tex_gyre_adventor_bold_italic_3.8662109375]

So I don't even know *which* font is actually used.

Finally: how should I try to write code to load and display fonts in 
Frescobaldi under these circumstances? And then by any chance code that 
reliably works on someone else's computer???



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

Re: Format of -dshow-available-fonts output

[Werner LEMBERG]

> OK, we're getting closer. There is a *substantial* difference in the
> results of fc-list | grep TeX when run from the system fontconfig
> and the one packaged with LilyPond:

Have you played with the `FC_CONFIG' environment variable?  Say

  FC_CONFIG=31 fc-list | less

to get a *very* detailed output how fontconfig finds something.  You
might then compare the outputs of the two programs.


Werner

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

Re: Format of -dshow-available-fonts output

[Torsten Hämmerle]

Urs Liska-3 wrote
> What makes me wonder even more is that in a LilyPond file the following 
> two are possible (i.e. call the right font):
> 
> \override TextScript.font-name = "TeX Gyre Adventor Bold Italic"
> \override TextScript.font-name = "TeXGyreAdventor Bold Italic"
> 
> but not this:
> 
> \override TextScript.font-name = "TeX Gyre Adventor BoldItalic"
> \override TextScript.font-name = "TeXGyreAdventor BoldItalic"


Hi Urs,

You could even write
"T EXGY   Read vento R"

The styles, however, have to be separated by space(s) and they also have to
be separated from the font family name.


Urs Liska-3 wrote
> [texgyreadventor_bold_italic_3.8662109375]
> [tex_gyre_adventor_bold_italic_3.8662109375]

These are the keys used for the font buffering hash table built from the
font-name specified and the Pango font size (this is an absolute font size
not depending on the current LilyPond output scale).

Spaces will be transformed into _ and everything will be converted to lower
case. Physically, it's the same font in both cases.

In the extreme example with "T EXGY   Read vento R", the internally used
font key will be:
[t_exgy___read_vento_r_3.8662109375]
When using 12pt instead of the standard 11pt font size, the generated key
name will be:
[t_exgy___read_vento_r_4.2177734375]



Torsten






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

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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 14:21 schrieb Werner LEMBERG:

OK, we're getting closer. There is a *substantial* difference in the
results of fc-list | grep TeX when run from the system fontconfig
and the one packaged with LilyPond:

Have you played with the `FC_CONFIG' environment variable?  Say

   FC_CONFIG=31 fc-list | less

to get a *very* detailed output how fontconfig finds something.  You
might then compare the outputs of the two programs.


Thanks for that hint. This gives indeed more details but actually 
confirms the prior finding:


Debian's fc-list finds (shortened output, and deliberatly choosing the 
Bold Italic case):


Font 98 Pattern has 24 elts (size 24)
family: "TeX Gyre Adventor"(w)
style: "Bold Italic"(w)
fullname: "TeXGyreAdventor-BoldItalic"(w)
file: 
"/usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreadventor-bolditalic.otf"(w)
fontformat: "CFF"(w)
postscriptname: "TeXGyreAdventor-BoldItalic"(w)

LilyPond's fc-list finds

Font 255 Pattern has 19 elts (size 19)
family: "TeXGyreAdventor"(w)
style: "BoldItalic"(w)
file: "/usr/share/fonts/X11/Type1/qagbi.pfb"(w)
fontformat: "Type 1"(w)
postscriptname: "TeXGyreAdventor-BoldItalic"(w)

After the section with the detailed font patterns there is a list with 
concise entries.


There Debian's fc-list finds

/usr/share/texmf/fonts/opentype/public/tex-gyre/texgyreadventor-bolditalic.otf: 
TeX Gyre Adventor:style=Bold Italic

while LilyPond's finds

/usr/share/fonts/X11/Type1/qagbi.pfb: TeXGyreAdventor:style=BoldItalic

So I realize that my problems in Frescobaldi stem from the fact that 
LilyPond finds different fonts than the operating system. But I don't 
really have an idea as to what to make of it.


Currently it looks like my best bet would be to simply split a reported 
style of "BoldItalic" in two words but leave it as it is in other cases 
(e.g. leave SemiBold alone). This really doesn't feel like a sane 
solution ...


Urs


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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 15:04 schrieb Torsten Hämmerle:

Urs Liska-3 wrote

What makes me wonder even more is that in a LilyPond file the following
two are possible (i.e. call the right font):

\override TextScript.font-name = "TeX Gyre Adventor Bold Italic"
\override TextScript.font-name = "TeXGyreAdventor Bold Italic"

but not this:

\override TextScript.font-name = "TeX Gyre Adventor BoldItalic"
\override TextScript.font-name = "TeXGyreAdventor BoldItalic"


Hi Urs,

You could even write
"T EXGY   Read vento R"


OK, I now see, there is also a reference to "ignore spaces" somewhere in 
the verbose log output.




The styles, however, have to be separated by space(s) and they also have to
be separated from the font family name.


Then why is LilyPond (in the output of -dshow-available-fots) reporting 
"BoldItalic" and not "Bold Italic"?





Urs Liska-3 wrote

[texgyreadventor_bold_italic_3.8662109375]
[tex_gyre_adventor_bold_italic_3.8662109375]

These are the keys used for the font buffering hash table built from the
font-name specified and the Pango font size (this is an absolute font size
not depending on the current LilyPond output scale).

Spaces will be transformed into _ and everything will be converted to lower
case. Physically, it's the same font in both cases.

In the extreme example with "T EXGY   Read vento R", the internally used
font key will be:
[t_exgy___read_vento_r_3.8662109375]
When using 12pt instead of the standard 11pt font size, the generated key
name will be:
[t_exgy___read_vento_r_4.2177734375]


Thanks for the explanation.
Urs





Torsten






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

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



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

Re: Format of -dshow-available-fonts output

[Torsten Hämmerle]

Urs Liska-3 wrote
> OK, I now see, there is also a reference to "ignore spaces" somewhere in 
> the verbose log output.

I rather suspect (that's a Pango issue) that the font name specified in
LilyPond is tweaked (ignore case and spaces) in order to find the
corresponding font file and then, font strings are extracted from the font
file (see below).


Urs Liska-3 wrote
> Then why is LilyPond (in the output of -dshow-available-fots) reporting 
> "BoldItalic" and not "Bold Italic"?

The funny thing is: "my" LilyPonds (Linux and Windows) don't report
BoldItalic for TeX Gyre Adventor, but actually Bold Italic.

In other cases, however, LilyPond reports BoldItalic.


When looking into the TFF Names of FontForge, there seems to be a connexion
between string ID "Styles (SubFamily)" and the LilyPond output:

*TeX Gyre Adventor*
Styles (SubFamily): "Bold Italic"
LilyPond reports: TeX Gyre Adventor:style=Bold Italic

 

*Century Schoolbook L*
Styles (SubFamily): BoldItalic
LilyPond reports: Century Schoolbook L:style=BoldItalic

So, LilyPond just reports the "Styles (SubFamily)" string content of the
font file: sometimes, it's "Bold Italic", sometimes it's "BoldItalic".

There may also be a "Preferred Styles" string ID.
In this case (if there they differ from "Styles (SubFamily)"), these strings
will be reported separated by spaces.

If there are Styles strings in more than one language (most of the times,
it's only English (US)), these strings also will be enumerated separated by
comma.

Family and Preferred Family may also be both reported by LilyPond (separated
by comma), as e.g. if a font comes in different weights etc., e.g.

Preferred Family "Bodoni MT", Families "Bodoni MT", "Bodoni MT Black",
"Bodoni MT Condensed", etc.


*All in all:* Could you check your TeX Gyre Adventor FontForge TTF Names
Styles string? Does it say BoldItalic or Bold Italic?
May these irregularities be caused by the font files themselves? 

All the best,
Torsten




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

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

Re: Format of -dshow-available-fonts output

[Werner LEMBERG]

>> Have you played with the `FC_CONFIG' environment variable?  Say
>>
>>FC_CONFIG=31 fc-list | less
>>
>> to get a *very* detailed output how fontconfig finds something.  You
>> might then compare the outputs of the two programs.

Sorry, this must be `FC_DEBUG=31'.

> So I realize that my problems in Frescobaldi stem from the fact that
> LilyPond finds different fonts than the operating system.  But I
> don't really have an idea as to what to make of it.

The above shows the names of the scanned directories also.


Werner

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

\textLengthOn in polyphony and over MultiMeasureRests

[Urs Liska]

Hi,

as a follow-up to my previous thread about text formatting 
(http://lists.gnu.org/archive/html/lilypond-user/2018-07/msg00395.html) 
(of which I'll soon post the results, I hope) I ran into some problems 
handling \textLengthOn.


The following snippet shows two things: \textLengthOn is a global thing 
(markup in voice one will push the music in voice two), and it doesn't 
work over MultiMeasureRests:


%
\version "2.19.82"

{
  \displayMusic \textLengthOn
  \override TextScript.self-alignment-X = #CENTER
  \override TextScript.staff-padding = #3

  c''1 ^\markup "Some longer text"
  \hideNotes
  c''1 ^\markup "Over an 'empty' measure."
  \unHideNotes
  <<
{
  \hideNotes
  c''1 ^\markup "Other voice interferes."
  \unHideNotes
}
\new Voice {
  c'4 c'2.
}
  >>
  \break
  c''1
  R1 ^\markup "It doesn't have any impact on MultiMeasureRests."
  c''
}
%

So I have two questions:

a)
I can see that it is considered too complex to automatically calculate 
\textLengthOn for one voice and have the other voices fill in the 
resulting width. But is there some way to emulate the result? What I 
need is the text filling a certain amount of time (typically a full 
measure) and stretch that amount of time to the text's width while 
another voice has some content in that measure..


b)
Is it possible to apply \textLengthOn over a MultiMeasureRest without 
resorting to a hidden extra voice?


Thanks
Urs


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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 18:35 schrieb Werner LEMBERG:

Have you played with the `FC_CONFIG' environment variable?  Say

FC_CONFIG=31 fc-list | less

to get a *very* detailed output how fontconfig finds something.  You
might then compare the outputs of the two programs.

Sorry, this must be `FC_DEBUG=31'.


Yes, I have found that out (otherwise I wouldn't have come up with any 
results).



So I realize that my problems in Frescobaldi stem from the fact that
LilyPond finds different fonts than the operating system.  But I
don't really have an idea as to what to make of it.

The above shows the names of the scanned directories also.


It seems that LilyPond's fc-list does not search anything below 
/usr/share/texmf, which is (I suppose) where TeX Live has installed 
fonts. OTOH Debian's fc-list *does* search in /usr/share/fonts/X11/Type1 
where LilyPond finds the fonts I'm currently looking at.


Urs




 Werner



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

Re: Format of -dshow-available-fonts output

[Werner LEMBERG]

> It seems that LilyPond's fc-list does not search anything below
> /usr/share/texmf, which is (I suppose) where TeX Live has installed
> fonts. OTOH Debian's fc-list *does* search in
> /usr/share/fonts/X11/Type1 where LilyPond finds the fonts I'm
> currently looking at.

Well, lilypond installs two fontconfig configuration files:

  00-lilypond-fonts.conf
  99-lilypond-fonts.conf

It also adds lilypond's `.../fonts/otf' directory to fontconfig's
search path (I'm too lazy to check whether it gets prepended or
appended).

Maybe this gives you further clues.


Werner

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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 18:50 schrieb Urs Liska:



Am 25.07.2018 um 18:35 schrieb Werner LEMBERG:

Have you played with the `FC_CONFIG' environment variable?  Say

    FC_CONFIG=31 fc-list | less

to get a *very* detailed output how fontconfig finds something.  You
might then compare the outputs of the two programs.

Sorry, this must be `FC_DEBUG=31'.


Yes, I have found that out (otherwise I wouldn't have come up with any 
results).



So I realize that my problems in Frescobaldi stem from the fact that
LilyPond finds different fonts than the operating system.  But I
don't really have an idea as to what to make of it.

The above shows the names of the scanned directories also.


It seems that LilyPond's fc-list does not search anything below 
/usr/share/texmf, which is (I suppose) where TeX Live has installed 
fonts. OTOH Debian's fc-list *does* search in 
/usr/share/fonts/X11/Type1 where LilyPond finds the fonts I'm 
currently looking at.




And for completeness: Obviously I have installed a number of TeX Gyre 
fonts in two locations, the ones in /usr/share/fonts/X11/Type1 are from 
the package tex-gyre while the others are from fonts-texgyre, both of 
which have been added through texlive-full (IISC). So I can't simply say 
I should not have duplicate fonts around ...



Urs




 Werner



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



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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 19:03 schrieb Werner LEMBERG:

It seems that LilyPond's fc-list does not search anything below
/usr/share/texmf, which is (I suppose) where TeX Live has installed
fonts. OTOH Debian's fc-list *does* search in
/usr/share/fonts/X11/Type1 where LilyPond finds the fonts I'm
currently looking at.

Well, lilypond installs two fontconfig configuration files:

   00-lilypond-fonts.conf
   99-lilypond-fonts.conf

It also adds lilypond's `.../fonts/otf' directory to fontconfig's
search path (I'm too lazy to check whether it gets prepended or
appended).

Maybe this gives you further clues.


Unfortunately not.
The two "local" conf files only define a number of match fallback aliases.

I'm not sure at what point the fonts/otf directory of the installation 
is added or used, but I can't see this in the output of LilyPond's 
fc-list nor in the result of -dshow-available-fonts.


I have massaged the output of fc-list to only show the sorted list of 
directories. The resulting list is identical with the font directories 
list produced from lilypond -dshow-available-fonts:


* ~/.fonts (recursively)
* ~/.local/share/fonts
* /usr/local/share/fonts
* /usr/share/fonts (recursively)

The list produced by Debian's fc-list is identical but significantly 
adds a few entries:

* /usr/share/texmf/fonts/opentype/public/lm
* /usr/share/texmf/fonts/opentype/public/lm-math
* /usr/share/texmf/fonts/opentype/public/tex-gyre
* /usr/share/texmf/fonts/opentype/public/tex-gyre-math
* /usr/X11R6/lib/X11/fonts

So this is why Debian's fc-list finds the .otf versions of the TeX Gyre 
family while Lilypond's does not.


Still no clue what to *really* do about it. More and more I think I'll 
end up with a hack that will catch 90% of special cases.





 Werner



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

Re: Format of -dshow-available-fonts output

[Urs Liska]

Am 25.07.2018 um 17:10 schrieb Torsten Hämmerle:

Urs Liska-3 wrote

OK, I now see, there is also a reference to "ignore spaces" somewhere in
the verbose log output.

I rather suspect (that's a Pango issue) that the font name specified in
LilyPond is tweaked (ignore case and spaces) in order to find the
corresponding font file and then, font strings are extracted from the font
file (see below).


Urs Liska-3 wrote

Then why is LilyPond (in the output of -dshow-available-fots) reporting
"BoldItalic" and not "Bold Italic"?

The funny thing is: "my" LilyPonds (Linux and Windows) don't report
BoldItalic for TeX Gyre Adventor, but actually Bold Italic.

In other cases, however, LilyPond reports BoldItalic.


Which is what I had initially observed when people showed their results 
on https://github.com/wbsoft/frescobaldi/pull/1075: different results 
for different people. Originally I had thought it was related to Qt's 
reporting of fonts, but by now I have the suspicion that it's related to 
LilyPond's fontconfig configuration.




When looking into the TFF Names of FontForge, there seems to be a connexion
between string ID "Styles (SubFamily)" and the LilyPond output:

*TeX Gyre Adventor*
Styles (SubFamily): "Bold Italic"
LilyPond reports: TeX Gyre Adventor:style=Bold Italic



*Century Schoolbook L*
Styles (SubFamily): BoldItalic
LilyPond reports: Century Schoolbook L:style=BoldItalic

So, LilyPond just reports the "Styles (SubFamily)" string content of the
font file: sometimes, it's "Bold Italic", sometimes it's "BoldItalic".

There may also be a "Preferred Styles" string ID.
In this case (if there they differ from "Styles (SubFamily)"), these strings
will be reported separated by spaces.

If there are Styles strings in more than one language (most of the times,
it's only English (US)), these strings also will be enumerated separated by
comma.

Family and Preferred Family may also be both reported by LilyPond (separated
by comma), as e.g. if a font comes in different weights etc., e.g.

Preferred Family "Bodoni MT", Families "Bodoni MT", "Bodoni MT Black",
"Bodoni MT Condensed", etc.


*All in all:* Could you check your TeX Gyre Adventor FontForge TTF Names
Styles string? Does it say BoldItalic or Bold Italic?


I've now found out that /usr/share/fonts/X11/Type1/qagbi.pfb actually is 
a link to /usr/share/texmf/fonts/type1/public/tex-gyre/qagbi.pfb,
so while Debian finds the OpenType version and LilyPond the Type1 
version of the font which is installed by the same package.


Opening the Type1 font with FontForge shows the following TTF entries:

 * Family "TeXGyreAdventor"
 * Styles (SubFamily) "BoldItalic"
 * Fullname "TeXGyreAdventor-BoldItalic"

while the TTF entries for the OpenType versions (now expectedly" expose 
the familiar spaces throughout.



May these irregularities be caused by the font files themselves?


It looks like it, and the confusion comes from the fact that LilyPond 
looks for the Type1 fonts and Debian for the OpenType flavour.
And additionally confusing is the fact that *three* of these TeX Gyre 
fonts are additionally installed in LilyPond's own font directory, in 
the OpenType variant.


Therefore this works:
      \override TextScript.font-name = "TeX Gyre Schola"
      \override TextScript.font-features = #'("onum")

but this not:
  \override TextScript.font-name = "TeX Gyre Adventor"
      \override TextScript.font-features = #'("onum")

because for the first case the OpenType font is used from LilyPond's own 
directory (so I assume this is somehow prepended to the search tree) 
while in the second case the system-installed Type1 font is used. This 
is also consistent with the fact that LilyPond reports both TeX Gyre 
Schola and TeXGyreSchola as available fonts, but only TeXGyreAdventor 
and not TeX Gyre Adventor.


The OpenType versions of both fonts that are installed as system fonts 
are never used by LilyPond.


So in the end this seems to boil down to two basic questions:

a)
is it possible or desirable to add the directories below 
/usr/share/texmf/fonts to LilyPond's fontconfig search path (i.e. a 
feature request/bug report)?


b)
how can I deal with the problem that in some cases (in Type1 fonts?) 
LilyPond reports "BoldItalic" but needs itself to use "Bold Italic" to 
access the style?


 * Spliting styles with camel case is not an option because there are
   also SemiBold styles that have to be kept together, and who knows
   which fonts also make use of this "feature"?
 * Treating "BoldItalic" specially seems my best bet so far - but this
   smells already now - just a matter of time until someone finds
   another corner case where either another style name must be
   separated or where "BoldItalic" is actually the intended style name ...

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

Re: \textLengthOn in polyphony and over MultiMeasureRests

[Torsten Hämmerle]

Urs Liska-3 wrote
> (markup in voice one will push the music in voice two)

Yes, but that's only natural: 

(0) \textLengthOn affects any neighbouring objects and will even push away
the surrounding notes etc.

(1) TextScript.self-alignment-X ist set to #CENTER and in combination with
\textLengthOn, the outer limits of the measure will be pushed apart.

(2) If there's only one single note, this note will be forced into the
horizontal centre of the measure (which is what we wanted in the example,
but that's not "natural", as the first note in a measure should start at the
beginning of the measure.

(3) The additional second voice prevents the single note of voice one from
being centred, because now the two voices have to be rhythmically aligned:
that's why the 2nd note of voice 2 sticks out to the right.

So as to your question a), it's not a problem of calculating \textLength,
it's just a problem of rhythmic alignment of notes.
You don't even need a 2nd voice for that effect,
  c''4 ^\markup "Other voice interferes." c''2.
would just behave in the same way.

If you need more than one (centred) note, you can use spacer rests (s) an/or
scaled durations (if needed) and (!) attach the markup text to <>, that way
it won't affect the neighbouring notes other than by widening the measure.
Don't ask me why, but it comes in handy.




Urs Liska-3 wrote
> and it doesn't 
> work over MultiMeasureRests:

In these cases, you can attach it to <>. This even works with compressed
MultiMeasureRests and it's an ordinary TextScript then.

The longa rest in the example below has been created by R1*4 in combination
with \compressFullBarRests and \omit MultiMeasureRestNumber. The markup text
has been attached to <>.
I haven't included the source code because it's a mess and I used a Fraktur
font just for fun.

 

I think this pretty much mimicks the original sample.

All the best,
Torsten




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

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

advice on orchestral parts and string Divisi

[Reggie]

For those of you who engrave orchestral music in which the strings often have
your typical divisi a2 or a3

Suppose a performance is coming up and you need to print parts from the full
score.

So when you go to engrave the individual parts for any of the strings for
example, (say Violin I), would you:

a) always leave the Violin I "as is" and just \new Staff the violin variable
as it appears in the full score regardless of divisi complexity /
independence
--*(Violin I all on one staff for part)
b) only leave the Violin I as is from the full score if it's a simple score
and not that complicated of a separate part
--*(Violin I all on one staff for part, but only if it's not too complex of
a division rhythm-wise and for not that many measures in the score)
c) always input all divisi as separate variables from the beginning and
actually partcombine the divisi of the same instrument, so as to have
multiple staves if need be on the part version.
--*(Violin I from the start of engraving has already been pre-variabled into
2/3 divisi with a ton of spacer rests throughout the whole part until the
sections needed, then input the divisi notes, then go back to normal, etc -
at the end, use partcombine on the part, etc.)

How do you approach printing string parts for a modern orchestral piece,
regarding divisi? Does it depend or is your approach constant?
Most of the music I am engraving has divisi similar to that of the 19th
century, where it's not too separate of a part difference but some upcoming
projects I will be working on have rather diverse divisi spreads within the
same string part.
So I wanted to begin the project 'correctly' before getting too deep in and
realizing I couldn't do parts easily. You can't really [easily] do a
partcombine with just one variable taht has temporary voices on it.

Thanks



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

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

Re: Hairpin.to-barline doesn't always work

[Patrick Karl]

On 7/20/18 11:32 PM, Pierre Perol-Schneider wrote:

Hi Patrick,
Try:

\version "2.19.81"

{
  \time 1/4
  \override Hairpin.to-barline = ##f
  a8\> b
  c'4\!
}
{
  \time 1/4
  a8-\tweak to-barline ##f \> b
  c'4\!
}

Cheers,
Pierre


I appreciate the advice.  Can you explain why a break, whether automatic 
or forced, seems to completely negate the to-barline setting:


\version "2.19.81"

\paper {
    ragged-bottom = ##t
    ragged-right = ##t
}

\relative c'' {
    c1
    \override Hairpin.to-barline = ##f d1\<
    e1\!
}

\relative c'' {
    c1 c c c c c c c c c
    \override Hairpin.to-barline = ##f d1\<
    e1\!
}

\relative c'' {
    c1
    \override Hairpin.to-barline = ##f d1\<
    \break
    e1\!
}

As you can see (I hope), the first example works as expected, but the 
next two examples fail in that the hairpin stops at the barline.  I have 
read the section of the Notation RM dealing with the to-barline property 
of Spanners (5.4.6), and haven't seen an explanation of this behavior.




2018-07-21 5:08 GMT+02:00 Patrick Karl >:



Section 5.4.6 of the Notation RM states:


/The|to-barline|property/

The second useful property of
the|spanner-interface|is|to-barline|. By default this is true,
causing hairpins and other spanners which are terminated on the
first note of a measure to end instead on the immediately
preceding bar line. If set to false, the spanner will extend
beyond the bar line and end on the note itself

I have a couple of questions about this section.  The first is,
why would the default setting for to-barface be true?  If I wanted
my spanner to end on the immediately preceding bar line, I could
easily set "\!" after the last note of the preceding bar.


The second question has to do with the following two examples:

\version "2.19.81"
{  \time 1/4
    a8\> b
    \override Hairpin.to-barline = ##f
    c'4\! }
{  \time 1/4
    a8\> b
    \override Hairpin.to-barline = ##t
    c'4\! }


Both examples give identical output, i.e., the hairpin ends before
the first barline, not extending to the first note of the second
bar no matter what the setting of Hairpin.to-barline is.


How can I extend the hairpin to the end of the note in the 2nd bar?

Please answer both questions.  Why would the default be so
counter-intuitive?


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





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

Re: Hairpin.to-barline doesn't always work

[Pierre Perol-Schneider]

No, I can't but I can give you a workaround:

\version "2.19.81"

\paper {
ragged-bottom = ##t
ragged-right = ##t
}

\relative c'' {
c1
\override Hairpin.to-barline = ##f d1\<
e1\!
}

\relative c'' {
\override Hairpin.to-barline = ##f
c1 c c c c c c c c c
d1-\tweak to-barline ##f -\tweak after-line-breaking ##t \<
e1\!
}

\relative c'' {
c1
\override Hairpin.to-barline = ##f
\override Hairpin.after-line-breaking = ##t
d1\<
\break
e1\!
}

HTH, Cheers,
Pierre

2018-07-26 3:59 GMT+02:00 Patrick Karl :

> On 7/20/18 11:32 PM, Pierre Perol-Schneider wrote:
>
> Hi Patrick,
> Try:
>
> \version "2.19.81"
>
> {
>   \time 1/4
>   \override Hairpin.to-barline = ##f
>   a8\> b
>   c'4\!
> }
> {
>   \time 1/4
>   a8-\tweak to-barline ##f \> b
>   c'4\!
> }
>
> Cheers,
> Pierre
>
>
> I appreciate the advice.  Can you explain why a break, whether automatic
> or forced, seems to completely negate the to-barline setting:
>
> \version "2.19.81"
>
> \paper {
> ragged-bottom = ##t
> ragged-right = ##t
> }
>
> \relative c'' {
> c1
> \override Hairpin.to-barline = ##f d1\<
> e1\!
> }
>
> \relative c'' {
> c1 c c c c c c c c c
> \override Hairpin.to-barline = ##f d1\<
> e1\!
> }
>
> \relative c'' {
> c1
> \override Hairpin.to-barline = ##f d1\<
> \break
> e1\!
> }
>
> As you can see (I hope), the first example works as expected, but the next
> two examples fail in that the hairpin stops at the barline.  I have read
> the section of the Notation RM dealing with the to-barline property of
> Spanners (5.4.6), and haven't seen an explanation of this behavior.
>
>
> 2018-07-21 5:08 GMT+02:00 Patrick Karl :
>
>> Section 5.4.6 of the Notation RM states:
>> *The to-barline property*
>>
>> The second useful property of the spanner-interface is to-barline. By
>> default this is true, causing hairpins and other spanners which are
>> terminated on the first note of a measure to end instead on the immediately
>> preceding bar line. If set to false, the spanner will extend beyond the bar
>> line and end on the note itself
>>
>> I have a couple of questions about this section.  The first is, why would
>> the default setting for to-barface be true?  If I wanted my spanner to end
>> on the immediately preceding bar line, I could easily set "\!" after the
>> last note of the preceding bar.
>>
>>
>> The second question has to do with the following two examples:
>>
>> \version "2.19.81"
>> {  \time 1/4
>> a8\> b
>> \override Hairpin.to-barline = ##f
>> c'4\! }
>> {  \time 1/4
>> a8\> b
>> \override Hairpin.to-barline = ##t
>> c'4\! }
>>
>>
>> Both examples give identical output, i.e., the hairpin ends before the
>> first barline, not extending to the first note of the second bar no matter
>> what the setting of Hairpin.to-barline is.
>>
>>
>> How can I extend the hairpin to the end of the note in the 2nd bar?
>>
>> Please answer both questions.  Why would the default be so
>> counter-intuitive?
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>>
>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Hairpin.to-barline doesn't always work

[Pierre Perol-Schneider]

If that could help for understanding this behaviour, in the regression
tests, hairpin-barline-break.ly says:
"If a hairpin ends on the first note of a new staff, we do not print that
ending. But on the previous line, this hairpin should not be left open, and
should end at the bar line."
This probably comes from a dedicated discussion about an hairpin / break
issue during the years 2010/2011...
Cheers,
Pierre

2018-07-26 7:11 GMT+02:00 Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com>:

> No, I can't but I can give you a workaround:
>
> \version "2.19.81"
>
> \paper {
> ragged-bottom = ##t
> ragged-right = ##t
> }
>
> \relative c'' {
> c1
> \override Hairpin.to-barline = ##f d1\<
> e1\!
> }
>
> \relative c'' {
> \override Hairpin.to-barline = ##f
> c1 c c c c c c c c c
> d1-\tweak to-barline ##f -\tweak after-line-breaking ##t \<
> e1\!
> }
>
> \relative c'' {
> c1
> \override Hairpin.to-barline = ##f
> \override Hairpin.after-line-breaking = ##t
> d1\<
> \break
> e1\!
> }
>
> HTH, Cheers,
> Pierre
>
> 2018-07-26 3:59 GMT+02:00 Patrick Karl :
>
>> On 7/20/18 11:32 PM, Pierre Perol-Schneider wrote:
>>
>> Hi Patrick,
>> Try:
>>
>> \version "2.19.81"
>>
>> {
>>   \time 1/4
>>   \override Hairpin.to-barline = ##f
>>   a8\> b
>>   c'4\!
>> }
>> {
>>   \time 1/4
>>   a8-\tweak to-barline ##f \> b
>>   c'4\!
>> }
>>
>> Cheers,
>> Pierre
>>
>>
>> I appreciate the advice.  Can you explain why a break, whether automatic
>> or forced, seems to completely negate the to-barline setting:
>>
>> \version "2.19.81"
>>
>> \paper {
>> ragged-bottom = ##t
>> ragged-right = ##t
>> }
>>
>> \relative c'' {
>> c1
>> \override Hairpin.to-barline = ##f d1\<
>> e1\!
>> }
>>
>> \relative c'' {
>> c1 c c c c c c c c c
>> \override Hairpin.to-barline = ##f d1\<
>> e1\!
>> }
>>
>> \relative c'' {
>> c1
>> \override Hairpin.to-barline = ##f d1\<
>> \break
>> e1\!
>> }
>>
>> As you can see (I hope), the first example works as expected, but the
>> next two examples fail in that the hairpin stops at the barline.  I have
>> read the section of the Notation RM dealing with the to-barline property of
>> Spanners (5.4.6), and haven't seen an explanation of this behavior.
>>
>>
>> 2018-07-21 5:08 GMT+02:00 Patrick Karl :
>>
>>> Section 5.4.6 of the Notation RM states:
>>> *The to-barline property*
>>>
>>> The second useful property of the spanner-interface is to-barline. By
>>> default this is true, causing hairpins and other spanners which are
>>> terminated on the first note of a measure to end instead on the immediately
>>> preceding bar line. If set to false, the spanner will extend beyond the bar
>>> line and end on the note itself
>>>
>>> I have a couple of questions about this section.  The first is, why
>>> would the default setting for to-barface be true?  If I wanted my spanner
>>> to end on the immediately preceding bar line, I could easily set "\!" after
>>> the last note of the preceding bar.
>>>
>>>
>>> The second question has to do with the following two examples:
>>>
>>> \version "2.19.81"
>>> {  \time 1/4
>>> a8\> b
>>> \override Hairpin.to-barline = ##f
>>> c'4\! }
>>> {  \time 1/4
>>> a8\> b
>>> \override Hairpin.to-barline = ##t
>>> c'4\! }
>>>
>>>
>>> Both examples give identical output, i.e., the hairpin ends before the
>>> first barline, not extending to the first note of the second bar no matter
>>> what the setting of Hairpin.to-barline is.
>>>
>>>
>>> How can I extend the hairpin to the end of the note in the 2nd bar?
>>>
>>> Please answer both questions.  Why would the default be so
>>> counter-intuitive?
>>>
>>> ___
>>> lilypond-user mailing list
>>> lilypond-user@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>>
>>
>>
>
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user