OTC support [was: Still cannot make doc :(]

[Werner LEMBERG]

> I think make doc uses --bigpdf and some sort of PDF postprocessing.
> Maybe one needs that to reproduce?

Here's a more detailed analysis of the problem regarding OpenType
collections.

I've just tried to compile this snippet

  \version "2.19.40"

  \markup {
   \override #'(font-name . "Noto Sans Mono CJK KR")
    \column {
      "First line"
      "Japanese: 日本語のページを検索"
      "Last line" } }

with

  lilypond --ps -o notolily notolily.ly

[`Noto Sans Mono CJK KR' is the subfont with index 5 in the
`NotoSansCJK-Regular.ttc' font.]

From the large PS output file I've then extracted the Noto T42 font
(i.e., the stuff between the first `%%BeginFont' ... `%%EndFont'
lines) into `notolily.t42' to test it with a self-compiled ftview that
contains debugging support.

I was very surprised that FreeType's `ftview' program couldn't open
the T42 font!  A closer look revealed that the `CharStrings'
dictionary entries are non-standard.  Instead of

  /foo 12345 def

format it uses

  (foo) cvn 12345 def

which I've never seen before in a T42 font (it's fully valid,
however).

Looking up the reason for this I found

  commit dbe720d6a2e6cbb1e60160c8d04a4d7ac658ac1d
  Author: Jan Nieuwenhuizen <address@hidden>
  Date:   Sun May 29 11:41:15 2011 +0200

      Allow for spaces in ttf font glyph names.  Fixes #1562.

      Apparently, the Verdana.ttf font that comes with Windows 7 SP1
      has glyphs 571 and 571 using names "glyph 571" and "glyph 572", i.e.,
      their glyph names contain spaces.  This breaks the PostScript output.

This somehow completely slipped my radar, which is embarrassing.  And
please note that glyph names in TTF files *must* *not* contain spaces,
so this commit provides a fix for a single, buggy version of
`verdana.ttf' ...

Anyways, FreeType in the current git can now read T42 fonts as
produced by lilypond :-)

After fixing this, the problem becomes obvious.  Calling

  FT2_DEBUG=any:7 ftview notolily.t42

now fails with

  ...
  Locations tt_face_lookup_table: 0x125ecf0, `loca' -- could not find table
  FT_Open_Face: Return 144
  FT_Open_Face: Return 144

A `loca' table only exists in TrueType fonts; the `NotoSansCJK'
family, however, is an OpenType collection represented in SFNT format,
not TrueType.

Currently, lilypond relies on the font file name extension to decide
what to do.  Of course, this is a bad thing, but most of the time it
works just fine.  However, OpenType collections can either have `.ttc'
or `.otc' as an extension, and we have no means currently to reject
CFF flavoured TTCs like `NotoSansCJK-Regular.ttc'.

Right now, the number of available OTCs is very small, but I guess
this will rapidly change in the future.  Masamichi-san's patch is thus
the right thing for now but only a temporary solution.

It wouldn't be very hard to extend lilypond so that it can extract
subfont OTFs from an OTC, then adding them as PS resources in the
output file.  However, this would lead to a size explosion – OTCs were
invented to exactly avoid that.

I've opened a bug report to discuss whether ghostscript will add OTC
support, and whether the gs team is going to extend Type42 support to
cover generic SFNTs (i.e., CFF flavour also).

  http://bugs.ghostscript.com/show_bug.cgi?id=696808


    Werner