Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by address@hidden)

[Carl . D . Sorensen]

The patch looks well put together.

However, I believe that the case problem with MacOS needs to be fixed.
I believe this patch won't work on MacOS -- only one version of the font
will be installed (the last one to be created).


https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):

https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(outdir) && mv $(notdir $@).otf $(notdir $@)
I think there is potential confusion where the CID file has no
extension, and  just has capitalization to indicate it.  Is this a
standard for CID-keyed fonts?

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in
File mf/emmentaler-brace.pe.in (right):

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in#newcode89
mf/emmentaler-brace.pe.in:89:
ConvertByCMap("/usr/share/ghostscript/9.23/Resource/CMap/Identity-H")
This hard-coded 9.23 seems to me to be broken in advance.

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in#newcode90
mf/emmentaler-brace.pe.in:90: Generate("Emmentaler-Brace.otf")
Will this work on MacOS?  IIRC, the default file system on MacOS is
case-insensitive, although it allows the used of mixed case.  THis means
you can have emmentaler-brace,otf or Emmentaler-Brace.otf, but I don't
think you can have both by default on MacOS.

For compatibility, I think there needs to be a different name.

Here's an example that shows the problem:

Carls-MBP:junk carlsorensen$ echo "This is a test" > test
Carls-MBP:junk carlsorensen$ cat test
This is a test
Carls-MBP:junk carlsorensen$ echo "This is an UpperCase test " > Test
Carls-MBP:junk carlsorensen$ cat Test
This is an UpperCase test
Carls-MBP:junk carlsorensen$ cat test
This is an UpperCase test

https://codereview.appspot.com/343970043/diff/1/ps/cidres.in
File ps/cidres.in (right):

https://codereview.appspot.com/343970043/diff/1/ps/cidres.in#newcode1
ps/cidres.in:1: lilypond-datadir (/fonts/otf/Emmentaler-11)
concatstrings (r) file .loadfont
The hardcoding of all the font sizes here seems broken.  If we change
the sizes to be generated from the .mf files; then this won't work any
more.  It seems there should be one variable that lists all of the sizes
to be generated, and that variable should be used throughout the build.

I guess that would meant that rather than having cidres.ps be a
developer-created file, there should be some kind of a template file and
a make command that would cat together cidres.ps using the template file
and the font size variable.

But recognizing that encodingdefs.ps doesn't follow this practice in the
current distribution, this comment may be without merit (or else it
would apply equally to encodingdefs.ps as well.

https://codereview.appspot.com/343970043/