Re: Gets vertical skylines from grob stencils (issue 5626052)

[address@hidden]

On Feb 16, 2012, at 1:21 PM, Han-Wen Nienhuys wrote:

> On Thu, Feb 16, 2012 at 8:08 AM,  <address@hidden> wrote:
>>> By the way, lilypond's fonts embed extra data in font tables (look for
>> 
>> LILC and
>>> 
>>> LILY in open-type-font.cc). That may be a better way to embed this
>> 
>> information
>>> 
>>> than by putting it in a scm file. For example, it would allow
>> 
>> unofficial fonts
>>> 
>>> to support integrals by embedding an extra table.
>> 
>> 
>> I think this is a good idea...I'll have a look at it.  Question, though
>> - aren't font tables done as alists?  I think it's important to use a
>> hash table here, as there is a lot of data getting thrown around and
>> hash table look ups are in constant time.  I'll investigate.
> 
> This sounds wrong.  Where does this data come from ultimately?
> 

The svg files.  I read them into lilypond and generate this informatin.

> Without knowing more, I suspect this data should be computed at font
> generation time, and it should be embedded in the OTF file.

It is created at font generation time (git grep font-cache.scm in 
mf/GNUmakefile) but it is not part of the otf-table.  As I said, I'd like to do 
this, but I'm not comfortable enough with build to know how its done.  Where 
and when are these files generated?  Are they generated by metafont or python 
or lilypond?  What I'd likely have to do is read the otf-tables into lilypond, 
run the code used to make font-chace.scm, and instead of writing this data to 
font-cache.scm overwrite the otf-table files w/ new otf-tables that contain 
this data.  This doesn't seem impossible, but I'd want to make sure it's the 
right way to go.  The advantage of font-cache.scm is that it defines box-hash 
in LilyPond at runtime, and as hash-table-lookups are in constant time, this is 
lightning fast compared to an alist, which is in linear time.

> 

> OTF tables are arbitrary binary data.  IIRC, the fonts are compressed
> anyway, so the on-disk space is not that relevant.
> 
> When we read the fonts, we interpret the data, see open-type-font.cc,
> and alist is just a very convenient form for (de)serializing data. You
> could do whatever format works best for you; since the font is only
> read once, you don't have to worry about performance when loading it.
> 


A separate issue should be opened in the tracker to use hash-tables instead of 
alists for otf tables.  I'm trying to think of this project in separable, 
manageable chunks.  I'd like the first chunk to be the pushing of the skyline 
code you see on Rietveld so that there is a direct effect straightaway in 
scores & so that we can get user feedback before we make infrastructural 
changes (which may depend on what people wind up asking for after the change).

Cheers,
MS