Glyphs for Kievan Notation

Added glyphs for Kievan Notation

Added Kievan glyphs and a basic test file

First step in supporting kievan square notation.
Add generic metafont file, driver files and
file containing code for glyphs.
Modified scripts used in font generation
to include kievan glyphs.

Signed-off-by: Aleksandr Andreev <aleksandr.andreev@gmail.com>

[aleksandr.andreev, 2011-09-05 19:13:49]

Publishing for review Metafont code for support of Kievan square notes plus a
very basic regression file to test the implementation.

[Graham Percival (old account), 2011-09-05 19:17:13]

Good job!  I'm not very familiar with the fetafont stuff, but this looks like
exactly the right thing to do.  :)

[janek, 2011-09-06 08:16:25]

LGTM.
Only some minor style nitpicks; you may also wish to change commit's message
(currently it says that there is only one glyph added).  You can modify commit
messages using 
git rebase -i origin/master

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode27
mf/feta-kievan.mf:27: fet_beginchar("kievan quarter (down)", "d4");
there shold be space between fet_beginchar and ( everywhere in the file

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode53
mf/feta-kievan.mf:53: 
I think there shouldn't be empty line here.

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode78
mf/feta-kievan.mf:78: fill z1{dir -6.9} .. z2 .. z3 & z3 .. z4 .. z5 & z5 -- z6
& z6 .. z7 .. z8 & z8{left} .. z9 & z9 .. z10 ... {dir -76.9}cycle;
please break this line (in general lines shouldn't be wider than 80 characters)

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode99
mf/feta-kievan.mf:99: fill z2 -- z8 -- z7 -- z12 -- z11 -- z6 -- z5 -- z10 -- z9
-- z4 -- z3 -- z1 -- cycle;
as above

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode119
mf/feta-kievan.mf:119: fill z1 -- z2 -- z6 -- z5 -- z9 -- z10 -- z12 -- z11 --
z7 -- z8 -- z4 -- z3 -- z1 -- cycle;
as above, and below the same

[aleksandr.andreev, 2011-09-08 00:52:04]

Cleaned up code style based on comments from janek.

[pkx166h, 2011-09-08 07:09:21]

Added to Tracker:

https://code.google.com/p/lilypond/issues/detail?id=1873

[Carl, 2011-09-08 13:07:46]

Looks very promising. 

A couple of style comments.

I think the naming should be revised to include Kievan as part of the name, at
least for the notes like s1.

Thanks,

Carl

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode28
mf/feta-kievan.mf:28: % this draws the quarter note with the stem down
Is this indented with tabs?  We use tabs in metafont files.

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode78
mf/feta-kievan.mf:78: fill z1{dir -6.9} .. z2 .. z3 & z3 .. z4 .. z5 & z5 -- z6
& z6 .. z7 .. z8 & z8{left} .. z9 & z9 .. z10 ... {dir -76.9}cycle;
I know that Werner left a review somewhere on a font change that showed the
proper way to break lines in a case like this. 

Looking, for example, at feta-noteheads.mf line 636, we see that the proper
format for this command would be

fill z1{dir -6.9} 
     .. z2 
     .. z3 
     & z3 
     .. z4 
     .. z5 
     & z5 
     -- z6 
     & z6 
     .. z7 
     .. z8 & z8{left} 
     .. z9 & z9 
     .. z10 
     ... {dir -76.9}cycle;

I guess we should add something about this to the CG.  I'll do it tonight.

http://codereview.appspot.com/4951062/diff/6001/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/6001/mf/feta-kievan.mf#newcode215
mf/feta-kievan.mf:215: fet_beginchar ("kievan whole note", "s1");
The name should probably not be s1, since that's the name of the standard whole
note glyph.

Look at the parmesan note naming for the kind of names you should probably use
for the kievan glyphs.  Something like s1Keivan.

[lemzwerg, 2011-09-09 06:46:12]

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/1/mf/feta-kievan.mf#newcode78
mf/feta-kievan.mf:78: fill z1{dir -6.9} .. z2 .. z3 & z3 .. z4 .. z5 & z5 -- z6
& z6 .. z7 .. z8 & z8{left} .. z9 & z9 .. z10 ... {dir -76.9}cycle;
> fill z1{dir -6.9} 
>      .. z2 
>      .. z3 
>      & z3 
>      .. z4 
>      .. z5 
>      & z5 
>      -- z6 
>      & z6 
>      .. z7 
>      .. z8 & z8{left} 
>      .. z9 & z9 
>      .. z10 
>      ... {dir -76.9}cycle;

Well, I generally prefer vertical alignment since it makes the code much easier
to read.  However, it shouldn't be a religious thing.  For example, given that
the fill command is quite long and clearly separated into subpaths, the
following looks good also:

  fill z1{dir -6.9} .. z2 .. z3
       & z3 .. z4 .. z5
       & z5 -- z6
       & z6 .. z7 .. z8
       & z8{left} .. z9
       & z9 .. z10... {dir -76.9}cycle;

http://codereview.appspot.com/4951062/diff/6001/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/6001/mf/feta-kievan.mf#newcode32
mf/feta-kievan.mf:32: x1 = 0.09 * staff_space;
I'm not really happy with the MF code: It looks like a direct translation of
PostScript points into MF points.  This definitely works but is quite clumsy. 
If you look at the design of other LilyPond glyphs, you can see that all
coordinates rely on meta-parameters which control the appearance.  For your
glyphs, we have to directly shift coordinates in case of a change, with a great
chance to inadvertently break important relationships within the glyph shape.

I would really like to see a `LilyPond approach' for Kievan notes also, treating
the current approach as a temporary solution.

[aleksandr.andreev, 2011-09-10 00:03:11]

Changed code style and glyph names based on the comments of Carl and lemzwerg.

Carl, is it OK that the group name is kievan, so now we have glyphs like
kievan.s1kievan? Is this how it should be?

Re: "you can see that all coordinates rely on  meta-parameters which control the
appearance"

I'm new to MetaFont, so I'm not sure I know what a meta-parameter is. lemzwerg,
could you or someone else more knowledgeable about MF than me code up one of
these glyphs the LilyPond way as an example? I think if I see it done once
correctly, I'll be able to figure it out.

[lemzwerg, 2011-09-10 10:20:45]

Simply have a look how other note heads are implemented, and watch how the shape
changes for different design sizes.

[Reinhold, 2011-09-10 10:27:43]

Can we please have a more meaningful issue title than "Cleaned up style", which
does not tell me at all what this review is about when I get all those
notifications mails.

[pkx166h, 2011-09-10 12:47:18]

I created

https://code.google.com/p/lilypond/issues/detail?id=1873

and called it

'Added glyphs for Kievan Notation'

so when this issue is changed can we use the same title?

[aleksandr.andreev, 2011-09-10 13:05:37]

On 2011/09/10 12:47:18, J_lowe wrote:
> I created
> 
> https://code.google.com/p/lilypond/issues/detail?id=1873
> 
> and called it
> 
> 'Added glyphs for Kievan Notation'
> 
> so when this issue is changed can we use the same title?

I changed the name of the issue.

[aleksandr.andreev, 2011-09-10 13:09:41]

On 2011/09/10 10:20:45, lemzwerg wrote:
> Simply have a look how other note heads are implemented, and watch how the
shape
> changes for different design sizes.

OK. What is noteheight# equal to and how is that determined?

[pkx166h, 2011-09-10 21:46:17]

passes make and reg tests

[lemzwerg, 2011-09-11 08:18:28]

> OK. What is noteheight# equal to and how is that determined?

A quick grep on the MF files shows that noteheight# is defined in
feta-params.mf.

[janek, 2011-09-14 10:27:50]

Werner,

2011/9/9  <lemzwerg@googlemail.com>:
> I'm not really happy with the MF code: It looks like a direct
> translation of PostScript points into MF points.  This definitely works
> but is quite clumsy.  If you look at the design of other LilyPond
> glyphs, you can see that all coordinates rely on meta-parameters which
> control the appearance.  For your glyphs, we have to directly shift
> coordinates in case of a change, with a great chance to inadvertently
> break important relationships within the glyph shape.
>
> I would really like to see a `LilyPond approach' for Kievan notes also,
> treating the current approach as a temporary solution.

what do you mean by "let's treat this as a temporary solution"?  Do
you mean that:
1) it can be pushed in this state so that Aleksandr can proceed on
getting Kievan notation to work (by adding KievanStaff, KievanVoice
and so on), but when support for Kievan notation is established, the
metafont code should be rewritten to be more LilyPond-esque,
or
2) it cannot be pushed in this state and it must be rewritten before
any other work on Kievan notation could be done,
or something else?

