On 2010-02-04, Jacob Rundall wrote:
> Thanks. I searched both the client and the server to see if any
> font cache files were being created elsewhere and this doesn't seem
> to be the case. I do have the following the client's system.log
> file however:
>
> Feb 2 11:26:29 camil15 kernel[0]: enc
Comment #3 on issue 819 by hgonzalez: TabVoice confused with ChordNames
spacing when using an override.
http://code.google.com/p/lilypond/issues/detail?id=819
If this helps: the issue seems to be present from version 2.11.53
(lilypond-2.11.52-1.mingw.exe is the last one that works ok for me)
Updates:
Status: Started
Owner: pnorcks
Comment #4 on issue 968 by pnorcks: SVG backend: implement an
output-preview-framework
http://code.google.com/p/lilypond/issues/detail?id=968
(No comment was entered for this change.)
--
You received this message because you are listed
On Sat, Feb 6, 2010 at 10:59 PM, James Bailey
wrote:
>
> The descriptions for Priority-medium and Priority-Low are a bit vague,
> Priority-Postponed is understandable, if one knows the history of
> development on things like Ancient Notation/MIDI, but understanding the
> difference between these t
Comment #32 on issue 887 by harmathdenes: Non-ASCII characters in textedit
URIs should be percent-encoded
http://code.google.com/p/lilypond/issues/detail?id=887
Sorry, I debugged and found out that it is decoded correctly. Another
component in my
system can't deal with accented path names.
Comment #31 on issue 887 by pnorcks: Non-ASCII characters in textedit URIs
should be percent-encoded
http://code.google.com/p/lilypond/issues/detail?id=887
I'm not really sure, but with the code you posted in comment 6, would the
resulting
string change if you do
byte[] uriDecodedBytes =
\version "2.13.11"
%{
Breathing sign collides with flat,
also in 2.12.2
(Interestingly, a sharp does not collide.)
%}
{ d'' \breathe fes'' }
best regards,
Wilbert Berendsen
--
Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/
Nederlands LilyPond forum: http://www.lilypo
Comment #30 on issue 887 by harmathdenes: Non-ASCII characters in textedit
URIs should be percent-encoded
http://code.google.com/p/lilypond/issues/detail?id=887
Okay, then it's definitely the fault of OS X. And maybe Java's: if both are
valid
representations, why can't it decode the former
Comment #29 on issue 887 by pnorcks: Non-ASCII characters in textedit URIs
should be percent-encoded
http://code.google.com/p/lilypond/issues/detail?id=887
By the way, on my GNU/Linux system, I'm seeing
á/á.ly -> %c3%a1/%c3%a1.ly
by default.
--
You received this message because you are l
Comment #28 on issue 887 by pnorcks: Non-ASCII characters in textedit URIs
should be percent-encoded
http://code.google.com/p/lilypond/issues/detail?id=887
They *could* be encoded in the same way, but since "a%cc%81" and "%c3%a1"
are both
valid ways of representing "á" in UTF-8, everything
Comment #27 on issue 887 by harmathdenes: Non-ASCII characters in textedit
URIs should be percent-encoded
http://code.google.com/p/lilypond/issues/detail?id=887
Thanks for the fix! Now non-Latin-2 characters work correctly, e.g.
a/ő.ly -> a/%c5%91.ly
But non-ASCII characters in the path are s
11 matches
Mail list logo