Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?

2017-10-04 Thread Karlin High 
On Wed, Oct 4, 2017 at 6:27 PM, Carl Sorensen  wrote:
> I haven't pulled out all the fonts yet to see how big they are, but I'm
> uncomfortable with referencing a blob in a given commit on the repo.

I think the largest one was about 101KB. So perhaps 1.5MB for all 12 of them.

> I'd be happier if it were referencing a blob in master.
> If it's not too big, I'd be even happier if we could just do a shallow
> clone of the git repo, so the command would never need to change.

Agreed. But I know too little about this issue to help with that.
Is it these EXACT files that are needed? Do newer versions cause problems?

> And we would used git to manage the download, which is what we were
> using previously.

Until the files are part of the repositories already being cloned,
they have to come from somewhere else, I expect.
If there's a git command to download
"just these 12 files, not the whole font repository"
then that could be the way to go. But wget is pretty standard on Linux, right?

> somehow this patch needs to be coordinated with Federico,
> rather than using the standard LilyPond patch sequence.

That's what I gathered, too. I assumed Federico follows this list. The
discussion had
stopped with the question of how to instruct new developers to get the fonts,
and I debated whether to continue it here,
or on the Sourceforge or Rietveld issues.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?

2017-10-04 Thread Carl Sorensen 
On 10/4/17 4:06 PM, "lilypond-devel on behalf of Karlin High"
 wrote:

>https://codereview.appspot.com/315850043/
>https://sourceforge.net/p/testlilyissues/issues/4998/
>
>I found this issue with the fonts while reading the LilyDev
>instructions on GitHub. To me, it looks like the easiest way to
>resolve it would be adding some WGET commands to the
>~/.lilydev-setup.sh script, right after the git clone operations that
>are already assuming an Internet connection. Then the fonts would be
>available from the beginning, and perhaps no special documentation
>would be needed. I'm attaching a proposed script for this idea. (No
>master of BASH here; could be doing it wrong.)

I haven't pulled out all the fonts yet to see how big they are, but I'm
uncomfortable with referencing a blob in a given commit on the repo.

I'd be happier if it were referencing a blob in master.

If it's not too big, I'd be even happier if we could just do a shallow
clone of the git repo, so the command would never need to change. And we
would used git to manage the download, which is what we were using
previously.

Having said all that, I'm fine with what you propose, if none of my other
ideas are workable.

Oh, and by the way, I'm not sure how to handle this, since strictly
speaking LilyDev is a separate product from LilyPond, and we don't host
LilyDev as part of the LilyPond repository.  So somehow this patch needs
to be coordinated with Federico, rather than using the standard LilyPond
patch sequence.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Installing URW++ fonts, issue 4998: why not add wget lines to lilydev-setup.sh?

2017-10-04 Thread Karlin High 
https://codereview.appspot.com/315850043/
https://sourceforge.net/p/testlilyissues/issues/4998/

I found this issue with the fonts while reading the LilyDev
instructions on GitHub. To me, it looks like the easiest way to
resolve it would be adding some WGET commands to the
~/.lilydev-setup.sh script, right after the git clone operations that
are already assuming an Internet connection. Then the fonts would be
available from the beginning, and perhaps no special documentation
would be needed. I'm attaching a proposed script for this idea. (No
master of BASH here; could be doing it wrong.)

Further observations: the referenced git repository has had several
commits since this issue began. One of them changes font file names
from "Oblique" to "Italic," and another says something about fixing a
missing blue zone at the tops of numbers. Should the download links
use the most recent files, or this exact commit from July 12, 2016?
The URLs for this repository could be written for either effect.
-- 
Karlin High
Missouri, USA
#!/bin/bash
# LilyPond docs need Greek and Cyrillic fonts from Ghostscript URW35 

URW35FONTS=\
"C059-BdIta.otf
C059-Bold.otf
C059-Italic.otf
C059-Roman.otf
NimbusMonoPS-Bold.otf
NimbusMonoPS-BoldItalic.otf
NimbusMonoPS-Italic.otf
NimbusMonoPS-Regular.otf
NimbusSans-Bold.otf
NimbusSans-BoldOblique.otf
NimbusSans-Oblique.otf
NimbusSans-Regular.otf"

for font in $URW35FONTS
do
  
WGETURL="http://git.ghostscript.com/?p=urw-core35-fonts.git;a=blob;hb=79bcdfb34fbce12b592cce389fa7a19da6b5b018;f=$font;;
  # wget: less verbose, create directory, don't make host directory,
  # use file name from HTTP header, set download location
  wget -nv -x -nH --content-disposition -P ~/.local/share/fonts "$WGETURL"
done
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Use -b together with -dgs-never-embed-fonts (issue 325630043 by knup...@gmail.com)

2017-10-04 Thread knupero 



> Unfortunately, non-CID-keyed fonts can not use Identity-H encoding.
> XeTeX and LuaTeX seem to convert non-CID-Keyed font to CID-keyed

font on the

> fly, and embed it to PDF, use Identity-H encoding.



Should we create a tracker for this?


I think whoever has an idea and the time to solve one of the remaining
postscript problems will create a tracker.

https://codereview.appspot.com/325630043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue tracker write access

2017-10-04 Thread Malte Meyn 
Thanks, as you can see I just submitted my first patch. I hope I did 
everything correctly?


Am 04.10.2017 um 10:47 schrieb Phil Holmes:

Done.

--
Phil Holmes


- Original Message - From: "Malte Meyn" 
To: 
Sent: Wednesday, October 04, 2017 8:35 AM
Subject: issue tracker write access



Hello list,

too long I have waited but now I would like to start contributing to 
LilyPond. Currently I’m going through the “quick start” of the CG; 
could you please give me (maltem on SourceForge) write access to the 
issue tracker?


Cheers,
Malte

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel





___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Merge_rests_engraver: fix vertical rest positions (issue 334740043 by lilyp...@maltemeyn.de)

2017-10-04 Thread lilypond 

Reviewers: ,

Message:
See
https://lists.gnu.org/archive/html/lilypond-user/2017-10/msg00012.html
for sort of bug report on the user list.

Description:
Merge_rests_engraver: fix vertical rest positions

When used with \magnifyStaff the engraver failed to position merged
rests correctly. Using staff-position instead of Y-offset for vertical
positioning fixes this.

Please review this at https://codereview.appspot.com/334740043/

Affected files (+9, -15 lines):
  M scm/scheme-engravers.scm


Index: scm/scheme-engravers.scm
diff --git a/scm/scheme-engravers.scm b/scm/scheme-engravers.scm
index  
3480610c4caee25a8bb8dd2b97e9accf2147f7d0..c9fc6cd78c715afddc35d6aad17dfd130373bca4  
100644

--- a/scm/scheme-engravers.scm
+++ b/scm/scheme-engravers.scm
@@ -128,20 +128,14 @@ if there were one voice."
   (define (is-single-bar-rest? mmrest)
 (eqv? (ly:grob-property mmrest 'measure-count) 1))

-  (define (is-whole-rest? rest)
-(eqv? (ly:grob-property rest 'duration-log) 0))
-
-  (define (mmrest-offset mmrest)
+  (define (mmrest-position mmrest)
   "For single measures they should hang from the second line from the top
-  (offset of 1). For longer multimeasure rests they should be centered on  
the

-  middle line (offset of 0).
+  (staff-position of 2). For longer multimeasure rests they should be  
centered on the

+  middle line (staff-position of 0).
   NOTE: For one-line staves full single measure rests should be positioned  
at

   0, but I don't anticipate this engraver's use in that case. No errors are
   given in this case."
-(if (is-single-bar-rest? mmrest) 1 0))
-
-  (define (rest-offset rest)
-(if (is-whole-rest? rest) 1 0))
+(if (is-single-bar-rest? mmrest) 2 0))

   (define (rest-eqv rest-len-prop)
 "Compare rests according the given property"
@@ -158,12 +152,12 @@ if there were one voice."
   (define (merge-mmrests rests)
   "Move all multimeasure rests to the single voice location."
 (if (all-equal rests (rest-eqv 'measure-count))
-  (merge-rests rests mmrest-offset)))
+  (merge-rests rests mmrest-position)))

-  (define (merge-rests rests offset-function)
-(let ((y-offset (offset-function (car rests
+  (define (merge-rests rests position-function)
+(let ((staff-pos (position-function (car rests
   (for-each
-(lambda (rest) (ly:grob-set-property! rest 'Y-offset y-offset))
+(lambda (rest) (ly:grob-set-property! rest 'staff-position  
staff-pos))

 rests))
 (for-each
   (lambda (rest) (ly:grob-set-property! rest 'transparent #t))
@@ -217,7 +211,7 @@ if there were one voice."
 (all-equal durs moment=?)
 (rests-all-unpitched rests))
   (begin
-(merge-rests rests rest-offset)
+(merge-rests rests (lambda (r) 0))
 ;; ly:grob-suicide! works nicely for dots, as opposed to  
rests.

 (if (pair? dots) (for-each ly:grob-suicide! (cdr dots)
   (if (has-at-least-two curr-mmrests)



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Allow a markup to replace the default LyricHyphen (issue 325470043 by knup...@gmail.com)

2017-10-04 Thread knupero 



Issue 1255 is: "#1255 Extract hyphen dimensions and/or hyphen glyph

from the

font "



Your patch does not extract hyphen dimensions or the hyphen glyph from

the font.

  It might get used for using the hyphen glyph (provided that you know

its

font-dependent character code) as a hyphen, so it might contribute to

deciding

to retire issue #1255 "Wontfix".



I opened a new issue 5210 and uploaded extended code for review.

So this issue here is dead.

https://codereview.appspot.com/325470043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: issue tracker write access

2017-10-04 Thread Phil Holmes 

Done.

--
Phil Holmes


- Original Message - 
From: "Malte Meyn" 

To: 
Sent: Wednesday, October 04, 2017 8:35 AM
Subject: issue tracker write access



Hello list,

too long I have waited but now I would like to start contributing to 
LilyPond. Currently I’m going through the “quick start” of the CG; could 
you please give me (maltem on SourceForge) write access to the issue 
tracker?


Cheers,
Malte

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

issue tracker write access

2017-10-04 Thread Malte Meyn 

Hello list,

too long I have waited but now I would like to start contributing to 
LilyPond. Currently I’m going through the “quick start” of the CG; could 
you please give me (maltem on SourceForge) write access to the issue 
tracker?


Cheers,
Malte

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel