Re: Simplify coord-rotate (issue 263690043 by d...@gnu.org)
Please disregard my code from comment #1, it's fishy. More appropiate would be (dropping the idea to rotate around other ponts than zero): #(define (get-PI/4-rotated-quadrants radians) (cond ((>= radians TWO-PI) (get-PI/4-rotated-quadrants (- radians TWO-PI))) ((< radians 0) (get-PI/4-rotated-quadrants (+ radians TWO-PI ))) (else (let* (;; get the octants (oct (truncate (/ radians (/ PI 4) ;; get the rotated quadrants (cond ((= oct 7) 0) ((even? oct) (/ oct 2)) (else (/ (1+ oct) 2))) (define-public (coord-rotate-p-II coordinate angle-in-radians) ;; getting around (sin PI) not being exactly zero by switching to cos at ;; appropiate angles and/or taking the negative value (vice versa for cos) (let* ((angle (angle-0-2pi angle-in-radians)) (quadrant (get-PI/4-rotated-quadrants angle)) (moved-angle (- angle (/ (* quadrant PI) 2))) (cm (cos moved-angle)) (sm (sin moved-angle)) (c (cond ((= 1 quadrant) (- sm)) ((= 2 quadrant) (- cm)) ((= 3 quadrant) sm) (else cm))) (s (cond ((= 1 quadrant) cm) ((= 2 quadrant) (- sm)) ((= 3 quadrant) (- cm)) (else sm))) (x (coord-x coordinate)) (y (coord-y coordinate))) (cons (- (* c x) (* s y)) (+ (* s x) (* c y) Maybe in a follow up? The patch itself LGTM https://codereview.appspot.com/263690043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify coord-rotate (issue 263690043 by d...@gnu.org)
Reviewers: thomasmorley651, Message: On 2015/10/15 12:34:17, thomasmorley651 wrote: Please disregard my code from comment #1, it's fishy. More appropiate would be (dropping the idea to rotate around other ponts than zero): #(define (get-PI/4-rotated-quadrants radians) (cond ((>= radians TWO-PI) (get-PI/4-rotated-quadrants (- radians TWO-PI))) ((< radians 0) (get-PI/4-rotated-quadrants (+ radians TWO-PI ))) (else (let* (;; get the octants (oct (truncate (/ radians (/ PI 4) ;; get the rotated quadrants (cond ((= oct 7) 0) ((even? oct) (/ oct 2)) (else (/ (1+ oct) 2))) (define-public (coord-rotate-p-II coordinate angle-in-radians) ;; getting around (sin PI) not being exactly zero by switching to cos at ;; appropiate angles and/or taking the negative value (vice versa for cos) (let* ((angle (angle-0-2pi angle-in-radians)) (quadrant (get-PI/4-rotated-quadrants angle)) (moved-angle (- angle (/ (* quadrant PI) 2))) (cm (cos moved-angle)) (sm (sin moved-angle)) (c (cond ((= 1 quadrant) (- sm)) ((= 2 quadrant) (- cm)) ((= 3 quadrant) sm) (else cm))) (s (cond ((= 1 quadrant) cm) ((= 2 quadrant) (- sm)) ((= 3 quadrant) (- cm)) (else sm))) (x (coord-x coordinate)) (y (coord-y coordinate))) (cons (- (* c x) (* s y)) (+ (* s x) (* c y) Maybe in a follow up? The patch itself LGTM I prefer a followup since this is a pretty hefty change with a different focus and warranting a separate Rietveld review. Description: Simplify coord-rotate This does not fix the problem that (sin PI) is not really zero because of the MPU working with higher precision than PI is specified, but at least it makes the code nicer to read and modify. Please review this at https://codereview.appspot.com/263690043/ Affected files (+7, -14 lines): M scm/lily-library.scm Index: scm/lily-library.scm diff --git a/scm/lily-library.scm b/scm/lily-library.scm index c5bf8cc59de12066e1f4bbf7e6aa88e321ef883e..0bfce9eb0c8a748099b3af053cf29d822de8a4b6 100644 --- a/scm/lily-library.scm +++ b/scm/lily-library.scm @@ -707,20 +707,13 @@ right (@var{dir}=+1)." (define-public (coord-scale coordinate amount) (coord-operation * amount coordinate)) -(define-public (coord-rotate coordinate degrees-in-radians) - (let* - ((coordinate -(cons - (exact->inexact (coord-x coordinate)) - (exact->inexact (coord-y coordinate - (radius -(sqrt - (+ (* (coord-x coordinate) (coord-x coordinate)) -(* (coord-y coordinate) (coord-y coordinate) - (angle (angle-0-2pi (atan (coord-y coordinate) (coord-x coordinate) -(cons - (* radius (cos (+ angle degrees-in-radians))) - (* radius (sin (+ angle degrees-in-radians)) +(define-public (coord-rotate coordinate angle) + (let ((c (cos angle)) +(s (sin angle)) +(x (coord-x coordinate)) +(y (coord-y coordinate))) +(cons (- (* c x) (* s y)) + (+ (* s x) (* c y) ;; trig ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond-mode in Emacs
Hi, there are a few changes in Emacs-mode that need to be done and stuff that needs to be cleaned/fixed. I don't have what it takes to do this with large amounts of backward-compatibility in mind (and that includes XEmacs which, all-in-all, uses quite older versions and APIs of generic functions). As one data point, I don't want to cater for Emacs versions not supporting lexical-binding (available as of Emacs 24.1) when writing new code as not being able to use closures is a real nuisance. In the medium range, I want to move LilyPond-mode to ELPA (the official package archive of Emacs) as installing packages via ELPA rather than via our own build procedure is more reliable and I have my doubts that our binary installers have much of a chance to install Emacs modes anyway. That means that without additional care, XEmacs+LilyPond will fall victim to bitrot. However, that's preferable to LilyPond-mode falling victim to bitrot on all platforms. Is that ok with people? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Cropped SVG Output
Hello all, I'm writing a Lilypond plugin for Sphinx and I'd like to use the SVG output to embed the lilypond output into html files. Compared to PNG embedding, SVG will allow a single webpage to look crisp on many different devices and minimizes the bandwidth necessary on clients. The problem I'm running into is that the SVG output option produces a SVG file with a length and width of the entire page that I'm trying to render. The PNG output, on the other hand, crops the score to the area with visible elements on it. Of course, when embedding, I'm looking for a visible area crop. Does anyone know if a cropped SVG output is possible? One solution is to manually specify the page height to how tall I think the score is going to be. I'd prefer an automated solution since presumably lilypond already knows how to calculate the height of the visible area. framework-svg.scm has the following code: (define (dump-page paper filename page page-number page-count) (let* ((outputter (ly:make-paper-outputter (open-file filename "wb") 'svg)) (dump (lambda (str) (display str (ly:outputter-port outputter (lookup (lambda (x) (ly:output-def-lookup paper x))) (unit-length (lookup 'output-scale)) (output-scale (* lily-unit->mm-factor unit-length)) (device-width (lookup 'paper-width)) (device-height (lookup 'paper-height)) (page-width (* output-scale device-width)) (page-height (* output-scale device-height))) Here "paper-width" is being looked up and used for configuring the width and height of the SVG element as well as the width and height of the viewBox. How would I get the width and height of the visual area over here? Any other suggestions as to how I could add a visible-area SVG output option? Thanks in advance for any help, David Sankel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cropped SVG Output
Il giorno gio 15 ott 2015 alle 22:10, David Sankel ha scritto: I'm writing a Lilypond plugin for Sphinx and I'd like to use the SVG output to embed the lilypond output into html files. Compared to PNG embedding, SVG will allow a single webpage to look crisp on many different devices and minimizes the bandwidth necessary on clients. do you know that someone wrote a lilypond plugin sometime ago (it's on bitbucket)? probably not maintained anymore The problem I'm running into is that the SVG output option produces a SVG file with a length and width of the entire page that I'm trying to render. The PNG output, on the other hand, crops the score to the area with visible elements on it. Of course, when embedding, I'm looking for a visible area crop. Does anyone know if a cropped SVG output is possible? yes, try: lilypond -dpreview -dbackend=svg test.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cropped SVG Output
Am 16.10.2015 um 08:40 schrieb Federico Bruni: > yes, try: > > lilypond -dpreview -dbackend=svg test.ly > But doesn't this output the first system only? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel