Add sans-serif and monospace fonts

Add sans-serif and monospace fonts

Nimbus Sans L (Helvetica substitute) as sans-serif font.
Nimbus Mono L (Courier substitute) as monospace font.

[pkx166h, 2015-03-31 09:37:52]

Patch on countdown for April 3rd

[dak, 2015-03-31 15:57:54]

Shouldn't we rather be selecting the Courier and Helvetica fonts (standard
PostScript) and rely on GhostScript and/or font installation to cater for the
font substitution to Nimbus when required?

That's not a rhetorical question: I don't know the answer myself.

[c_sorensen, 2015-03-31 22:18:11]

On 2015/03/31 15:57:54, dak wrote:
> Shouldn't we rather be selecting the Courier and Helvetica fonts (standard
> PostScript) and rely on GhostScript and/or font installation to cater for the
> font substitution to Nimbus when required?
> 
> That's not a rhetorical question: I don't know the answer myself.

IIUC, the problem that we had was that the font installations for some systems
did not include ligatures, so we proposed to make a selection, rather than
allowing the system default to apply.

[dak, 2015-04-01 05:33:59]

On 2015/03/31 22:18:11, c_sorensen wrote:
> On 2015/03/31 15:57:54, dak wrote:
> > Shouldn't we rather be selecting the Courier and Helvetica fonts (standard
> > PostScript) and rely on GhostScript and/or font installation to cater for
the
> > font substitution to Nimbus when required?
> > 
> > That's not a rhetorical question: I don't know the answer myself.
> 
> IIUC, the problem that we had was that the font installations for some systems
> did not include ligatures, so we proposed to make a selection, rather than
> allowing the system default to apply.

The PostScript default fonts have well-defined metrics including ligatures. 
That's different from a non-specific "system default font" according to Pango. 
At least it _should_ be different.  I was not talking about asking Pango for
"Sans" or "Fixed", but for "Helvetica" and "Courier".

PostScript is required to do something with that request that at least results
in well-known font metrics.  I don't know whether Pango is similarly
well-defined for that request, however.

[trueroad, 2015-04-01 10:35:03]

On 2015/04/01 05:33:59, dak wrote:
> On 2015/03/31 22:18:11, c_sorensen wrote:
> > On 2015/03/31 15:57:54, dak wrote:
> > > Shouldn't we rather be selecting the Courier and Helvetica fonts (standard
> > > PostScript) and rely on GhostScript and/or font installation to cater for
> the
> > > font substitution to Nimbus when required?
> > > 
> > > That's not a rhetorical question: I don't know the answer myself.
> > 
> > IIUC, the problem that we had was that the font installations for some
systems
> > did not include ligatures, so we proposed to make a selection, rather than
> > allowing the system default to apply.
> 
> The PostScript default fonts have well-defined metrics including ligatures. 
> That's different from a non-specific "system default font" according to Pango.

> At least it _should_ be different.  I was not talking about asking Pango for
> "Sans" or "Fixed", but for "Helvetica" and "Courier".
> 
> PostScript is required to do something with that request that at least results
> in well-known font metrics.  I don't know whether Pango is similarly
> well-defined for that request, however.

In my perception, pango requires actual font file (.otf, .pfb etc.).
If there is no font files, pango can't render anything.
Even if there is only font metric files (.afm, .pfm, .tfm etc.),
pango can't handle it.

Moreover, in my experiment,
pango can't handle the ligature of PostScript Type1 font (.pfb with .afm or
.pfm).
It can handle the ligature of OpenType font (.otf).

[dak, 2015-04-01 18:46:34]

On 2015/04/01 10:35:03, trueroad wrote:
> On 2015/04/01 05:33:59, dak wrote:
> > On 2015/03/31 22:18:11, c_sorensen wrote:
> > > On 2015/03/31 15:57:54, dak wrote:
> > > > Shouldn't we rather be selecting the Courier and Helvetica fonts
(standard
> > > > PostScript) and rely on GhostScript and/or font installation to cater
for
> > the
> > > > font substitution to Nimbus when required?
> > > > 
> > > > That's not a rhetorical question: I don't know the answer myself.
> > > 
> > > IIUC, the problem that we had was that the font installations for some
> systems
> > > did not include ligatures, so we proposed to make a selection, rather than
> > > allowing the system default to apply.
> > 
> > The PostScript default fonts have well-defined metrics including ligatures. 
> > That's different from a non-specific "system default font" according to
Pango.
> 
> > At least it _should_ be different.  I was not talking about asking Pango for
> > "Sans" or "Fixed", but for "Helvetica" and "Courier".
> > 
> > PostScript is required to do something with that request that at least
results
> > in well-known font metrics.  I don't know whether Pango is similarly
> > well-defined for that request, however.
> 
> In my perception, pango requires actual font file (.otf, .pfb etc.).
> If there is no font files, pango can't render anything.
> Even if there is only font metric files (.afm, .pfm, .tfm etc.),
> pango can't handle it.
> 
> Moreover, in my experiment,
> pango can't handle the ligature of PostScript Type1 font (.pfb with .afm or
> .pfm).
> It can handle the ligature of OpenType font (.otf).

