> > . The CFF part of bigcheese20.otf is extracted and put into a PS
> > resource which is loaded with the -h option of dvips. If that
> > doesn't work, lilypond-book simply emits
> > \special{header=bigcheese.cff} at the beginning of the document.
I was a bit unclear. Here a reformulatio
Hello all,
A problem arises when you try to write tab's for 5-string banjos: the
fifth string starts at the 5th fret. This means that the "first fret"
on the fifth string is really the sixth fret on the neck. To solve
this I've made another tablatureFormat-function:
fret-number-tablature-format-ba
Hello,
Here's some trivial documentation patches:
doc-format-mark.patch:
document the new mark-formatter functions format-mark-box-letters and
format-mark-box-numbers.
doc-trivial.patch:
tchange comment from translator-property-description.scm to
define-context-properties.scm at top of file.
R
Hello Lilyponders
I've had a look at tab's, and I've made some trivial changes to a
couple of files. Here is a description of the patches (which are
attached):
tuning-triv.patch: (ly/engraver-init.ly and scm/output-lib.scm)
change the variable name guitar-tunings to guitar-tuning (because it
is _
Is this a bug, or an undocumented "feature"?
Lily 2.4.2, OSX. I have a global.ly, which contains
\layout{
\context { \Staff
\override TimeSignature #'style = #'numbered
}
}
In my actual piece, I use
\include "../global.ly"
\layout{
\context{
\RemoveEmptyStaffContext
}}
(which p
Maybe I used the wrong address the first time.
Sorry,
A.P.
Original Message
Subject: Yet another midi2ly
Date: Tue, 04 Jan 2005 00:38:49 +0100
From: Antonio PALAMA' <[EMAIL PROTECTED]>
To: Han-Wen Nienhuys <[EMAIL PROTECTED]>, Jan Nieuwenhuizen
<[EMAIL PROTECTED]>
Dear Auth
On Tue, 2005-01-04 at 23:29 +0100, Werner LEMBERG wrote:
> > > Owen, can you answer this, please? Since there are two mechanisms
> > > for kerning (the `kern' table and the `kern' feature in the GPOS
> > > table) I wonder how Pango is handling this.
> >
> > I won't say that I actually have plans
"GW" == George Williams writes:
>> Then they have to be there in the CFF separately. The H/D can be
>> different from the outlines, eg. due to overshoot.
GW> What do you mean by overshoot?
GW> Remember tfm metrics are not perfect. There are only 16 possible
GW> values for depth or height, an
On Tue, 2005-01-04 at 15:40, Han-Wen Nienhuys wrote:
> Then they have to be there in the CFF separately. The H/D can be
> different from the outlines, eg. due to overshoot.
What do you mean by overshoot?
Remember tfm metrics are not perfect. There are only 16 possible values
for depth or height,
On Tue, 2005-01-04 at 14:11, Han-Wen Nienhuys wrote:
> Hmm. I'd say it should contain all info from the TFM
>
> * metrics (these are entirely unrelated to the extents of the
> outlines)
The advance widths have their natural place.
Height/Depth information:
Per glyph Bounding box informat
> Remember tfm metrics are not perfect. There are only 16 possible
> values for depth or height, and one of these is required to be 0.
> So in a font with many different glyph sizes the tfm file has
> already done some kind of grouping operation which can lose a lot of
> information.
Whatever th
> > Owen, can you answer this, please? Since there are two mechanisms
> > for kerning (the `kern' table and the `kern' feature in the GPOS
> > table) I wonder how Pango is handling this.
>
> I won't say that I actually have plans for handling AFM files. I
> basically know how it would work: [...]
On 04 Jan 2005 08:04:23 -0800, George Williams <[EMAIL PROTECTED]> wrote:
> > Maybe these things ought to be discussed on the OpenType mailing list too?
> I brought up ITLC on the OpenType list some time ago, hoping to get it
> added to the standard feature list. I was unable to do so. Perhaps if
>
13 matches
Mail list logo
