LGTM
https://codereview.appspot.com/325860043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/321350043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely#newcode1037
Documentation/changes.tely:1037:
It would be nice to have an example of a feature that
Thanks for the additions. LGTM.
https://codereview.appspot.com/328140043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
By mere inspection: LGTM
https://codereview.appspot.com/324140043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This is really great! Do you happen know what the current limitations
are? Or
rather, having the full feature list is great, but if only a few
features are
actually recognized by the underlying typography engine (it's still
Pango,
right?), that would probably be a better list to show, unless
If Pango really is agnostic of the features, that is really exciting
and a bit
mysterious ;-).
Why? It's not Pango but HarfBuzz that processes (i.e., applies) the
OpenType features to a run of glyphs.
Perhaps a note should be added, though, to mention that if the
user requests a feature tha
I'm not aware of such an online tool. I've posted a question on
Typedrawers.
http://typedrawers.com/discussion/2292/list-of-opentype-font-feature-inspection-tools
At least for the command line I got the right information! Given that
many people already have TeXLive installed, the `otfinfo' p
If I'm not mistaken, you don't need to specify the script/language.
That's part of the OpenType feature itself. In other words, if the
feature is requested for a glyph outside the scripts/languages that
the feature was specified for, the feature is not applied. Is that
correct, Werner?
No, it'
I looked into the latest Harfbuzz internals, and it looks like
the list of supported OpenType features is manually maintained.
Nope.
Not all the features listed on the Microsoft feature registry
are supported, but many are.
HarfBuzz is agnostic to most features; if you select a feature, and
I very much appreciate your insight and correction. So, there's no
reason to provide or point to a separate list other than the
Microsoft registry?
Well, there is. As told before, the registry contains many, many
features not relevant for Joe User. It would be beneficial if the most
important
lgtm
https://codereview.appspot.com/321440043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Should I use the red 4-line-staff for the rest
of the examples or just for the Gregorian clefs?
Red four-line staves should be probably used for Gregorian only.
However, I'm not an expert, so maybe others have a more educated
opinion.
Two other problems.
* For Hufnagel clefs you should also us
Could you provide an image?
https://codereview.appspot.com/40043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM!
https://codereview.appspot.com/40043/diff/40001/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):
https://codereview.appspot.com/40043/diff/40001/lily/multi-measure-rest.cc#newcode298
lily/multi-measure-rest.cc:298: int dl = min(0 ,
calc_closest_duration_log (me,
LGTM! However, for my taste, the space between the left and the right
leg of `n' is a bit large; maybe you can reduce it by, say, 10% to make
the whole glyph a bit narrower?
https://codereview.appspot.com/339090043/
___
lilypond-devel mailing list
lil
https://codereview.appspot.com/339090043/diff/80001/ps/encodingdefs.ps
File ps/encodingdefs.ps (right):
https://codereview.appspot.com/339090043/diff/80001/ps/encodingdefs.ps#newcode721
ps/encodingdefs.ps:721: /.notdef /.notdef /.notdef /.notdef /.notdef
Yes, the encoding vector should contain e
LGTM.
BTW, I plan to still mentor the two projects that I was already assigned
to.
https://codereview.appspot.com/338320043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
BTW, I plan to still mentor the two projects that I was already
assigned to.
Aah, with `attic' you mean moving down the page, right? Then please
unearth my two projects, i.e., move them up again :-)
https://codereview.appspot.com/338320043/
___
lily
> Yes, the encoding vector should contain exactly 256 elements.
This isn’t the case in other vectors too, I’ll fix that with
the next patch set.
My answer was a little white lie – actually, the encoding vector can be
of any size, AFAIK, but only up the first 256 elements are taken.
However, i
LGTM!
https://codereview.appspot.com/339090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/337400043/diff/20001/scm/translation-functions.scm
File scm/translation-functions.scm (right):
https://codereview.appspot.com/337400043/diff/20001/scm/translation-functions.scm#newcode86
scm/translation-functions.scm:86: (define-public (format-mark-generic
alphabet
> What about using a list of keys instead of the last five arguments,
where
> non-presence means `false'? Something like
>
> (define-public format-mark-circle-barnumbers
> (format-mark-generic '(barnumbers circle bold uppercase))
Good idea though I would prefer two arguments: the first is
\set Score.markFormatter = \format-mark-generic
alphabet,circle,repeat,mixedcase
Whatever :-) Note that the advantage of a parameter list is that the
arguments don't need to be ordered. I guess that with a variadic
function you can do the same.
https://codereview.appspot.com/337400043/
___
LGTM, thanks!
https://codereview.appspot.com/337400043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/337520043/diff/1/input/regression/departure-mark-instrumental.ly
File input/regression/departure-mark-instrumental.ly (right):
https://codereview.appspot.com/337520043/diff/1/input/regression/departure-mark-instrumental.ly#newcode4
input/regression/departure-mark-i
Very nice idea!
On the other hand, \goTo seems unlikely to resemble whatever
we settle on for the grob name… unless everyone likes GoToScript.
What about \jumpTo? Note that I like \goTo also, and I don't mind if
the low-level stuff uses `depart' in its name.
https://codereview.appspot.com/3
\location or \place, with LocationMark or PlaceMark to match?
\location sounds excellent.
https://codereview.appspot.com/337520043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, with a single question.
https://codereview.appspot.com/335520043/diff/1/configure.ac
File configure.ac (right):
https://codereview.appspot.com/335520043/diff/1/configure.ac#newcode66
configure.ac:66: AC_MSG_CHECKING([how to replicate source files to build
files])
Any reason why you are us
LGTM!
https://codereview.appspot.com/337560043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks!
https://codereview.appspot.com/336590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lgtm
https://codereview.appspot.com/337650043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Just for completeness: LGTM :-)
https://codereview.appspot.com/342740043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Very nice! LGTM.
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
https://codereview.appspot.com/340660043/diff/1/mf/feta-scripts.mf#newcode757
mf/feta-scripts.mf:757: set_char_box (wd# / 2, wd# / 2, ht# / 2 *
height_factor, ht# / 2 * height_f
LGTM, thanks!
https://codereview.appspot.com/341140043/diff/1/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/341140043/diff/1/lily/stencil-integral.cc#newcode410
lily/stencil-integral.cc:410: int quantization = max (0, (int) (rounded
* (x_scale +
LGTM
https://codereview.appspot.com/342060043/diff/1/lily/key-signature-interface.cc
File lily/key-signature-interface.cc (right):
https://codereview.appspot.com/342060043/diff/1/lily/key-signature-interface.cc#newcode114
lily/key-signature-interface.cc:114: padding += (intersection (ht_right,
LGTM, but I share Carl's concerns, in particular the issue with font
names that only differ in case.
https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):
https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(ou
Nice!
https://codereview.appspot.com/343970043/diff/40001/mf/GNUmakefile
File mf/GNUmakefile (right):
https://codereview.appspot.com/343970043/diff/40001/mf/GNUmakefile#newcode183
mf/GNUmakefile:183: echo $(TEXGYRE_DIR)/texgyreschola-regular.otf
YYY
This looks like a debug message, probabl
LGTM, thanks!
Two minor suggestions:
s/intermediate/tmp/, since this is shorter.
Please wrap the extremely long lines in the makefiles for improved
readability.
https://codereview.appspot.com/357760043/
___
lilypond-devel mailing list
lilypond-devel
LGTM, thanks!
https://codereview.appspot.com/355800043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. I suggest that you do such trivial clean-ups directly in the git
repository, not wasting your time with setting up an issue.
https://codereview.appspot.com/347930043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/m
LGTM, thanks!
https://codereview.appspot.com/341450043/diff/1/input/regression/book-change-global-staffsize-abs-fonts.ly
File input/regression/book-change-global-staffsize-abs-fonts.ly (right):
https://codereview.appspot.com/341450043/diff/1/input/regression/book-change-global-staffsize-abs-fon
Reviewers: dak,
Message:
On 2018/11/04 23:11:20, dak wrote:
All three look indeed like typos, but all three look like they will
have
significant effects warranting individual testing and likely a
regtest. So
while that looks bothersome, it might make sense turning this into
three
separate
Reviewers: dak,
Message:
Where/how is that being used? Wouldn't this want documenting?
It's nowhere documented, which pretty nicely describes the state of gub
in total... This feature gets only activated if you configure with
`--enable-relocation` (which you normally won't do).
I will docum
not "else if"?
Fixed, thanks.
https://codereview.appspot.com/345160043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This feature gets only activated if you configure with
`--enable-relocation` (which you normally won't do).
I have to correct myself: The configure option `--enable-relocation` is
dead code that does nothing. LilyPond's `--relocate` command line
option is useless, too: Since 12(!) years, reloca
https://codereview.appspot.com/344120043/diff/1/make/lilypond-book-vars.make
File make/lilypond-book-vars.make (right):
https://codereview.appspot.com/344120043/diff/1/make/lilypond-book-vars.make#newcode43
make/lilypond-book-vars.make:43: ifneq (,($findstring xelatex,($notdir
$(PDFLATEX
Sh
LGTM, with some minor issues. Thanks!
https://codereview.appspot.com/357930043/diff/20001/Documentation/notation/text.itely
File Documentation/notation/text.itely (right):
https://codereview.appspot.com/357930043/diff/20001/Documentation/notation/text.itely#newcode50
Documentation/notation/tex
LGTM, thanks!
https://codereview.appspot.com/353870043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: dak,
Message:
On 2019/02/08 09:42:27, dak wrote:
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc
File lily/relocate.cc (right):
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128
lily/relocate.cc:128: TOPLEVEL_VERSION, package_datadir));
W
Can you give any reason why it _should_ work rather than "I tried"?
flower/include/international.hh:46
https://codereview.appspot.com/347070043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-de
Frankly, my approach would be to throw that function out. It just
obfuscates what will and what will not work and keeps GCC from issuing
warnings when number and uses of %s don't match.
Hmm. Having a C++ version of `_f' is actually quite nice, since
appending `c_str' again and again is a nuisa
https://codereview.appspot.com/353880043/diff/2/lily/main.cc
File lily/main.cc (right):
https://codereview.appspot.com/353880043/diff/2/lily/main.cc#newcode635
lily/main.cc:635: { }; // ignore option for backwards compatibility
On 2019/02/19 12:55:10, dak wrote:
This code is insane. Maybe jus
Where do you see any action taken differently in reaction
to "recognizing" --relocate? This just runs into break;
either way.
Ah, right. My mistake. On the other hand, maybe we should add a
warning that `--relocate' is a deprecated no-op?
https://codereview.appspot.com/353880043/
__
https://codereview.appspot.com/363930043/diff/1/Documentation/GNUmakefile
File Documentation/GNUmakefile (right):
https://codereview.appspot.com/363930043/diff/1/Documentation/GNUmakefile#newcode54
Documentation/GNUmakefile:54: TEXINFO_MANUALS_BUT_WEB = $(filter-out
web,$(TEXINFO_MANUALS))
LGTM
What about "TEXINFO_MANUALS_WITHOUT_WEB"?
IMHO this is much better.
https://codereview.appspot.com/363930043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. However, I'm not completely happy with it. What about making
\fermata (and \fermataMarkup) accept an optional argument that indicates
the type:
\fermata 'short
\fermata 'veryLong
\fermata "arbitrary markup stuff"
https://codereview.appspot.com/344160043/
_
On 2019/02/28 09:21:34, Malte Meyn wrote:
On 2019/02/28 09:15:44, lemzwerg wrote:
> LGTM. However, I'm not completely happy with it. What about making
\fermata
> (and \fermataMarkup) accept an optional argument that indicates the
type:
>
> \fermata 'short
>
[Oops, pressed the wrong button]
The idea of
\fermata 'foo
is its open endedness; you don't have to define a new command for a new
fermata type. I'm a fan of a smaller set of multiplex commands instead
of a larger set of specific macros (which a user could always define by
herself). However
Hm … Would this apply to the already existing script commands
\shortfermata etc.? Then we would need a convert-ly rule.
Good question. I see arguments for both directions, i.e., whether to
stay with the commands, or to remove them.
https://codereview.appspot.com/344160043/
__
LGTM, thanks!
https://codereview.appspot.com/347080043/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):
https://codereview.appspot.com/347080043/diff/1/mf/feta-scripts.mf#newcode122
mf/feta-scripts.mf:122: .. z6{up}
Indentation
https://codereview.appspot.com/347080043/
_
The mf code looks fine, thanks!
https://codereview.appspot.com/341560043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/548590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: Valentin Villenave,
Message:
\addInstrumentDefinition is deprecated; see commit
a7c014b60702e96bbc376892249b495bc10b8662. I've just removed the last
documentation remnants.
Description:
NR: Add many function index entries.
Also clean up some minor typos.
Also add minor documentation
Without testing: LGTM, thanks!
https://codereview.appspot.com/562710043/diff/582610043/input/regression/multi-measure-rest-text.ly
File input/regression/multi-measure-rest-text.ly (right):
https://codereview.appspot.com/562710043/diff/582610043/input/regression/multi-measure-rest-text.ly#newcod
LGTM, thanks!
https://codereview.appspot.com/550650043/diff/548760043/Documentation/notation/percussion.itely
File Documentation/notation/percussion.itely (right):
https://codereview.appspot.com/550650043/diff/548760043/Documentation/notation/percussion.itely#newcode423
Documentation/notation/p
I wonder whether it makes sense to use more camel case for the macro
names, this is, \shortFermata, \longFermata, etc.
https://codereview.appspot.com/344160043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listin
LGTM, thanks. Only cosmetic nits :-)
https://codereview.appspot.com/560670043/diff/550690043/lily/line-spanner.cc
File lily/line-spanner.cc (right):
https://codereview.appspot.com/560670043/diff/550690043/lily/line-spanner.cc#newcode395
lily/line-spanner.cc:395: "Sets the Y-coordinate of the e
I think I'd at least stick with uppercase since it evokes the #X
and 'X-offset and other programmatic use of X inside of LilyPond.
Mhmm, I rather disagree, but it's a really minor nit.
https://codereview.appspot.com/560670043/
___
lilypond-devel mail
https://codereview.appspot.com/560670043/diff/552680043/lily/line-spanner.cc
File lily/line-spanner.cc (right):
https://codereview.appspot.com/560670043/diff/552680043/lily/line-spanner.cc#newcode421
lily/line-spanner.cc:421: " of the line"
Oh, here (and at similar places) you should retain the
LGTM, thanks.
https://codereview.appspot.com/560670043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/560670043/diff/582680043/lily/line-spanner.cc
File lily/line-spanner.cc (right):
https://codereview.appspot.com/560670043/diff/582680043/lily/line-spanner.cc#newcode421
lily/line-spanner.cc:421: " @code{stencil-offset}, expecting a
number-pair, the stencil"
s/numb
LGTM, but some comments. Thanks for working on this!
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
https://codereview.appspot.com/550780043/diff/560710043/Documentation/notation/world.itely#newcode74
LGTM, with only small issues that don't deserve a new upload. Since
Knut doesn't have time I can take care of the patch, fixing the minor
issues.
https://codereview.appspot.com/552770043/diff/574790043/aclocal.m4
File aclocal.m4 (right):
https://codereview.appspot.com/552770043/diff/574790043/
LGTM, thanks, with one minor remaining nit.
https://codereview.appspot.com/550780043/diff/570700043/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
https://codereview.appspot.com/550780043/diff/570700043/Documentation/notation/world.itely#newcode562
Documenta
Indentation problems...
https://codereview.appspot.com/552770043/diff/574800043/aclocal.m4
File aclocal.m4 (right):
https://codereview.appspot.com/552770043/diff/574800043/aclocal.m4#newcode77
aclocal.m4:77: STEPMAKE_ADD_ENTRY($3, $2)
This looks strange, at least here in appspot. It appears as
Are you sure this is my patch set? In the comparison view I see many »
signs, which usually indicate tabs. However, the file I've sent to you
doesn't contain any tabs.
https://codereview.appspot.com/552770043/
___
lilypond-devel mailing list
lilypond-
LGTM, thanks!
https://codereview.appspot.com/568820043/diff/550830043/config.make.in
File config.make.in (right):
https://codereview.appspot.com/568820043/diff/550830043/config.make.in#newcode34
config.make.in:34: CONFIG_LIBS = @LIBS@ @EXTRA_LIBS@ $(GLIB_LIBS)
$(GUILE_LIBS) $(PANGO_FT2_LIBS) $(
Some typographic issues.
https://codereview.appspot.com/560790043/diff/572830043/Documentation/notation/world.itely
File Documentation/notation/world.itely (right):
https://codereview.appspot.com/560790043/diff/572830043/Documentation/notation/world.itely#newcode185
Documentation/notation/world
http://codereview.appspot.com/193077/diff/1001/12
File lily/general-scheme.cc (right):
http://codereview.appspot.com/193077/diff/1001/12#newcode230
lily/general-scheme.cc:230: return ((c >= 0x2D && c <= 0x2F) // hyphen,
full-stop, and forward-slash
Wouldn't it be faster to use an array of `0' an
http://codereview.appspot.com/1817045/diff/1/4
File scm/define-grob-properties.scm (right):
http://codereview.appspot.com/1817045/diff/1/4#newcode1059
scm/define-grob-properties.scm:1059:
Since the properties in this file are sorted alphabetically, this is the
wrong place...
http://codereview.a
LGTM too.
http://codereview.appspot.com/2275042/diff/18001/lily/stencil-scheme.cc
File lily/stencil-scheme.cc (right):
http://codereview.appspot.com/2275042/diff/18001/lily/stencil-scheme.cc#newcode398
lily/stencil-scheme.cc:398: {
Don't say @co...@var{...}} but @var{...}.
http://codereview.ap
http://codereview.appspot.com/2754041/diff/1/lily/general-scheme.cc
File lily/general-scheme.cc (right):
http://codereview.appspot.com/2754041/diff/1/lily/general-scheme.cc#newcode84
lily/general-scheme.cc:84: " If @var{size} is @code{SCM_UNDEFINED}, the
entire file is read."
To be in sync with
http://codereview.appspot.com/2726043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Oops, somehow I've just created an empty comment.
http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly#newcode238
ly/music-functions-init.ly:238: cleffedCueDuring
http://codereview.appspot.com/6351083/diff/1/Documentation/contributor/lsr-work.itexi
File Documentation/contributor/lsr-work.itexi (right):
http://codereview.appspot.com/6351083/diff/1/Documentation/contributor/lsr-work.itexi#newcode209
Documentation/contributor/lsr-work.itexi:209: e.g. 2011-12
LGTM. Thanks a lot!
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly
File Documentation/snippets/simultaneous-headword.ly (right):
http://codereview.appspot.com/6345088/diff/1/Documentation/snippets/simultaneous-headword.ly#newcode16
Documentation/sn
I'm currently in Japan, with bad internet access (and additionally, I
can only use the web interface for writing emails, which I heartily
dislike, since SMTP doesn't work here in the hotel for yet unknown
reasons), so it will take some time until I'm able to test this and
communicate with the lily
http://codereview.appspot.com/6374068/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This looks great! I don't have time right now to test it, but errors
will be quite easily be caught :-) Thanks for fixing this.
http://codereview.appspot.com/6399046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailma
Reviewers: ,
Message:
It would be nice if a Russian speaking person could fix the Cyrillic
index entries. However, since we don't have Cyrillic characters in the
index, this is not an urgent issue (and maybe we never need this).
Description:
Add support for Cyrillic in texinfo.
Please review
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi
File Documentation/cyrillic.itexi (right):
http://codereview.appspot.com/6459081/diff/1/Documentation/cyrillic.itexi#newcode14
Documentation/cyrillic.itexi:14: \gdef\cyrfont{%
I fully agree. However, I'm simply mimicking
Notation, section `Kievan contexts', or `snippets/utf-8.ly'.
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6459081/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
For example, `Cyrillic letter V' currently maps to the `V', and
`Cyrillic letter G' maps to `G'. [All Cyrillic characters start
with prefix `' so that they get sorted after all Latin letters].
But this is certainly not the correct collation order for Russian!
AFAIK, `Cyrillic letter V
LGTM, thanks!
http://codereview.appspot.com/6492045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6503091/diff/1/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (left):
http://codereview.appspot.com/6503091/diff/1/mf/parmesan-clefs.mf#oldcode885
mf/parmesan-clefs.mf:885:
Your code is not correct. I'm sending comparison images to the
lilypond-devel list.
http://
I'm sorry, but I find this incredibly unhelpful. "You've done it
wrong"
is insulting to someone who's spent about 40 hours trying to get it
right.
The original code was wrong, with any number of incorrect assumtions.
If you could point me to what is incorrect, I'll try to fix it. I see
nothi
There isn't any indentation standard for mf files, is there?
It's implicitly given by the formatting of all MF files. I know that
this is far from ideal, but unless someone is stepping forward to write
a specification for GNU indent or something similar so that the
indentation can be enforced m
I was aware of a slight difference, although actually I'm
not certain it's that important - these are machine drawn
glyphs intending to replicate hand-drawn clefs from the
15th century. How important is 0.1 staff space?
This is not the point. Your are changing the shape without documenting
thi
1 - 100 of 722 matches
Mail list logo