What a mess.  Well, since we do the font handling with Pango, we have to make do
with its limitations.  I'd have thought that a sensible Pango design would have
gotten by with at most a .afm file for producing PostScript files without
embedded fonts but using PostScript standard fonts.

If that's not the case, and if we even need to provide a .otf font, I don't see
much of an option around using a free font like Nimbus.

[wl_gnu.org, 2015-04-02 04:29:07]

>> Moreover, in my experiment, pango can't handle the ligature of
>> PostScript Type1 font (.pfb with .afm or .pfm).  It can handle the
>> ligature of OpenType font (.otf).

If you assumption is correct, this is clearly a bug.  Looking into the
source code of Pango, I can't find a reference to the string AFM at
all; similarly, the GNOME bug tracker doesn't contain the string AFM
either.

> I'd have thought that a sensible Pango design would have gotten by
> with at most a .afm file for producing PostScript files without
> embedded fonts but using PostScript standard fonts.

Indeed.


    Werner

[pkx166h, 2015-04-03 13:02:31]

This looks like this still needs some review - I'll leave this on countdown for
now, if it needs work can someone set this to needs_work and update the rietveld
accordingly.

[trueroad, 2015-04-05 04:00:43]

On 2015/04/02 04:29:07, wl_gnu.org wrote:
> >> Moreover, in my experiment, pango can't handle the ligature of
> >> PostScript Type1 font (.pfb with .afm or .pfm).  It can handle the
> >> ligature of OpenType font (.otf).
> 
> If you assumption is correct, this is clearly a bug.  Looking into the
> source code of Pango, I can't find a reference to the string AFM at
> all; similarly, the GNOME bug tracker doesn't contain the string AFM
> either.

At least, this patch uses OpenType fonts
rather than PostScript Type1 fonts.
Therefore, it is not affected by the Pango's bug.

In addition, the default serif font of current lilypond is
OpenType converted "Century Schoolbook L".
It is a substitute font of
PostScript standard font "New Century Schoolbook".

This patch is same approach for sans-serif and monospace.

[pkx166h, 2015-04-06 12:49:01]

Patch counted down - but at David K's request (and dev agreement) this will not
be set to Push until next countdown so it can be reviewed on 7th/8th Apr.

[dak, 2015-04-07 16:04:27]

https://codereview.appspot.com/224800043/diff/1/config.make.in
File config.make.in (right):

https://codereview.appspot.com/224800043/diff/1/config.make.in#newcode97
config.make.in:97: COUR_DIR = @COUR_DIR@
It seems a bit excessive to point separately to the font files for all of New
Century Schoolbook, Helvetica, and Courier.

Wouldn't it make more sense to have one setting for all of the included fonts? 
Are there really circumstances where we can expect all of these to be different?

[dak, 2015-04-07 16:07:49]

https://codereview.appspot.com/224800043/diff/1/scripts/auxiliar/pfx2ttf-mono...
File scripts/auxiliar/pfx2ttf-mono.fontforge (right):

https://codereview.appspot.com/224800043/diff/1/scripts/auxiliar/pfx2ttf-mono...
scripts/auxiliar/pfx2ttf-mono.fontforge:17: # Monospace font shouldn't have
these ligature.
The file in its proposed state talks about both "Monospace" as well as "New
Century Schoolbook".  I should think that one of those would be inaccurate.

[lemzwerg, 2015-04-07 18:19:25]

> Wouldn't it make more sense to have one setting for all
> of the included fonts? Are there really circumstances
> where we can expect all of these to be different?

Probably not.  I think that the patch is a proof of concept, and we should
comment on it.

[trueroad, 2015-04-08 11:03:28]

On 2015/04/07 16:07:49, dak wrote:
>
https://codereview.appspot.com/224800043/diff/1/scripts/auxiliar/pfx2ttf-mono...
> File scripts/auxiliar/pfx2ttf-mono.fontforge (right):
> 
>
https://codereview.appspot.com/224800043/diff/1/scripts/auxiliar/pfx2ttf-mono...
> scripts/auxiliar/pfx2ttf-mono.fontforge:17: # Monospace font shouldn't have
> these ligature.
> The file in its proposed state talks about both "Monospace" as well as "New
> Century Schoolbook".  I should think that one of those would be inaccurate.