cheers,
Janek

[wl_gnu.org, 2011-09-14 12:06:11]

> what do you mean by "let's treat this as a temporary solution"?  Do
> you mean that: 1) it can be pushed in this state so that Aleksandr
> can proceed on getting Kievan notation to work (by adding
> KievanStaff, KievanVoice and so on), but when support for Kievan
> notation is established, the metafont code should be rewritten to be
> more LilyPond-esque,

This is what I mean.  Sorry for being imprecise.


    Werner

[Neil Puttock, 2011-09-14 19:40:08]

http://codereview.appspot.com/4951062/diff/11001/input/regression/kievan-note...
File input/regression/kievan-notes.ly (right):

http://codereview.appspot.com/4951062/diff/11001/input/regression/kievan-note...
input/regression/kievan-notes.ly:11: \override NoteHead #'stencil =
#ly:text-interface::print
NoteHead doesn't have an interface for 'text, so this regression test will spit
out warnings when compiled (to see run it with -dcheck-internal-types).

The canonical method is to use grob::interpret-markup, but this is still rather
hackish.  It would be preferable to add the infrastructure which switches the
glyphs (if possible, a 'style setting).

[aleksandr.andreev, 2011-09-19 01:20:53]

As per comments by Neil, I removed the reg test file. Also made the necessary
changes to Documentation/included/font-table.ly

Also merged with Parmesan patch by Bertrand and resolved conflict.

[lemzwerg, 2011-09-19 05:02:32]

LGTM

http://codereview.appspot.com/4951062/diff/24001/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/24001/mf/feta-kievan.mf#newcode52
mf/feta-kievan.mf:52: fill z1{dir 8.6} .. z2 .. z3
A minor thing: Please align this vertically (and at similar places also); this
is, the indentation here consists of a tab and some space characters:

   fill z1 .. z2 ..z3
        & z4 .. z5 .. z6
        ...

Maybe you call this weird, but it helps reading the code, at least for me :-)

[aleksandr.andreev, 2011-09-20 02:01:42]

Fixed alignment issue based on comments by lemzwerg.

[janek, 2011-09-20 17:39:23]

Hi Neil,

