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

[knupero]

Answers to comments.


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 $@)
On 2018/05/26 16:25:25, lemzwerg wrote:
> On 2018/05/26 15:17:09, Carl wrote:
> > 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?

> Actually, it is, but I don't see a reason to not use `.cid' as an
extension.

Done.

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#newcode90
mf/emmentaler-brace.pe.in:90: Generate("Emmentaler-Brace.otf")
On 2018/05/26 15:17:09, Carl wrote:
> 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

Done.

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
On 2018/05/26 15:17:09, Carl wrote:
> 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.

Yes. But as I doubt that anyone will change the design sizes in the next
decade I think I postpone a fix.

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

https://codereview.appspot.com/343970043/diff/40001/mf/GNUmakefile#newcode183
mf/GNUmakefile:183: echo XXXX $(TEXGYRE_DIR)/texgyreschola-regular.otf
YYY
On 2018/05/30 04:31:54, lemzwerg wrote:
> This looks like a debug message, probably to be removed (or
improved)...

Done.

https://codereview.appspot.com/343970043/diff/40001/mf/GNUmakefile#newcode201
mf/GNUmakefile:201: otfinfo -u $(TEXGYRE_DIR)/texgyreschola-regular.otf
| \
On 2018/05/30 04:31:54, lemzwerg wrote:
> I suggest to start a line with the pipe symbol:

>      foo \
>      | bar

Done.

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