Century Schoolbook L (New Century Schoolbook) is converted by conventional
pfx2ttf.fontforge.
https://codereview.appspot.com/224800043/diff/1/mf/GNUmakefile#newcode178

Nimbus Sans L (Helvetica) is also converted by conventional pfx2ttf.fontforge.
https://codereview.appspot.com/224800043/diff/1/mf/GNUmakefile#newcode189

This patch doesn't modify pfx2ttf.fontforge.

Nimbus Mono L (Courier) is only converted by new pfx2ttf-mono.fontforge.
https://codereview.appspot.com/224800043/diff/1/mf/GNUmakefile#newcode200

[trueroad, 2015-04-08 11:05:32]

On 2015/04/07 18:19:25, lemzwerg wrote:
> > Wouldn't it make more sense to have one setting for all
> > of the included fonts? Are there really circumstances
> > where we can expect all of these to be different?
> 
> Probably not.  I think that the patch is a proof of concept, and we should
> comment on it.

I also think that those font files are in the same directory.

I'll integrate the font directory specified options.
For example,
  from --with-ncsb-dir, --with-helv-dir, --with-cour-dir
  to --with-fonts-dir

[trueroad, 2015-04-08 13:44:05]

Integrate fonts dir configure options

[trueroad_sea.plala.or.jp, 2015-04-08 14:09:34]

> I'll integrate the font directory specified options.
> For example,
>   from --with-ncsb-dir, --with-helv-dir, --with-cour-dir
>   to --with-fonts-dir

I've done.
Patch Set 2 has been uploaded.

https://codereview.appspot.com/224800043/
http://code.google.com/p/lilypond/issues/detail?id=4332

[pkx166h, 2015-04-08 16:45:37]

Passes make, make check and a full make doc.

Reg test diffs here:

https://drive.google.com/file/d/0B9nZ5LHV2Ds6R3pUdHNpMkhVZEU/view?usp=sharing

[dak, 2015-04-08 18:07:06]

On 2015/04/08 16:45:37, J_lowe wrote:
> Passes make, make check and a full make doc.
> 
> Reg test diffs here:
> 
> https://drive.google.com/file/d/0B9nZ5LHV2Ds6R3pUdHNpMkhVZEU/view?usp=sharing

Facepalm.  It would appear that we previously just got some random platform
dependent font for chord names and some other stuff.  Quite embarrassing.  And
some of those diff originals look a bit like the font glyphs don't match the
metrics perfectly.  Or just don't have all that good metrics.  I like the
current overall look for _this_ choice of fonts better afterwards as compared to
before, even though the "C" glyph has a more conspicuous rounding and the "G"
glyph has the well-known somewhat poignant Helvetica shape.

It's a pity that Pango does not seem to support some setup where there would be
a graceful upgradation to the identically-metriced Helvetica when available:
many professional printers/publishers have the original Helvetica readily
available in their setup.

[lemzwerg, 2015-04-08 20:18:55]

> I like the current overall look for _this_ choice of fonts
> better afterwards as compared to before, even though the "C"
> glyph has a more conspicuous rounding and the "G" glyph has
> the well-known somewhat poignant Helvetica shape.

Yes, it's more consistent.  On the other hand, I very much dislike Helvetica,
and maybe there's a better choice eventually...

> It's a pity that Pango does not seem to support some setup
> where there would be a graceful upgradation to the
> identically-metriced Helvetica when available:
> many professional printers/publishers have the original
> Helvetica readily available in their setup.

It's not clear to me what you expect and how it should work.

[dak, 2015-04-09 05:14:59]

On 2015/04/08 20:18:55, lemzwerg wrote:
> > I like the current overall look for _this_ choice of fonts
> > better afterwards as compared to before, even though the "C"
> > glyph has a more conspicuous rounding and the "G" glyph has
> > the well-known somewhat poignant Helvetica shape.
> 
> Yes, it's more consistent.  On the other hand, I very much dislike Helvetica,
> and maybe there's a better choice eventually...
> 
> > It's a pity that Pango does not seem to support some setup
> > where there would be a graceful upgradation to the
> > identically-metriced Helvetica when available:
> > many professional printers/publishers have the original
> > Helvetica readily available in their setup.
> 
> It's not clear to me what you expect and how it should work.

Letting PostScript ask for Helvetica which will let GhostScript fall back to the
URW version when the original Helvetica is not available.  If I understand
correctly, we currently ask for and embed the URW version.  But maybe printers
have their own way to resubstitute the original.  No idea.

[lemzwerg, 2015-04-09 05:32:28]

> Letting PostScript ask for Helvetica which will let GhostScript
> fall back to the URW version when the original Helvetica is not
> available.  If I understand correctly, we currently ask for and
> embed the URW version.  But maybe printers have their own way
> to resubstitute the original.  No idea.