2011/9/14  <n.puttock@gmail.com>:
>
http://codereview.appspot.com/4951062/diff/11001/input/regression/kievan-note...
> File input/regression/kievan-notes.ly (right):
>
>
http://codereview.appspot.com/4951062/diff/11001/input/regression/kievan-note...
> input/regression/kievan-notes.ly:11: \override NoteHead #'stencil =
> #ly:text-interface::print
> NoteHead doesn't have an interface for 'text, so this regression test
> will spit out warnings when compiled (to see run it with
> -dcheck-internal-types).
>
> The canonical method is to use grob::interpret-markup, but this is still
> rather hackish.  It would be preferable to add the infrastructure which
> switches the glyphs (if possible, a 'style setting).

I'm not sure what is your opinion on this patch currently.  Do you
agree to push it if it doesn't break make, make doc and regtests?  Do
you agree with my comment no.7
http://code.google.com/p/lilypond/issues/detail?id=1873#c7 ?

cheers,
Janek

[Neil Puttock, 2011-09-20 20:37:31]

2011/9/20 Janek Warchoł <janek.lilypond@gmail.com>:

> I'm not sure what is your opinion on this patch currently.  Do you
> agree to push it if it doesn't break make, make doc and regtests?  Do
> you agree with my comment no.7
> http://code.google.com/p/lilypond/issues/detail?id=1873#c7 ?

Yes.

I'm running make doc with the patch applied at the moment.  Will
report any problems.

Cheers,
Neil

[Neil Puttock, 2011-09-20 21:08:44]

2011/9/20 Neil Puttock <n.puttock@gmail.com>:

> I'm running make doc with the patch applied at the moment.  Will
> report any problems.

There's nothing wrong with the patch as far as I can tell.  Make doc
completes successfully here.

The only thing that's missing is an entry in
Documentation/notation/notation-appendices.itely to show the glyphs.

Cheers,
Neil

[aleksandr.andreev, 2011-09-21 02:27:23]

Unfortunately, I cannot get my documentation to build. As was
suggested earlier, I nuked my build folder and redid everything from
the beginning (configure.sh, make all, touch, make doc). However, make
doc errors out with the following message:

Calculating line breaks... Segmentation fault
command failed: /home/sasha/lilypond-git/build/out/bin/lilypond
-dbackend=eps --formats=ps,png,pdf  -dinclude-eps-fonts
-dgs-load-fonts --header=doctitle --header=doctitlecs
--header=doctitlede --header=doctitlees --header=doctitlefr
--header=doctitlehu --header=doctitleit --header=doctitleja
--header=doctitlenl --header=doctitlezh --header=texidoc
--header=texidoccs --header=texidocde --header=texidoces
--header=texidocfr --header=texidochu --header=texidocit
--header=texidocja --header=texidocnl --header=texidoczh
-dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I
"/home/sasha/lilypond-git/build/out/lybook-db"  -I
"/home/sasha/lilypond-git/build/Documentation"  -I
"/home/sasha/lilypond-git/Documentation"  -I
"/home/sasha/lilypond-git/build/Documentation/out-www"  -I
"/home/sasha/lilypond-git/input"  -I
"/home/sasha/lilypond-git/Documentation"  -I
"/home/sasha/lilypond-git/Documentation/snippets"  -I
"/home/sasha/lilypond-git/input/regression"  -I
"/home/sasha/lilypond-git/Documentation/included"  -I
"/home/sasha/lilypond-git/build/mf/out"  -I
"/home/sasha/lilypond-git/build/mf/out"  -I
"/home/sasha/lilypond-git/Documentation/pictures"  -I
"/home/sasha/lilypond-git/build/Documentation/pictures/out-www"
--formats=eps  --verbose  -deps-box-padding=3.000000  -dread-file-list
-dno-strip-output-dir
"/home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly"
Child returned 139
make[2]: *** [out-www/notation.texi] Error 1
make[2]: Leaving directory `/home/sasha/lilypond-git/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/sasha/lilypond-git/build'
make: *** [doc-stage-1] Error 2

Does anyone have any idea what could be going on?

> The only thing that's missing is an entry in
> Documentation/notation/notation-appendices.itely to show the glyphs.

OK. I'll work on notation-appendices.itely.

Aleks

[Graham Percival, 2011-09-21 03:07:19]

On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote:
>
"/home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly"
 
> Does anyone have any idea what could be going on?

What's in the above file?  It'll probably contain 5-10 other
filenames; one of those is the failing file.  If you find the
failing file, you can see the syntax that caused the error in
lilypond, and then you can (relatively) easily investigate why
that syntax causes a problem.

This process can be automated relatively easily ("relatively
easily" meaning 2-10 hours of python and build system work); that
was the whole point of
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-9-_002d-...

Cheers,
- Graham

[janek, 2011-09-21 06:02:34]

2011/9/21 Graham Percival <graham@percival-music.ca>:
> On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote:
>>
"/home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly"
>
>> Does anyone have any idea what could be going on?
>
> What's in the above file?  It'll probably contain 5-10 other
> filenames; one of those is the failing file.  If you find the
> failing file, you can see the syntax that caused the error in
> lilypond, and then you can (relatively) easily investigate why
> that syntax causes a problem.

Out of curiosity i searched for snippet-names-5304161007275961614.ly
file in build/out/lybook-db/ and... it doesn't exist.  In fact i
couldn't find snippet-names-5304161007275961614.ly anywhere in
lilypond-git.

Another interesting thing is that make doc failed for me too, but with
different error message:

extract_texi_filenames.py: Processing out-www/learning.texi
Warning: No such file: learning/working.itely (search path:
.:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www)
Warning: No such file: learning/scheme-tutorial.itely (search path:
.:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www)
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/learning.de.xref-map
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/notation.xref-map
out-www/notation.texi
extract_texi_filenames.py: Processing out-www/notation.texi
Warning: No such file: notation/programming-interface.itely (search
path:
.:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www)
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/notation.de.xref-map
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/usage.xref-map
out-www/usage.texi
extract_texi_filenames.py: Processing out-www/usage.texi
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map
cp -p web.texi out-www/web.texi
cp: cannot stat `web.texi': No such file or directory
make[3]: *** [out-www/web.texi] Error 1
make[3]: Leaving directory `/home/janek/lilypond-git/build/Documentation/de'
make[2]: *** [WWW-1] Error 2
rm out-www/weblinks.itexi
make[2]: Leaving directory `/home/janek/lilypond-git/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/janek/lilypond-git/build'
make: *** [doc-stage-1] Error 2

It's the first time i tried compiling docs, so i may have screwed
something.  Here's what i did:
    rm -r build
    sh autogen.sh --noconfigure
    mkdir -p build/
    cd build/
    ../configure
    make
    make doc

and this failed as above...

> This process can be automated relatively easily ("relatively
> easily" meaning 2-10 hours of python and build system work); that
> was the whole point of
>
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-9-_002d-...

What's the status of this?  I don't see any protests to the "probable
decision" but i also don't see any final decision...

cheers,
Janek

[mike_apollinemike.com, 2011-09-21 06:15:26]

On Sep 21, 2011, at 8:02 AM, Janek Warchoł wrote:

> 2011/9/21 Graham Percival <graham@percival-music.ca>:
>> On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote:
>>>
"/home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly"
>> 
>>> Does anyone have any idea what could be going on?
>> 
>> What's in the above file?  It'll probably contain 5-10 other
>> filenames; one of those is the failing file.  If you find the
>> failing file, you can see the syntax that caused the error in
>> lilypond, and then you can (relatively) easily investigate why
>> that syntax causes a problem.
> 
> Out of curiosity i searched for snippet-names-5304161007275961614.ly
> file in build/out/lybook-db/ and... it doesn't exist.  In fact i
> couldn't find snippet-names-5304161007275961614.ly anywhere in
> lilypond-git.
> 

Hey Janek,

I believe that the names of snippets are randomly generated anew every time the
relevant make command is called.

Cheers,
MS

[pkx166h, 2011-09-21 06:30:07]

Hello,

2011/9/21 mike@apollinemike.com <mike@apollinemike.com>:
>
> On Sep 21, 2011, at 8:02 AM, Janek Warchoł wrote:
>
>> 2011/9/21 Graham Percival <graham@percival-music.ca>:
>>> On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote:
>>>>
"/home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly"
>>>
>>>> Does anyone have any idea what could be going on?
>>>
>>> What's in the above file?  It'll probably contain 5-10 other
>>> filenames; one of those is the failing file.  If you find the
>>> failing file, you can see the syntax that caused the error in
>>> lilypond, and then you can (relatively) easily investigate why
>>> that syntax causes a problem.
>>
>> Out of curiosity i searched for snippet-names-5304161007275961614.ly
>> file in build/out/lybook-db/ and... it doesn't exist.  In fact i
>> couldn't find snippet-names-5304161007275961614.ly anywhere in
>> lilypond-git.
>>
>
> Hey Janek,
>
> I believe that the names of snippets are randomly generated anew every time
the relevant make command is called.

Yes, they are.

-- 
--
James

��{
James

[janek, 2011-09-21 07:03:07]

2011/9/21 Peekay Ex <pkx166h@gmail.com>:
> Hello,
>
> 2011/9/21 mike@apollinemike.com <mike@apollinemike.com>:
>>
>> On Sep 21, 2011, at 8:02 AM, Janek Warchoł wrote:
>>> Out of curiosity i searched for snippet-names-5304161007275961614.ly
>>> file in build/out/lybook-db/ and... it doesn't exist.  In fact i
>>> couldn't find snippet-names-5304161007275961614.ly anywhere in
>>> lilypond-git.
>>
>> I believe that the names of snippets are randomly generated anew every time
the relevant make command is called.
>
> Yes, they are.

Aha.  Thanks for explanation.  How can we find out what's the problem then?

cheers,
Janek

[aleksandr.andreev, 2011-09-21 12:09:56]

>> What's in the above file?  It'll probably contain 5-10 other
filename

Yes. All the different snippets seem to have something to do with percussion.

Aleks

[pkx166h, 2011-09-21 12:50:41]

Hello,

On Wed, Sep 21, 2011 at 1:09 PM, Aleksandr Andreev
<aleksandr.andreev@gmail.com> wrote:
>>> What's in the above file?  It'll probably contain 5-10 other
> filename
>
> Yes. All the different snippets seem to have something to do with percussion.
>
> Aleks
>
> _______________________________________________
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel
>

You did see that I was able to build the documentation this morning on
your patch?

I think the problem is possibly the state of your tree you are building from.

-- 
--
James

[janek, 2011-09-21 17:37:51]

2011/9/21 Peekay Ex <pkx166h@gmail.com>:
> Hello,
>
> On Wed, Sep 21, 2011 at 1:09 PM, Aleksandr Andreev
> <aleksandr.andreev@gmail.com> wrote:
>>>> What's in the above file?  It'll probably contain 5-10 other
>> filename
>>
>> Yes. All the different snippets seem to have something to do with percussion.
>
> You did see that I was able to build the documentation this morning on
> your patch?
>
> I think the problem is possibly the state of your tree you are building from.

The most interesting thing is that i got a make doc error too!

Here is what i see when i call 'git log --oneline':

5bb8482 Add glyphs for Kievan Notation
1b77637 Doc: update translation status.
41fca35 Doc-es: update Vocal.
9446d6a Merge branch 'master' into lilypond/translation
f2ac987 Doc-es: update Usage/Running.
7c6fe26 Doc-es: update Notation/Rhythms, Usage/LilyPond-Book.
adb80c0 Doc-es: update Input.
8dabf10 Doc-es: complete updating Programming Interface.
4469eaf Doc-es: update Programming interfaces.
a8b60ab parser.yy: Allow embedded_scm inside \book & and \bookpart
ef8dd3e Merge branch 'release/unstable'
e166d07 Release: bump version.
a327032 Release: update news.
63cfd55 Release: update news.
1a41431 parser.yy: Use precedences to remove REPEAT/ALTERNATIVE
shift/reduce problem
0ae0eb4 parser.yy: Reorganization/cleanup
31e79fa define-markup-commands.scm: Fix bad parameter type for \on-the-fly
5483f4b Doc-fr: typo (notation/input)
4d8f987 Doc-es: update Changing defaults.
3930746 Fix 1896: chord names can have instrument names.
3c6e2cd Amend 16e626a85244: Forgot to change the function documentation string
ff38b00 doc build: Use all includes for texinfo also for the xref-map generation
16e626a Introduce a maximum depth for markup evaluation
25be0aa Fix 380: Try to auto-detect cyclic references in header fields
e2ebf57 Fix 380: Auto-detect all cyclic references in markups
f925133 Add some polyphonically directed grobs
2fff263 New short lyric tie.
ca53f84 Fix 1903: honor score-ending manual page breaks.
c5ad460 Uses Beam::is_knee instead of get_property ("knee") to check
for kneed beams.
126b045 Doc: a more precise translation status.
f78e9c0 Doc-es: update Suggestions, Scheme, Updating.
7fb2a99 Doc-es: update CHANGES, Chords, Percussion, World,
usage/external, and more.
f8a4491 Fix missing linebreaks in output
e10a13c Formatting nits.
b551257 Warnings: Turn some normal messages into warnings
8653d9a Revert "Release: update news."
ea4fdf1 Merge branch 'master' into lilypond/translation
5de09e7 Doc: adding doc strings for \...DashPattern and \harmonicBy...
fced4c8 Cleans the selector of "reduced hole" noteheads.
a2d8779 change longas similarly to how breves were changed
3f36a29 Revert "change longas similarly to how breves were changed"
79c2154 Revert "variable fix"
67e06fc variable fix
72b2acb change longas similarly to how breves were changed
b1bc02e Glossary: Fix snippets with Scale degree and function
31dd18a Make: Move comments out of the receipe; We don't want them to
be passed to the shell
b7fc79e Build fix : destroy nice python list comprehension
677f06b Release: update news.
463be0c Build: fix website (1892)
0e31cd9 Add missing files of the previous commit.
0dcc93c Improves parmesan noteheads.

Here is my error message:

\entry{Benutzung auf der Kommandozeile}{51}{\code {\xeatspaces {Benutzung auf d
er Kommandozeile}}}
\entry{lilypond-book}{51}{\code {\xeatspaces {lilypond-book}}}
] [52] [53] [54] [55] [56] [57]) Anhang B [58] (./usage.cps [59]) [60] )
(see the transcript file for additional information) </home/janek/.texmf-var/fo
nts/pk/ljfour/jknappen/ec/ecrm0900.600pk> </home/janek/.texmf-var/fonts/pk/ljfo
ur/jknappen/ec/ecrm1095.603pk></usr/share/texmf-texlive/fonts/type1/public/amsf
onts/cm/cmb10.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmbx
12.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmcsc10.pfb></u
sr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/te
xmf-texlive/fonts/type1/public/amsfonts/cm/cmmi12.pfb></usr/share/texmf-texlive
/fonts/type1/public/amsfonts/cm/cmmi9.pfb></usr/share/texmf-texlive/fonts/type1
/public/amsfonts/cm/cmr10.pfb></usr/share/texmf-texlive/fonts/type1/public/amsf
onts/cm/cmr7.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr8.
pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr9.pfb></usr/sha
re/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsl10.pfb></usr/share/texmf-te
xlive/fonts/type1/public/amsfonts/cm/cmsltt10.pfb></usr/share/texmf-texlive/fon
ts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/texmf-texlive/fonts/type1/pu
blic/amsfonts/cm/cmti10.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfon
ts/cm/cmti8.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmtt10
.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmtt12.pfb></usr/
share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmtt9.pfb></usr/share/texmf-
texlive/fonts/type1/public/amsfonts/latxfont/lcircle1.pfb></usr/share/texmf-tex
live/fonts/type1/urw/ncntrsbk/uncb8a.pfb></usr/share/texmf-texlive/fonts/type1/
urw/ncntrsbk/uncr8a.pfb></usr/share/texmf-texlive/fonts/type1/urw/ncntrsbk/uncr
i8a.pfb>
Output written on usage.pdf (63 pages, 639810 bytes).
Transcript written on usage.log.
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/essay.xref-map
out-www/essay.texi
extract_texi_filenames.py: Processing out-www/essay.texi
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/essay.de.xref-map
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/extending.xref-map
out-www/extending.texi
extract_texi_filenames.py: Processing out-www/extending.texi
writing:
/home/janek/lilypond-git/build/./out-www/xref-maps/extending.de.xref-map
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/learning.xref-map
out-www/learning.texi
extract_texi_filenames.py: Processing out-www/learning.texi
Warning: No such file: learning/working.itely (search path:
.:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www)
Warning: No such file: learning/scheme-tutorial.itely (search path:
.:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www)
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/learning.de.xref-map
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/notation.xref-map
out-www/notation.texi
extract_texi_filenames.py: Processing out-www/notation.texi
Warning: No such file: notation/programming-interface.itely (search
path:
.:./out-www:/home/janek/lilypond-git/Documentation/de:/home/janek/lilypond-git/Documentation/de/included:/home/janek/lilypond-git/Documentation:/home/janek/lilypond-git/build/Documentation/./out-www)
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/notation.de.xref-map
/home/janek/lilypond-git/build/scripts/build/out/extract_texi_filenames
-o /home/janek/lilypond-git/build/./out-www/xref-maps -I ./out-www -I
/home/janek/lilypond-git/Documentation/de -I
/home/janek/lilypond-git/Documentation/de/included -I
/home/janek/lilypond-git/Documentation -I
/home/janek/lilypond-git/build/Documentation/./out-www
--master-map-file=/home/janek/lilypond-git/build/./out-www/xref-maps/usage.xref-map
out-www/usage.texi
extract_texi_filenames.py: Processing out-www/usage.texi
writing: /home/janek/lilypond-git/build/./out-www/xref-maps/usage.de.xref-map
cp -p web.texi out-www/web.texi
cp: cannot stat `web.texi': No such file or directory
make[3]: *** [out-www/web.texi] Error 1
make[3]: Leaving directory `/home/janek/lilypond-git/build/Documentation/de'
make[2]: *** [WWW-1] Error 2
rm out-www/weblinks.itexi
make[2]: Leaving directory `/home/janek/lilypond-git/build/Documentation'
make[1]: *** [WWW-1] Error 2
make[1]: Leaving directory `/home/janek/lilypond-git/build'
make: *** [doc-stage-1] Error 2


2011/9/21 Phil Holmes <mail@philholmes.net>:
>
> ----- Original Message ----- From: "Janek Warchoł"
> <janek.lilypond@gmail.com>
> [snip]
>
>>
>> It's the first time i tried compiling docs, so i may have screwed
>> something.  Here's what i did:
>>   rm -r build
>>   sh autogen.sh --noconfigure
>>   mkdir -p build/
>>   cd build/
>>   ../configure
>>   make
>>   make doc
>
> That looks OK - although you don't need the autogen if you've done it
> before.
>
> A quick look at what you have above makes it seem like you have missing
> files.  Is your git tree up to date

Yes

> and in good shape?

I suppose so...

> If you can't get
> make doc to work with the commands above, I've resorted to nuking my git
> directory too...
>
> Before you do this, though, go through the steps above with a "good" git
> tree and instead of running make doc, run make -d doc &> somefile.txt.  Then
> zip the output and send it my way some convenient way.

I'll try running make doc on current master, but it takes so much time...

cheers,
Janek

[aleksandr.andreev, 2011-09-21 23:49:03]

Updated Documentation/notation/notation-appendices.itely to show new glyphs,
reflecting comments by Neil.

[aleksandr.andreev, 2011-09-22 01:06:25]

Yet another rm -fdr build/ and re-run of make, etc., eliminated my
original problem with snippets.

Now, my make doc command crashes with the same error message that
Janek is getting.

Looks like there's a missing file web.texi.

Aleks

[aleksandr.andreev, 2011-09-23 20:00:25]

make doc problem solved on my system. I can confirm that make and make doc run
successfully with this patch.

[mail_philholmes.net, 2011-09-24 10:23:07]

----- Original Message ----- 
From: <aleksandr.andreev@gmail.com>
To: <percival.music.ca@gmail.com>; <janek.lilypond@gmail.com>; 
<pkx166h@gmail.com>; <carl.d.sorensen@gmail.com>; <lemzwerg@googlemail.com>; 
<reinhold.kainhofer@gmail.com>; <wl@gnu.org>; <n.puttock@gmail.com>; 
<graham@percival-music.ca>; <mike@apollinemike.com>
Cc: <reply@codereview.appspotmail.com>; <lilypond-devel@gnu.org>
Sent: Friday, September 23, 2011 9:00 PM
Subject: Re: Glyphs for Kievan Notation (issue 4951062)


