Re: Add usage of OpenType font feature to the documents (issue 328140043 by truer...@gmail.com)

2017-07-31 Thread lemzwerg 

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)

2017-07-31 Thread tisimst . lilypond 

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)

2017-07-31 Thread lemzwerg 

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)

2017-07-31 Thread tisimst . lilypond 

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)

2017-07-31 Thread lemzwerg 

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 Thread Thomas Morley 
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)

2017-07-31 Thread tisimst . lilypond 

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

2017-07-31 Thread 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?

-- 
David Kastrup

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

Re: rest/mm-rest-markup

2017-07-31 Thread David Nalesnik 
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

2017-07-31 Thread David Kastrup 
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

2017-07-31 Thread Thomas Morley 
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)