Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)
I'm not aware of such an online tool. I've posted a question on Typedrawers. http://typedrawers.com/discussion/2292/list-of-opentype-font-feature-inspection-tools At least for the command line I got the right information! Given that many people already have TeXLive installed, the `otfinfo' program is already available and does the right thing. It can also be downloaded separately from https://www.lcdf.org/type/ However, I haven't yet got a point for something that does the same with a GUI or online. https://codereview.appspot.com/328140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)
On 2017/07/31 17:48:10, lemzwerg wrote: > If Pango really is agnostic of the features, that is really exciting and a bit > mysterious ;-). Why? It's not Pango but HarfBuzz that processes (i.e., applies) the OpenType features to a run of glyphs. Ah, I see! Thanks for clarifying that. I didn't realize Harfbuzz was part of the picture. Guess I haven't looked deep enough into the code. https://codereview.appspot.com/328140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)
If Pango really is agnostic of the features, that is really exciting and a bit mysterious ;-). Why? It's not Pango but HarfBuzz that processes (i.e., applies) the OpenType features to a run of glyphs. Perhaps a note should be added, though, to mention that if the user requests a feature that doesn't exist in the chosen font, then the feature is simply ignored. Yep. Is there a web-based tool that can do this? That'd eliminate the need to install another app just to inspect a font's features. I use FontForge all the time, so I understand how to do it, but a "normal" user probably won't have a font editor. I'm not aware of such an online tool. I've posted a question on Typedrawers. http://typedrawers.com/discussion/2292/list-of-opentype-font-feature-inspection-tools https://codereview.appspot.com/328140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)
On 2017/07/31 16:58:40, lemzwerg wrote: In general, Pango is agnostic of the features themselves, AFAIK. It simply forwards the selected stuff to the font in question. If Pango really is agnostic of the features, that is really exciting and a bit mysterious ;-). However, the user has first to look up what the font he or she wants to use actually supports, but this is not lilypond's job. Oh, I get that. Perhaps a note should be added, though, to mention that if the user requests a feature that doesn't exist in the chosen font, then the feature is simply ignored. What could be added, though, is a link to such a font inspection tool that reports the font's OpenType capabilities (i.e., supported scripts, languages, features). Sounds good to me! Is there a web-based tool that can do this? That'd eliminate the need to install another app just to inspect a font's features. I use FontForge all the time, so I understand how to do it, but a "normal" user probably won't have a font editor. https://codereview.appspot.com/328140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)
This is really great! Do you happen know what the current limitations are? Or rather, having the full feature list is great, but if only a few features are actually recognized by the underlying typography engine (it's still Pango, right?), that would probably be a better list to show, unless they're all recognized, of course. In general, Pango is agnostic of the features themselves, AFAIK. It simply forwards the selected stuff to the font in question. However, the user has first to look up what the font he or she wants to use actually supports, but this is not lilypond's job. What could be added, though, is a link to such a font inspection tool that reports the font's OpenType capabilities (i.e., supported scripts, languages, features). https://codereview.appspot.com/328140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rest/mm-rest-markup
2017-07-31 18:09 GMT+02:00 David Kastrup : > David Nalesnik writes: > >> On Mon, Jul 31, 2017 at 9:08 AM, David Kastrup wrote: >>> Thomas Morley writes: >>> Hi David, this refers to http://lists.gnu.org/archive/html/lilypond-devel/2017-07/msg00144.html I opened a new thread, because this one will be about rest-markups only. rest-by-number-markup and rest-markup were impemented by myself commit ffa21bb1a55d2436bb432c4dff7ec04df95dc6f0 My second patch at all. >>> >>> Ah, I thought that it wasn't quite in the line of code I see you doing >>> these days. A few corners looked like copying idioms of David Nalesnik >>> in cases for which they appeared overengineered. >> >> Goodness! Hopefully, I'm not as guilty of "open coding" these days. > > Anybody else needs his toes stepped on while I'm on a run? rofl More seriously. I learned a lot studying your code, David N and David K and from several others. And I plan to continue this behaviour ;) Best, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)
On 2017/07/27 13:47:01, trueroad wrote: Thank you for your reviewing. https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely File Documentation/changes.tely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/changes.tely#newcode1037 Documentation/changes.tely:1037: On 2017/07/26 20:09:33, lemzwerg wrote: > It would be nice to have an example of a feature that needs an index (e.g., the > `salt' or `swsh' features). Done. https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.itely File Documentation/notation/text.itely (right): https://codereview.appspot.com/328140043/diff/1/Documentation/notation/text.itely#newcode1464 Documentation/notation/text.itely:1464: On 2017/07/26 15:38:12, pkx166h wrote: > Would it be appropriate to add something after this @lilypond example like: > > For the full OpenType font feature list please see: > > @uref{https://www.microsoft.com/typography/otspec/featurelist.htm} > > Otherwise LGTM Done. This is really great! Do you happen know what the current limitations are? Or rather, having the full feature list is great, but if only a few features are actually recognized by the underlying typography engine (it's still Pango, right?), that would probably be a better list to show, unless they're all recognized, of course. https://codereview.appspot.com/328140043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rest/mm-rest-markup
David Nalesnik writes: > On Mon, Jul 31, 2017 at 9:08 AM, David Kastrup wrote: >> Thomas Morley writes: >> >>> Hi David, >>> >>> this refers to >>> http://lists.gnu.org/archive/html/lilypond-devel/2017-07/msg00144.html >>> I opened a new thread, because this one will be about rest-markups only. >>> >>> rest-by-number-markup and rest-markup were impemented by myself >>> commit ffa21bb1a55d2436bb432c4dff7ec04df95dc6f0 >>> My second patch at all. >> >> Ah, I thought that it wasn't quite in the line of code I see you doing >> these days. A few corners looked like copying idioms of David Nalesnik >> in cases for which they appeared overengineered. > > Goodness! Hopefully, I'm not as guilty of "open coding" these days. Anybody else needs his toes stepped on while I'm on a run? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rest/mm-rest-markup
On Mon, Jul 31, 2017 at 9:08 AM, David Kastrup wrote: > Thomas Morley writes: > >> Hi David, >> >> this refers to >> http://lists.gnu.org/archive/html/lilypond-devel/2017-07/msg00144.html >> I opened a new thread, because this one will be about rest-markups only. >> >> rest-by-number-markup and rest-markup were impemented by myself >> commit ffa21bb1a55d2436bb432c4dff7ec04df95dc6f0 >> My second patch at all. > > Ah, I thought that it wasn't quite in the line of code I see you doing > these days. A few corners looked like copying idioms of David Nalesnik > in cases for which they appeared overengineered. Goodness! Hopefully, I'm not as guilty of "open coding" these days. DN ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: rest/mm-rest-markup
Thomas Morley writes: > Hi David, > > this refers to > http://lists.gnu.org/archive/html/lilypond-devel/2017-07/msg00144.html > I opened a new thread, because this one will be about rest-markups only. > > rest-by-number-markup and rest-markup were impemented by myself > commit ffa21bb1a55d2436bb432c4dff7ec04df95dc6f0 > My second patch at all. Ah, I thought that it wasn't quite in the line of code I see you doing these days. A few corners looked like copying idioms of David Nalesnik in cases for which they appeared overengineered. > I saw no reason to distuingish rest and mm-rest in markup-mode, as we > need to do in music (one is an item the other a spanner). Hence I've > put them all in one markup-command. Where is the point in having one markup-command that needs a flag to distinguish two different cases that are so fundamentally different that they even take different arguments? Now the thing is that with the new change in place, we would not necessarily _need_ different arguments: an integral multiplier larger than 1 could be taken as a multi-measure rest count, like {1*4} So we likely _could_ get away with a single command: multipliers don't seem to make much sense in the context of markup rests. I am not sure that is a good idea, though. rest-markup would then have a convenient way of its own to flag multimeasure rests while rest-by-number-markup could not make use of it. > Nevertheless, attached you'll find a first attempt to disentangle > them. > > What do you think? I have to take a look first. I've been dry-musing yet. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
rest/mm-rest-markup
Hi David, this refers to http://lists.gnu.org/archive/html/lilypond-devel/2017-07/msg00144.html I opened a new thread, because this one will be about rest-markups only. rest-by-number-markup and rest-markup were impemented by myself commit ffa21bb1a55d2436bb432c4dff7ec04df95dc6f0 My second patch at all. I saw no reason to distuingish rest and mm-rest in markup-mode, as we need to do in music (one is an item the other a spanner). Hence I've put them all in one markup-command. Nevertheless, attached you'll find a first attempt to disentangle them. What do you think? Cheers, Harm \version "2.19.64" #(use-modules (ice-9 regex)) %% to make things work here, 'parse-simple-duration' is not public #(define parse-simple-duration (@@ (lily) parse-simple-duration)) %% changed rest-markup #(define-markup-command (rest layout props duration) (string?) #:category music #:properties ((style '()) (word-space 0.6)) ;; No need to check `duration' for validity, `parse-simple-duration' will ;; throw an error in this case anyway (let* (;; Get a (log dots) list. (parsed (parse-simple-duration duration))) (rest-by-number-markup layout props (car parsed) (cadr parsed %% new mm-rest-markup #(define-markup-command (mm-rest layout props duration) (string?) #:category music #:properties ((style '()) (multi-measure-rest-number #t) (word-space 0.6)) ;; Get the number of mmr-glyphs. ;; Store them in a list. ;; example: (mmr-numbers 25) -> '(3 0 0 1) (define (mmr-numbers nmbr) (define (helper i init ls) (if (not (integer? init)) (reverse ls) (helper (remainder i init) (/ init 2) (cons (floor (/ i init)) ls ;; helper is called with the longest mmr-glyph-duration, i.e. 'init = 8' (helper nmbr 8 '())) ;; Get the correct mmr-glyphs. ;; Store them in a list. ;; example: ;; (get-mmr-glyphs '(1 0 1 0) '("rests.M3" "rests.M2" "rests.M1" "rests.0")) ;; -> ("rests.M3" "rests.M1") (define (get-mmr-glyphs lst1 lst2) (append-map! make-list lst1 lst2)) ;; If duration is not valid, print a warning and return empty-stencil (if (not (and (integer? (string->number duration)) (exact? (string->number duration (begin (ly:warning (_ "not a valid duration string: ~a - ignoring") duration) empty-stencil) (let* ((dur (string->number duration)) ;; Get a list of the correct number of each mmr-glyph. (count-mmr-glyphs-list (mmr-numbers dur)) ;; Create a list of mmr-stencils, ;; translating the glyph for a whole rest. (mmr-stils-list (map (lambda (x) (let ((single-mmr-stil (interpret-markup layout props (make-override-markup (cons 'multi-measure-rest #t) (make-rest-by-number-markup (* -1 x) 0) (if (= x 0) (ly:stencil-translate-axis single-mmr-stil ;; Ugh, hard-coded, why 1? 1 Y) single-mmr-stil))) (get-mmr-glyphs count-mmr-glyphs-list (iota 4 3 -1 ;; Adjust the space between the mmr-glyphs, ;; if not default-glyphs are used. (word-space (if (member style '(neomensural mensural petrucci)) (/ (* word-space 2) 3) word-space)) ;; Create the final mmr-stencil ;; via `stack-stencil-lineĀ“ from /scm/markup.scm (mmr-stil (stack-stencil-line word-space mmr-stils-list))) ;; Print the number above a multi-measure-rest ;; Depends on duration, style and multi-measure-rest-number set #t (if (and multi-measure-rest-number (> dur 1) (not (member style '(neomensural mensural petrucci (let* ((mmr-stil-x-center (interval-center (ly:stencil-extent mmr-stil X))) (duration-markup (markup #:fontsize -2 #:override '(font-encoding . fetaText) duration)) (mmr-number-stil (interpret-markup layout props duration-markup)) (mmr-number-stil-x-center (interval-center (ly:stencil-extent mmr-number-stil X (set! mmr-stil (ly:stencil-combine-at-edge mmr-stil Y UP (ly:stencil-translate-axis mmr-number-stil (- mmr-stil-x-center mmr-number-stil-x-center)