> make doc problem solved on my system. I can confirm that make and make
> doc run successfully with this patch.


What did you do to get make doc going?

--
Phil Holmes

[Bertrand Bordage, 2011-09-24 12:47:09]

This passes make and make doc on my computer, without a scratch.

This is a great work, but it doesn't fit correctly into LilyPond:

* This should be put inside the parmesan font, like every ancient font:
noteheads in parmesan-noteheads, accidentals in parmesan-accidentals, clef in
parmesan-clefs, dot in parmesan-dots and the final "barline" in parmesan-scripts

* Update 'note-head::calc-glyph-name' and 'select-head-glyph' in
scm/output-lib.scm so that it handles the kievan style.

* Add your new style to input/regression/note-head-style.ly


I also agree with Werner, there's also a lot of cleanup to do inside your
MetaFont stuff.

For example, you are using 15 dots for the flat glyph, but this could be reduced
to 5 or 6 dots.

Another example: there's a lot of common parts between your glyphs. We can see
it in such cases:

\markup \vspace #5
\markup \fontsize #15 {
  \musicglyph #"kievan.u2kievan"
  \scale #'(1 . -1) \musicglyph #"kievan.d2kievan"
}

95% of these glyphs is the same and could be merged.

In a general way, the idea with MetaFont is that you can easily see what a glyph
looks like by reading its code. Writing a bunch of dots with hard-coded
positions has no logical sense until you compile it. You have to write your
equations directly, instead of writing their results.

Again, thanks for having done this great work,
Bertrand

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode27
mf/feta-kievan.mf:27: fet_beginchar ("kievan quarter (down)", "d4kievan");
"d2kievan" instead of "d4kievan"
We are using the duration log to select glyphs.

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode32
mf/feta-kievan.mf:32: x1 = 0.09 * staff_space;
In MetaFont, '=' stands for a mathematical equality.
Here, you are making an attribution, so ':=' would be better.
This comment is true for all your "[...] = [num] * staff_space;" lines.

Plus, you could use "z1 := (0.09 staff_space, 0.33 staff_space);" as you
correctly made later.

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode61
mf/feta-kievan.mf:61: fet_beginchar ("kievan quarter (up)", "u4kievan");
"u2kievan" (see previous comment)

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode91
mf/feta-kievan.mf:91: fet_beginchar ("kievan final note", "sfinalkievan");
Why not using a fake duration log such as -2?
This is used for brevis noteheads.
So, this will give "sM2kievan" instead of "sfinalkievan".

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode124
mf/feta-kievan.mf:124: fet_beginchar ("kievan recitative mark", "srecitative");
As for previous comment, I think "sM1kievan" would be better.

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode180
mf/feta-kievan.mf:180: fet_beginchar ("kievan half note (line position)",
"s2lkievan");
Use "s1kievan" instead.
This will use the selector I made for noteheads that are on line or between
lines (commit 0dcc93c0a5a97d048db2f7631966f41ae0059ab5).

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode205
mf/feta-kievan.mf:205: fet_beginchar ("kievan half note (space position)",
"s2skievan");
Use "s1rkievan" instead.
See previous comment.

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode231
mf/feta-kievan.mf:231: fet_beginchar ("kievan clef", "scleftsefaut");
"kievan.do" or "kievan.c3" instead of "scleftsefaut".
"Tse-Fa-Ut" can be written in the description.

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode271
mf/feta-kievan.mf:271: fet_beginchar ("kievan whole note", "s1kievan");
"s0kievan" (see earlier comment)

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode290
mf/feta-kievan.mf:290: fet_beginchar ("kievan eighth note (down)", "d8kievan");
"d3kievan" (see earlier comment)

http://codereview.appspot.com/4951062/diff/41002/mf/feta-kievan.mf#newcode319
mf/feta-kievan.mf:319: fet_beginchar ("kievan eighth note (up)", "u8kievan");
"u3kievan" (see earlier comment)

[aleksandr.andreev, 2011-09-24 13:03:27]

> What did you do to get make doc going?

I nuked my entire lilypond-git directory, reinstalled the source and
ran make and make doc.

Then, I ran the Kievan patch and recompiled.

A

[aleksandr.andreev, 2011-09-24 13:20:30]

> This is a great work, but it doesn't fit correctly into LilyPond:

OK, I will merge with Parmesan and work on the Scheme stuff.

> I also agree with Werner, there's also a lot of cleanup to do inside
> your MetaFont stuff.

I'm  new to MetaFont, so right now I'm using it like a GUI-less
outline font editor. I know that's probably the wrong approach.

A

[aleksandr.andreev, 2011-09-28 02:39:26]

Per comments by Bertrand, I have moved the Kievan glyphs to Parmesan. I have
also changed the names of the glyphs as he suggested.

I've begun working on improving the MetaFont code. Please take a look at the
code for the final note, the recitative, and the whole note and let me know if
I'm on the right track.

I've been trying to understand the way the other glyphs in Parmesan are drawn,
but there's a lot of subpaths of circles and other stuff that quite honestly is
beyond me at this point. :(

[wl_gnu.org, 2011-09-29 06:59:02]

> I've begun working on improving the MetaFont code. Please take a
> look at the code for the final note, the recitative, and the whole
> note and let me know if I'm on the right track.

This is definitely the right track.  Currently, I don't have the time
to actually apply your patches, but it looks good.


    Werner

[janek, 2011-09-29 11:36:22]

2011/9/28  <aleksandr.andreev@gmail.com>:
> Per comments by Bertrand, I have moved the Kievan glyphs to Parmesan. I
> have also changed the names of the glyphs as he suggested.
>
> I've begun working on improving the MetaFont code. Please take a look at
> the code for the final note, the recitative, and the whole note and let
> me know if I'm on the right track.

Yes, that's definately the "truly Metafont-ish" way of writing glyphs :)

Btw, you may be interested in this script written by me to ease font work:

#!/bin/bash

# this script generates dvi previews of metafont files;
# they are saved in 'home/font-preview/'.
# call this script from top source directory (usually
# 'lilypond-git/')
#
# first argument is the "operating mode"
# second argument is the name of mf file to be compiled
# (for example feta20, feta-noteheads20, parmesan13 etc.)
# third argument (used only in 'c' operating mode)
# is the branch with changed glyph sources.
#
# operating modes
# c = creates 3 dvi preview files of specified font file
#     and opens them with xdvi:
#     - file-current = how glyphs from master look like
#     - file-new = how glyphs from specified branch look like
#     - file-revised = at the beginning it's a copy of -new;
#     after making some changes in the glyph sources,
#     run this script with operating mode 'r' to see
#     these new changes in third window.
# n = create a dvi preview of a specified mf file
#     and open it with xdvi
# r = recompile the 'file-revised' dvi preview.

case $1 in
  c)
    git commit -a -m "saving unsaved changes"
    git checkout $3
    git pull -r
    git checkout master
    git pull -r

    cd mf/
    mf $2
    gftodvi $2.2602gf
    mv --force $2.dvi ~/font-preview/$2-current.dvi
    rm $2.log
    rm $2.2602gf
    cd ../

    git checkout $3

    cd mf/
    mf $2
    gftodvi $2.2602gf
    mv --force $2.dvi ~/font-preview/$2-new.dvi
    rm $2.log
    rm $2.2602gf
    cd ../

    cp ~/font-preview/$2-new.dvi ~/font-preview/$2-revised.dvi

    xdvi ~/font-preview/$2-current.dvi &
    xdvi ~/font-preview/$2-new.dvi &
    xdvi ~/font-preview/$2-revised.dvi &
    ;;

  n)
    cd mf/
    mf $2
    gftodvi $2.2602gf
    mv --force $2.dvi ~/font-preview/$2.dvi
    rm $2.log
    rm $2.2602gf
    cd ../
    xdvi ~/font-preview/$2.dvi &
    ;;

  r)
    cd mf/
    mf $1
    gftodvi $1.2602gf
    mv --force $1.dvi ~/font-preview/$1-revised.dvi
    rm $1.log
    rm $1.2602gf
    ;;
esac


Additional small tip: it's good to check how glyphs look like at
different design sizes, just to be sure that there are no unwanted
side effects.  I suggest compiling a dvi proof at least for sizes 20
(standard) and 13.

cheers,
Janek

[aleksandr.andreev, 2011-09-30 01:10:31]

I've uploaded changes to output-lib.scm. The problem I have is that output-lib
does not allow access to noteheads of log-duration greater than 2.

I've temporarily changed a few lines of the file. However, I'm not sure this is
the best way of doing this. Please let me know what the right approach should
be.

[Bertrand Bordage, 2011-09-30 10:07:10]

Very good!  The MetaFont code could still be improved, but don't think about it.
 The only things you have to improve in MetaFont are the character boxes, which
are broken.  Example:
\markup \box { \musicglyph #"noteheads.u3kievan" \musicglyph
#"scripts.barline.kievan" \musicglyph #"accidentals.kievanM1" }

A glyph for clef changes would also be great.


Then we have to integrate your patch to LilyPond.  First, I think you made the
right thing in output-lib.scm.  Now, let's do a KievanStaff!

*** Add this in scm/output-lib.scm, line 581:
(define-public alteration-kievan-glyph-name-alist
  '((-1/2 . "accidentals.kievanM1")
    (0 . "accidentals.vaticana0")
    (1/2 . "accidentals.kievan1")))

*** Add this in lily/bar-line.cc, line 289:
  else if (str == "kievan")
    m.add_stencil (Font_interface::get_default_font (me)->find_by_name
("scripts.barline.kievan"));

*** Add this in scm/output-lib.scm, line 324:
    ;; ancient bar lines
    ("kievan" . ("kievan" . ""))

*** Add this in scm/parser-clef.scm, line 79:
    ("kievan-do" . ("clefs.kievan.do" 0 0))
*** and line 107:
    ("clefs.kievan.do" . 0)

*** Add this to ly/engraver-init.ly, line 1103:
\context {
  \Voice
  \name "KievanVoice"
  \alias "Voice"
  \description "Same as @code{Voice} context, except that it is
accommodated for typesetting a piece in Kievan style."

  \remove Stem_engraver

  %% Set glyph styles.
  \override NoteHead #'style = #'kievan
  \override Rest #'style = #'mensural
  \override Accidental #'glyph-name-alist = #alteration-kievan-glyph-name-alist
  \override Dots #'style = #'kievan

  %% There are no beams in Kievan notation.
  autoBeaming = ##f
}

\context {
  \Staff
  \name "KievanStaff"
  \alias "Staff"
  \denies "Voice"
  \defaultchild "KievanVoice"
  \accepts "KievanVoice"
  \description "Same as @code{Staff} context, except that it is
accommodated for typesetting a piece in Kievan style."

  %% Choose kievan do clef.
  clefGlyph = #"clefs.kievan.do"
  middleCClefPosition = #0
  middleCPosition = #0
  clefPosition = #0
  clefOctavation = #0

  %% Accidentals are valid only once (if the following note is different)
  extraNatural = ##f
  autoAccidentals = #`(Staff ,(make-accidental-rule 'same-octave 0)
                             ,neo-modern-accidental-rule)
  autoCautionaries = #'()
  printKeyCancellation = ##f
}

*** and line 550:
  \accepts "KievanStaff"


Of course, you can change what I wrote, especially the names.

Thanks!
Bertrand

http://codereview.appspot.com/4951062/diff/59001/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):

http://codereview.appspot.com/4951062/diff/59001/mf/parmesan-noteheads.mf#new...
mf/parmesan-noteheads.mf:1861: fet_beginchar ("kievan half note (space
position)", "s1rkievan");
"sr1kievan" instead of "s1rkievan".

[aleksandr.andreev, 2011-10-03 22:52:05]

I've taken care of the issues Bertrand points out in #46. There are still some
issues outstanding. The code in output-lib.scm is probably not the best way of
doing this. Also, the Kievan bar line does not appear correctly.

[Bertrand Bordage, 2011-10-04 12:16:09]

You can't solve the Kievan bar line problem without calculate every dot
position.  I made a pure MetaFont version of the Kievan bar line:

fet_beginchar ("kievan end of piece (slash)", "barline.kievan");
	% this draws the end of piece figure
	% this figure is placed at the end of the musical piece, after the staff
	save hair_thickness, thick_thickness, width, depth, height, path;
	hair# = 1.9 linethickness#;
	thick# = 6.0 linethickness#;
	width# = .8 staff_space#;
	height# + depth# = 4 staff_space#;
	depth# = height# + hair# / 2;

	set_char_box (0, width#, depth#, height#);
	define_pixels (hair, thick);

	x1r - x2l = w;
	y1 - y3r = d + h + linethickness / 2;
	z3 = z2;
	z4 = .5 [z1, z2] = (w / 2, hair / 8);
	z5 = (x2 - .17 staff_space, 9/10 [y2, y1]);
	z7 - z6 = (.5 staff_space, -.2 staff_space);
	.4 [z6, z7] = 7/6 [z2, z1];

	pickup pencircle scaled blot_diameter;
	penpos1 (hair, 0);
	penpos2 (hair, 0);
	penpos3 (hair, -90);
	penpos4 (thick, 10);
	penpos5 (thick, 35);
	penpos6 (hair, -90);
	penpos7 (.5 thick, -120);

	penlabels (1, 2, 3, 4, 5, 6, 7);

	fill z1r
	     -- z2r
	     -- z2l
	     -- z1l
	     -- cycle;

	fill simple_serif (z3l, z3r, 90){1.5 right}
	     .. z4r
	     .. z5r
	     .. z6r
	     .. simple_serif (z7r, z7l, 80)
	     .. {left}z6l
	     .. z5l
	     .. z4l
	     .. cycle;
fet_endchar;


I will make a complete review later.

Bertrand

[Bertrand Bordage, 2011-10-07 10:29:15]

Here's the second part of my review.  I saw that kievan notation has beams,
contrary to what I thought.  If you're intrepid, you can also try to implement
the kievan beaming parameters in you KievanVoice.

Hold on, it's the end!
Bertrand

http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):

http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf#newcode...
mf/parmesan-clefs.mf:1738: % TODO: merge this code with the above
Obviously, this must be done.  This is easy, you just have to define the glyph
and create two characters with it:


def draw_kievan_do_clef =
    z1 = [...]
[...]
enddef;

fet_beginchar ([...]);
    draw_kievan_do_clef;
fet_endchar;

fet beginchar ([...]_change");
    % TODO: make a different glyph for changes, but
    % dunno what a kievan clef looks like in changes...
    draw[...];
endchar;

http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):

http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf#new...
mf/parmesan-noteheads.mf:1861: fet_beginchar ("kievan half note (space
position)", "s1rkievan");
Still "sr1kievan".

http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm
File scm/output-lib.scm (right):

http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode101
scm/output-lib.scm:101: (min 2
Maybe you could try to change "min 2" for "min 3" and remove what you added
before.  I'm totally unsure of that, we must check what's going on downstream to
be sure.

http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode595
scm/output-lib.scm:595: (0 . "accidentals.vaticana0")
I guess there's no natural glyph in kievan notation since there is no time
signature and no accidental 'remembering'.  Can you confirm this?  Maybe we need
to remove this line, then.  This will produce a warning (but no crash) if one
tries to use a natural in kievan style.

[aleksandr.andreev, 2011-10-07 16:32:29]

I'm trying to implement beams, but I get this message:

"must have Item for spanner bound of Beam"

What does this refer to?

A

On Fri, Oct 7, 2011 at 6:29 AM,  <bordage.bertrand@gmail.com> wrote:
> Here's the second part of my review.  I saw that kievan notation has
> beams, contrary to what I thought.  If you're intrepid, you can also try
> to implement the kievan beaming parameters in you KievanVoice.
>
> Hold on, it's the end!
> Bertrand
>
>
> http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf
> File mf/parmesan-clefs.mf (right):
>
>
http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-clefs.mf#newcode...
> mf/parmesan-clefs.mf:1738: % TODO: merge this code with the above
> Obviously, this must be done.  This is easy, you just have to define the
> glyph and create two characters with it:
>
>
> def draw_kievan_do_clef =
>    z1 = [...]
> [...]
> enddef;
>
> fet_beginchar ([...]);
>    draw_kievan_do_clef;
> fet_endchar;
>
> fet beginchar ([...]_change");
>    % TODO: make a different glyph for changes, but
>    % dunno what a kievan clef looks like in changes...
>    draw[...];
> endchar;
>
> http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf
> File mf/parmesan-noteheads.mf (right):
>
>
http://codereview.appspot.com/4951062/diff/64002/mf/parmesan-noteheads.mf#new...
> mf/parmesan-noteheads.mf:1861: fet_beginchar ("kievan half note (space
> position)", "s1rkievan");
> Still "sr1kievan".
>
> http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm
> File scm/output-lib.scm (right):
>
> http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode101
> scm/output-lib.scm:101: (min 2
> Maybe you could try to change "min 2" for "min 3" and remove what you
> added before.  I'm totally unsure of that, we must check what's going on
> downstream to be sure.
>
> http://codereview.appspot.com/4951062/diff/64002/scm/output-lib.scm#newcode595
> scm/output-lib.scm:595: (0 . "accidentals.vaticana0")
> I guess there's no natural glyph in kievan notation since there is no
> time signature and no accidental 'remembering'.  Can you confirm this?
> Maybe we need to remove this line, then.  This will produce a warning
> (but no crash) if one tries to use a natural in kievan style.
>
> http://codereview.appspot.com/4951062/
>

[aleksandr.andreev, 2011-10-18 16:47:21]

Fixed the issues addressed by Bertrand.

What still remains:
1. Implementing beams

2. Changing the spacing so that notes in a phrasing slur are closer together.

3. Remove extra space after final note.

Comments much appreciated.

[Bertrand Bordage, 2011-10-18 17:46:23]

LGTM.  Two tiny changes and it'll be ready to push.

http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly
File ly/engraver-init.ly (right):

http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly#newcode1107
ly/engraver-init.ly:1107: \remove Stem_engraver
Sorry, I made a mistake.  This line is producing errors when we use the
kievanvoice/staff.  You have to remove this and add a \override Stem #'stencil =
##f instead.

http://codereview.appspot.com/4951062/diff/78001/ly/engraver-init.ly#newcode1114
ly/engraver-init.ly:1114: \override Slur #'transparent = ##t
Could you change 'transparent' into 'stencil'?  With transparent, the stem is
invisible, but still there.  The calculus of grob positions can be disturbed by
that.

[pkx166h, 2011-11-09 13:26:57]

On 2011/10/18 17:46:23, Bertrand Bordage wrote:
> LGTM.  Two tiny changes and it'll be ready to push.

That was three weeks ago. Is this done? I still see the tracker open, Janek owns
that

http://code.google.com/p/lilypond/issues/detail?id=1873

but he is away so I am chasing the state of this.

james

[aleksandr.andreev, 2011-11-09 14:02:43]

That is done, but before updating I wanted to resolve a few other issues.
However, I cannot figure out how to control the amount of spacing between notes
(I need the notes in a phrasing slur to be closer together). Also, I can't get
the beams to show properly.

[janek, 2011-12-26 09:05:05]

Hi Aleksandr,

2011/11/9  <aleksandr.andreev@gmail.com>:
> That is done, but before updating I wanted to resolve a few other
> issues. However, I cannot figure out how to control the amount of
> spacing between notes (I need the notes in a phrasing slur to be closer
> together). Also, I can't get the beams to show properly.
>
> http://codereview.appspot.com/4951062/

how are you doning?  Can i help you finish Kievan notation, now that
i've came back?
Do i understand correctly that most of the work is done and you just
wanted to implement some (independent) extras?  Maybe it'd be a good
idea to split this and push what is ready.

cheers,
Janek

[aleksandr.andreev, 2012-01-09 02:07:43]

Merged Kievan patch with existing source code and fixed an issue in
output-lib.scm

[janek, 2012-01-11 05:25:08]

http://codereview.appspot.com/4951062/diff/91002/input/regression/note-head-s...
File input/regression/note-head-style.ly (right):

http://codereview.appspot.com/4951062/diff/91002/input/regression/note-head-s...
input/regression/note-head-style.ly:101: 
add break here

http://codereview.appspot.com/4951062/diff/91002/ly/engraver-init.ly
File ly/engraver-init.ly (right):

http://codereview.appspot.com/4951062/diff/91002/ly/engraver-init.ly#newcode1123
ly/engraver-init.ly:1123: \override Stem #'stencil = ##f
this doesn't seem to work

[aleksandr.andreev, 2012-01-11 17:13:23]

>> something like stems, which should be hidden, stick from notes.

The problem here is that we're not using KievanVoice in note-head-style.ly.

I've posted a potential solution to get rid of the "stems", but it's not very
elegant because it breaks the pattern.

Perhaps someone else has a better idea.

[Neil Puttock, 2012-01-11 21:37:36]

On 11 January 2012 17:13,  <aleksandr.andreev@gmail.com> wrote:

> I've posted a potential solution to get rid of the "stems", but it's not
> very elegant because it breaks the pattern.
>
> Perhaps someone else has a better idea.

Add a check for kievan style in Stem::is_normal_stem ().

Cheers,
Neil

[aleksandr.andreev, 2012-01-12 15:43:23]

On 2012/01/11 21:37:36, Neil Puttock wrote:

> Add a check for kievan style in Stem::is_normal_stem ().

Unfortunately, that doesn't seem to do anything. Unless I'm not accessing the
property correctly ... see the latest patch.

Aleks

[Neil Puttock, 2012-01-12 16:24:13]

On 12 January 2012 15:43,  <aleksandr.andreev@gmail.com> wrote:

> Unfortunately, that doesn't seem to do anything. Unless I'm not
> accessing the property correctly ... see the latest patch.

You're trying to access style from the Stem instead of the NoteHead.

Cheers,
Neil

[aleksandr.andreev, 2012-01-12 20:19:47]

On 2012/01/12 16:24:13, Neil Puttock wrote:

> You're trying to access style from the Stem instead of the NoteHead.

Got it. Thanks, Neil.

[janek, 2012-01-17 23:49:03]

Aleksandr,

i apologize for not replying so long.
I've tested your patch and i see only one problem, see below.
When you fix it, could you merge all changes into one commit (using 'git rebase
-i origin/master'), make a patch and send it to James?  I guess he has to check
it manually since Patchy doesn't know how to rebuild fonts.
If you have problems with any off these steps, let me know.

thanks for your work,
Janek

http://codereview.appspot.com/4951062/diff/99002/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):

http://codereview.appspot.com/4951062/diff/99002/mf/parmesan-noteheads.mf#new...
mf/parmesan-noteheads.mf:1813: set_char_box (0, 1.02 staff_space#, 0.37
staff_space#, 0.40 staff_space#);
the last number is too small.  I guess it should be 2.5 staff_space or something
like that.

http://codereview.appspot.com/4951062/diff/99002/mf/parmesan-noteheads.mf#new...
mf/parmesan-noteheads.mf:1833: set_char_box (0, 1.02 staff_space#, 0.40
staff_space#, 0.4 staff_space#);
the last number is too small.  I guess it should be 2.5 staff_space or something
like that.

[Neil Puttock, 2012-01-18 15:44:37]

http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284
lily/stem.cc:284: string style = robust_symbol2string (heads[0]->get_property
("style"), "default");
A bit fussy.  You can safely check the symbol without converting to a string.

SCM style = heads[0]->get_property ("style");
return style != ly_symbol2scm ("kievan") && ...

[Bertrand Bordage, 2012-01-22 18:23:49]

http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc
File lily/stem.cc (right):

http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284
lily/stem.cc:284: string style = robust_symbol2string (heads[0]->get_property
("style"), "default");
I think Aleksandr is right.
See http://lilypond.org/doc/v2.15/Documentation/contributor/comparison

[aleksandr.andreev, 2012-01-23 01:02:13]

Regarding comments by Jan:

>> I guess it should be 2.5 staff_space or something

I changed the depth and height parameters as you suggested. However, I do not
see any difference, in the reg tests or in my test files. Are we sure that the
entire glyph has to fit within the char_box, including the "stem"?

Regarding comments by Neil and Bertrand:

I rewrote Stem::is_normal_stem the way Neil suggested. Looking at the code in
Stem.cc, it appears that both ways are being used to check the style property. I
don't know which is the more correct.

[Neil Puttock, 2012-01-23 12:14:58]

On 23 January 2012 01:02,  <aleksandr.andreev@gmail.com> wrote:

> Regarding comments by Neil and Bertrand:
>
> I rewrote Stem::is_normal_stem the way Neil suggested. Looking at the
> code in Stem.cc, it appears that both ways are being used to check the
> style property. I don't know which is the more correct.

Strictly speaking, Bertrand is more correct.  But there's still no
need to convert to a string.  If we want to be paranoid about such
comparisons, it would be better to use scm_is_eq () for comparing
symbols.

Cheers,
Neil

[aleksandr.andreev, 2012-01-24 15:39:22]

When I go to make the regression tests, I get the following error message:

texi2html --I=/home/sasha/lilypond-git/input/regression/lilypond-book
--I=./out-test -I /home/sasha/lilypond-git/Documentation
--I=/home/sasha/lilypond-git/build/./out-test/xref-maps
--init-file=/home/sasha/lilypond-git/Documentation/lilypond-texi2html.init 
--output=out-test/collated-files.html out-test/collated-files.texi
*** Duplicate node found: Top (in out-test/papersize-docs.texi l. 8)
make[2]: Leaving directory
`/home/sasha/lilypond-git/build/input/regression/lilypond-book'
rsync -L -a --exclude 'out-*' --exclude 'out' --exclude mf --exclude source
--exclude mf /home/sasha/lilypond-git/build/out/share ./out-test
make[1]: Leaving directory
`/home/sasha/lilypond-git/build/input/regression/lilypond-book'

Looks like it's complaining about a "Top" node in collated-files.texi and
another "Top" node in papersize-docs.texi.

[mail_philholmes.net, 2012-01-24 15:55:23]

----- Original Message ----- 
From: <aleksandr.andreev@gmail.com>
To: <percival.music.ca@gmail.com>; <janek.lilypond@gmail.com>; 
<pkx166h@gmail.com>; <carl.d.sorensen@gmail.com>; <lemzwerg@googlemail.com>; 
<reinhold.kainhofer@gmail.com>; <wl@gnu.org>; <n.puttock@gmail.com>; 
<graham@percival-music.ca>; <mike@apollinemike.com>; <mail@philholmes.net>; 
<bordage.bertrand@gmail.com>
Cc: <lilypond-devel@gnu.org>; <reply@codereview-hr.appspotmail.com>
Sent: Tuesday, January 24, 2012 3:39 PM
Subject: Re: Glyphs for Kievan Notation (issue 4951062)


> When I go to make the regression tests, I get the following error
> message:
>
> texi2html --I=/home/sasha/lilypond-git/input/regression/lilypond-book
> --I=./out-test -I /home/sasha/lilypond-git/Documentation
> --I=/home/sasha/lilypond-git/build/./out-test/xref-maps
> --init-file=/home/sasha/lilypond-git/Documentation/lilypond-texi2html.init
>  --output=out-test/collated-files.html out-test/collated-files.texi
> *** Duplicate node found: Top (in out-test/papersize-docs.texi l. 8)
> make[2]: Leaving directory
> `/home/sasha/lilypond-git/build/input/regression/lilypond-book'
> rsync -L -a --exclude 'out-*' --exclude 'out' --exclude mf --exclude
> source --exclude mf /home/sasha/lilypond-git/build/out/share ./out-test
> make[1]: Leaving directory
> `/home/sasha/lilypond-git/build/input/regression/lilypond-book'
>
> Looks like it's complaining about a "Top" node in collated-files.texi
> and another "Top" node in papersize-docs.texi.
>
> http://codereview.appspot.com/4951062/
>

(Snipped distribution list).

Have you got a freshly pulled version of the source?

--
Phil Holmes

[Julien Rioux, 2012-01-24 21:31:46]

On 2012/01/24 15:39:22, aleksandr.andreev wrote:
> Looks like it's complaining about a "Top" node in collated-files.texi and
> another "Top" node in papersize-docs.texi.

This is reported here:
http://code.google.com/p/lilypond/issues/detail?id=2223#c3
I fix for this is in review.

Regards, 
Julien

[janek, 2012-01-24 22:43:03]

only one change left.

On 2012/01/23 01:02:13, aleksandr.andreev wrote:
> Regarding comments by Jan:
> 
> >> I guess it should be 2.5 staff_space or something
> 
> I changed the depth and height parameters as you suggested.
> However, I do not see any difference, in the reg tests
> or in my test files. Are we sure that the entire glyph
> has to fit within the char_box, including the "stem"?

Yes.  There is a difference, compare the position of "kievan" markups in pdfs
attached in the last 2 comments in tracker issue
http://code.google.com/p/lilypond/issues/detail?id=1873#c22
You've forgotten about one char_box, see below.


On 2012/01/24 15:39:22, aleksandr.andreev wrote:
> When I go to make the regression tests, I get the following
> error message: [...]

I've run make and regtests from scratch on a freshly-updated source.  Regtests
seem fine to me (only some differences in logs, looking harmless).

http://codereview.appspot.com/4951062/diff/110002/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):

http://codereview.appspot.com/4951062/diff/110002/mf/parmesan-noteheads.mf#ne...
mf/parmesan-noteheads.mf:1813: set_char_box (0, 1.02 staff_space#, 0.37
staff_space#, 0.40 staff_space#);
this bounding box is still too small.  The third number should be 2.6
staff_space#

[aleksandr.andreev, 2012-01-25 00:01:16]

>> There is a difference, compare the position of "kievan" markups in pdfs

Ah, OK, I see it now.

>> You've forgotten about one char_box, see below.

I fixed this one as well as the char_box for the clef.

>> I've run make and regtests from scratch on a freshly-updated source.

I'm getting the error described above by Julien when running make test. I guess
I have to wait for that patch to be pushed.

[Julien Rioux, 2012-01-25 00:38:59]

On 2012/01/25 00:01:16, aleksandr.andreev wrote:
> I'm getting the error described above by Julien when running make test. I
guess
> I have to wait for that patch to be pushed.

If you time `texi2html --help' in your terminal, what do you see next to the
--error-limit line? For me, it says 1000, which means that it by default will
tolerate a thousand errors before exiting. So for me, the "Top node" error
currently does not stop `make test' from processing further, unless texi2html is
running with the --error-limit=0 flag. If your texi2html is configured the same
as mine, it should keep going. So you might want to skim through the output on
your terminal a bit. What are other error messages in there? You can also send a
log to me if you want and I'll look at it.

Regards,
Julien

[janek, 2012-02-10 22:59:26]

This was pushed as 18dda6b2f5fbea91a174b60eb22bbb73591b9b64
Thanks, Aleksandr and all reviewers!
Janek