Re: commit 12fe78825798191ecb7e5a4ee3064679773ae1ab is broken

[Knut Petersen]

Am 07.06.2018 um 15:24 schrieb James Lowe:
> Hello
>
> On Tue, 5 Jun 2018 14:12:16 +0200, Knut Petersen <address@hidden> wrote:
>
> > Commit 12fe788... caused encodingdefs.ps to be out of sync
> > with the emmentaler fonts.
> >
> > It even does not pass a 'make check' against the previous commit - have a
> > look at the staccato in test-output-distance. The png generated from commit
> > be08490329a2242... shows the expected staccato, the png from commit 12fe788...
> > clearly shows a snappizzicato.
> >
> > Malte, please fix the problem.
> >
> > BTW: we also have make-regtest-pngs.sh ...
> >
> > Knut
> Excuse my ignorance but if this were true

I checked it twice before writing to bug-lilypond, and now I checked a third 
time:

   address@hidden:~/sources/lily> ../mklily-regtest
      exec git clean -dfx in /home/knut/sources/lily ... succeeded after 1 
seconds
      exec git checkout be08490329a22423bb2a723eea7a5cd33f3a42d8 in 
/home/knut/sources/lily ... succeeded after 0 seconds
   Building LILYPOND be08490329a22423bb2a723eea7a5cd33f3a42d8...
      exec ./autogen.sh --noconfigure in /home/knut/sources/lily ... succeeded 
after 0 seconds
      exec mkdir -p build in /home/knut/sources/lily ... succeeded after 0 
seconds
      exec cd /home/knut/sources/lily/build in /home/knut/sources/lily ... 
succeeded after 0 seconds
      exec ../configure --prefix=/home/knut/sources/lilybuilt 
--with-urwotf-dir=/home/knut/sources/urw-core35-fonts in 
/home/knut/sources/lily/build ... succeeded after 7 seconds
      exec make -j 11 CPU_COUNT=11 all in /home/knut/sources/lily/build ... 
succeeded after 103 seconds
      exec make -j 11 CPU_COUNT=11 test-baseline in 
/home/knut/sources/lily/build ... succeeded after 152 seconds
      exec ./make-regtest-pngs.sh -j9 -o in 
/home/knut/sources/lily/scripts/auxiliar ... succeeded after 55 seconds
      exec git checkout 12fe78825798191ecb7e5a4ee3064679773ae1ab in 
/home/knut/sources/lily ... succeeded after 0 seconds
   Building LILYPOND 12fe78825798191ecb7e5a4ee3064679773ae1ab...
      exec ./autogen.sh --noconfigure in /home/knut/sources/lily ... succeeded 
after 0 seconds
      exec mkdir -p build in /home/knut/sources/lily ... succeeded after 0 
seconds
      exec cd /home/knut/sources/lily/build in /home/knut/sources/lily ... 
succeeded after 0 seconds
      exec ../configure --prefix=/home/knut/sources/lilybuilt 
--with-urwotf-dir=/home/knut/sources/urw-core35-fonts in 
/home/knut/sources/lily/build ... succeeded after 6 seconds
      exec make -j 11 CPU_COUNT=11 all in /home/knut/sources/lily/build ... 
succeeded after 9 seconds
      exec make -j 11 CPU_COUNT=11 test-clean in /home/knut/sources/lily/build 
... succeeded after 0 seconds
      exec make -j 11 CPU_COUNT=11 check in /home/knut/sources/lily/build ... 
succeeded after 163 seconds
      exec ./make-regtest-pngs.sh -j9 -n in 
/home/knut/sources/lily/scripts/auxiliar ... succeeded after 306 seconds

The result still is:

 * test-output-distance.png from be084... shows a staccato under the last note, 
the same source compiled with 12fe7... shows a snappizzicato instead.
 * merge-rests-engraver.png, bar 11, 2nd rest: staccato under and above the 
rest compiled with be084... , snappizzicatos if compiled with 12fe7...

Have a look at the attached files.

> wouldn't all the patches I have tested since this was checked in have failed 
> with the make check?

If the next test is based on 12fe7... or later, the error will not show up 
again. Since 12fe7 lilypond produces some wrong glyphs (if called with a 
command line that exposes the problem, there is no problem with the legacy 
postscript code generator that does not use encodings.ps).

BTW: I dont know the script you use.

If you try to use ghostscript on the eps source files used to generate the pngs 
be aware of the fact that our regtest eps files load  emmentaler fonts with 
absolute paths,
not with relative paths to the fonts in 
/build/input/regression/midi/out-test-baseline/... and 
/build/input/regression/midi/out-test/...

After 'make check' these files are still present, but they will not be used by 
ghostscript, even if you override lilypond-datadir on the ghostscript command 
line.

   address@hidden:~/sources/lily> grep loadfont 
./build/input/regression/out-test-baseline/test-output-distance.eps
   
(/home/knut/sources/lily/build/out/share/lilypond/current/fonts/otf/emmentaler-20.otf)
 (r) file .loadfont
   
(/home/knut/sources/lily/build/out/share/lilypond/current/fonts/otf/emmentaler-20.otf)
 (r) file .loadfont
   
(/home/knut/sources/lily/build/out/share/lilypond/current/fonts/otf/emmentaler-brace.otf)
 (r) file .loadfont

   address@hidden:~/sources/lily> grep loadfont 
./build/input/regression/out-test/test-output-distance.eps
   
(/home/knut/sources/lily/build/out/share/lilypond/current/fonts/otf/emmentaler-20.otf)
 (r) file .loadfont
   
(/home/knut/sources/lily/build/out/share/lilypond/current/fonts/otf/emmentaler-20.otf)
 (r) file .loadfont
   
(/home/knut/sources/lily/build/out/share/lilypond/current/fonts/otf/emmentaler-brace.otf)
 (r) file .loadfont

That means gs will always use the fonts of the last version built. Better would 
be something like

   lilypond-datadir (/fonts/otf/emmentaler-20.otf) concatstrings (r) file 
.loadfont


But that does not mean that the regtest results are invalid as the pngs for 
test-baseline are generated at a time before the new fonts overwrite the old 
ones.
I have not had a look at the log, but I suspect that this trap was introduced 
with extractpdfmark. The responsible code is located in framework-ps.scm:

         (define (ps-load-file file-name)
           (if (string? file-name)
              (if (and (not (ly:get-option 'font-export-dir))
                       (string-contains file-name (ly:get-option 'datadir)))

James, of course I excuse your ignorance.   ;-))

But I really think there is a problem with 12fe7...

Knut

test-output-distance-12fe7.png
Description: PNG image

test-output-distance-be08a.png
Description: PNG image

test-output-distance.compare.jpeg
Description: JPEG image