Add option to embed font data into executable.

Add option to embed font data into executable.

Some tools would like to be built with all resources embedded.
This change makes it possible to build a font manager which
uses font data embedded into the executable.

Committed: https://skia.googlesource.com/skia/+/5c9fa2844c4f97b9358d547f947372f680c68dd1

[bungeman-skia, 2015-03-26 22:11:32]

bungeman@google.com changed reviewers:
+ humper@google.com, reed@google.com

[bungeman-skia, 2015-03-26 22:11:33]

Just wanted to let you guys know I'm working on this and give you a chance to
try it out. At PS1 there are two ways of embedding the data (directly with the
linker or with objcopy) which have various trade-offs, but I'm trying to figure
out the right way to set the correct alignment. Also, the symbols need to be
made a bit more sane, with a define stating how to access them. In any event,
this still needs work and more fonts, but it's getting there.

[mtklein, 2015-03-26 22:32:07]

On 2015/03/26 22:11:33, bungeman1 wrote:
> Just wanted to let you guys know I'm working on this and give you a chance to
> try it out. At PS1 there are two ways of embedding the data (directly with the
> linker or with objcopy) which have various trade-offs, but I'm trying to
figure
> out the right way to set the correct alignment. Also, the symbols need to be
> made a bit more sane, with a define stating how to access them. In any event,
> this still needs work and more fonts, but it's getting there.

Is this so we can lock down open()?

[bungeman-skia, 2015-03-27 14:27:15]

On 2015/03/26 22:32:07, mtklein wrote:
> On 2015/03/26 22:11:33, bungeman1 wrote:
> > Just wanted to let you guys know I'm working on this and give you a chance
to
> > try it out. At PS1 there are two ways of embedding the data (directly with
the
> > linker or with objcopy) which have various trade-offs, but I'm trying to
> figure
> > out the right way to set the correct alignment. Also, the symbols need to be
> > made a bit more sane, with a define stating how to access them. In any
event,
> > this still needs work and more fonts, but it's getting there.
> 
> Is this so we can lock down open()?

Yes, the idea is just to make everything as self-contained as possible so that
fewer permissions are needed in general. In theory, in the future this could
also be used for simpler control of test font data for users who are sandboxed.

[jcgregorio, 2015-03-27 14:47:06]

On 2015/03/27 at 14:27:15, bungeman wrote:
> On 2015/03/26 22:32:07, mtklein wrote:
> > On 2015/03/26 22:11:33, bungeman1 wrote:
> > > Just wanted to let you guys know I'm working on this and give you a chance
to
> > > try it out. At PS1 there are two ways of embedding the data (directly with
the
> > > linker or with objcopy) which have various trade-offs, but I'm trying to
> > figure
> > > out the right way to set the correct alignment. Also, the symbols need to
be
> > > made a bit more sane, with a define stating how to access them. In any
event,
> > > this still needs work and more fonts, but it's getting there.
> > 
> > Is this so we can lock down open()?
> 
> Yes, the idea is just to make everything as self-contained as possible so that
fewer permissions are needed in general. In theory, in the future this could
also be used for simpler control of test font data for users who are sandboxed.

This is excellent, thanks for tackling this!

[bungeman-skia, 2015-03-30 18:44:12]

bungeman@google.com changed reviewers:
+ jcgregorio@google.com

[bungeman-skia, 2015-03-30 18:44:13]

I think this is fairly straight forward now. Currently (PS3) this just lists
Funkster.ttf, since that's the one we have checked in. When using this we'll
probably want to add some more.

[humper, 2015-03-30 19:07:41]

On 2015/03/30 18:44:13, bungeman1 wrote:
> I think this is fairly straight forward now. Currently (PS3) this just lists
> Funkster.ttf, since that's the one we have checked in. When using this we'll
> probably want to add some more.

LGTM, thanks for this.

As I understand the plan, I'll update the gyp file to point at the linux system
directories that contain the fonts we want to use.  This means that the embedded
font build won't work unless the fonts are installed in the same place as they
are on the fiddle GCE instance; we should probably eventually make the embed
resources script not fail if it can't find the specified input?

[bungeman-skia, 2015-03-30 19:36:37]

On 2015/03/30 19:07:41, humper wrote:
> On 2015/03/30 18:44:13, bungeman1 wrote:
> > I think this is fairly straight forward now. Currently (PS3) this just lists
> > Funkster.ttf, since that's the one we have checked in. When using this we'll
> > probably want to add some more.
> 
> LGTM, thanks for this.
> 
> As I understand the plan, I'll update the gyp file to point at the linux
system
> directories that contain the fonts we want to use.  This means that the
embedded
> font build won't work unless the fonts are installed in the same place as they
> are on the fiddle GCE instance; we should probably eventually make the embed
> resources script not fail if it can't find the specified input?

So I just ran this with

'<!@(find /usr/share/fonts -type f -name "*\.ttf" -print0 | xargs -0)',

as the value of the 'fonts_to_include' variable on my local machine. This takes
a few minutes to create a ~1GB input .cpp file and then it takes a while (it's
still going) to actually compile this file. I think you're going to want a small
curated set of fonts.

[bungeman-skia, 2015-03-30 19:48:35]

The CQ bit was checked by bungeman@google.com

[commit-bot: I haz the power, 2015-03-30 19:48:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1015723004/40001

[commit-bot: I haz the power, 2015-03-30 19:53:51]

Committed patchset #3 (id:40001) as
https://skia.googlesource.com/skia/+/5c9fa2844c4f97b9358d547f947372f680c68dd1