Re: Inputting special symbols

[Gilles]

[The list moderator rejected a previous post with this message;
so I had to remove the "pdf" attachment.  Hopefully someone will
be kind enough to try and compile the attached lily file, and tell
me whether he gets the same result as I.]

> >
> >Wouldn't it be more logical to do that by default, instead of having
> >to call a function explicitely to remove something (space) which wasn't
> >there in the first place?
> > 
> >
> 
> The current behaviour is certainly logical and intuitive. Your proposal 
> would
> imply that a markup such as
> \markup{\bold Allegro molto }
> would appear as Allegromolto! 

I would write the above as

  \markup{\bold "Allegro molto" }

as this is what is really intended (2 words separated by a space).
The fact that lilypond allows "bare" (unquoted) strings *is* the
syntactic sugar.
[The possibility of leaving out 2 quote characters, at the expense
of having to implement a \concatenate function, is not a gain.]

> Of course you are right that there should be
> a way to concatenate markups. Some programming languages, like Java,
> use a plus-sign or some other character to denote string concatenation,
> sym + \eaigu + trique, but as Han-Wen would say, that's syntactic sugar.
> 
> In this particular case, it seems like a much better solution to use a 
> text editor
> that handles UTF-8, but that's of course another discussion.
> 

In the case of "symétrique", I fully agree (the example was provided by
someone else), but another case is presented in the attached file.
Referring to the "subtitle" header field, in the (commented out) first
case, I have the "added space" problem after the opening and before the
closing parenthesis.
While in the second case, lilypond seems to be confused by the mixing
of right-to-left (parentheses) and left-to-right (Hebrew) characters,
so that the text line is "scrambled" (see attached "pdf" [1]).
[The "ly" file was edited with "gedit".]

What would you suggest in this case?

Thanks,
Gilles


[1] Hopefully you will be able to "see" the Hebrew characters; I don't,
    neither in "gv" nor in "xpdf", but they appear when the page is
    printed on a PostScript printer.  Does this confirm a bug in "gs"
    (latest on Debian is version 8.15)?

test4.ly
Description: Text document