Today, it is very important to *embed* fonts since the world has changed from PS
to PDF, and assuming that the original PS fonts are available everywhere is no
longer true.  So asking for and embedding the free URW fonts is the right way to
go.

An additional bonus is that the URW fonts come with more glyphs than the
original Adobe fonts.  Additionally, Adobe itself distributed multiple variants
of its core PS fonts, depending on the locale – for example, I have the AFM
files for the font versions with 229 and 313 glyphs, respectively.  In summary,
there is no such thing as the `original Helvetica' that works everywhere as soon
as you are using some non-ASCII glyphs...

[simon.albrecht, 2015-04-09 09:01:44]

Am 09.04.2015 um 07:14 schrieb dak@gnu.org:
> On 2015/04/08 20:18:55, lemzwerg wrote:
>> > I like the current overall look for _this_ choice of fonts
>> > better afterwards as compared to before, even though the "C"
>> > glyph has a more conspicuous rounding and the "G" glyph has
>> > the well-known somewhat poignant Helvetica shape.
>
>> Yes, it's more consistent.  On the other hand, I very much dislike
> Helvetica,
>> and maybe there's a better choice eventually...
>
>> > It's a pity that Pango does not seem to support some setup
>> > where there would be a graceful upgradation to the
>> > identically-metriced Helvetica when available:
>> > many professional printers/publishers have the original
>> > Helvetica readily available in their setup.
>
>> It's not clear to me what you expect and how it should work.
>
> Letting PostScript ask for Helvetica which will let GhostScript fall
> back to the URW version when the original Helvetica is not available.
> If I understand correctly, we currently ask for and embed the URW
> version.  But maybe printers have their own way to resubstitute the
> original.
I don’t get your point here. Don’t we have convenient mechanisms to 
select other fonts than default?
\paper {
   fonts = #(set-global-fonts #:sans "Helvetica")
}
This isn’t documented but in 
<http://fonts.openlilylib.org/docs.html#how-to-use>, though. Can the 
same be done with make-pango-font-tree (i.e. retain the default fonts 
except for sans)?

Yours, Simon

[dak, 2015-04-09 09:36:33]

Simon Albrecht <simon.albrecht@mail.de> writes:

> Am 09.04.2015 um 07:14 schrieb dak@gnu.org:
>> On 2015/04/08 20:18:55, lemzwerg wrote:
>>
>>> It's not clear to me what you expect and how it should work.
>>
>> Letting PostScript ask for Helvetica which will let GhostScript fall
>> back to the URW version when the original Helvetica is not available.
>> If I understand correctly, we currently ask for and embed the URW
>> version.  But maybe printers have their own way to resubstitute the
>> original.
> I don’t get your point here. Don’t we have convenient mechanisms to
> select other fonts than default?
> \paper {
>   fonts = #(set-global-fonts #:sans "Helvetica")
> }

The idea was to get optimal results from a clueless user delivering
default content to a clueless publisher/printer using standard (and
probably expensive) equipment.

I've had some publishing project where the default layout specs called
for "Arial".  Which is actually a non-trivial feat to produce using TeX.
When looking at example printed drafts from the publisher providing the
specifications however (rather than the DOC files produced according to
specs), it became obvious that "Arial" was just an intermediary and
would have been substituted by Helvetica anyway at the printing stage.

Now I don't want to suggest that LilyPond should produce DOC files using
Arial (Bach forbid) but getting as close as possible to the workflow of
the clueless anticipated by the provider of professional tools seems
advisable.

I just don't have an idea what that workflow would actually be.

-- 
David Kastrup

[pkx166h, 2015-04-12 10:06:27]

OK this still needs discussion I think. I'll leave it on review.

[dak, 2015-04-12 10:20:42]

On 2015/04/12 10:06:27, J_lowe wrote:
> OK this still needs discussion I think. I'll leave it on review.

Oh, I don't think the patch still needs discussion: the discussion was all
rather theoretical, more circled around how awful other software writers are
than being able to come up with the concrete improvement to this patch.

[pkx166h, 2015-04-15 22:42:27]

Patch on countdown for April 18th

[pkx166h, 2015-04-18 08:43:13]

Patch counted down - please push

[pkx166h, 2015-04-18 14:17:02]

author	Masamichi Hosoda <trueroad@sea.plala.or.jp>	
	Sat, 18 Apr 2015 14:10:06 +0000 (15:10 +0100)
committer	James Lowe <pkx166h@gmail.com>	
	Sat, 18 Apr 2015 14:15:18 +0000 (15:15 +0100)
commit	af1b0da3853670ee559e148cea70535d5f6ac716