DirectWrite to use PostScript name for PDF.

DirectWrite to use PostScript name for PDF.

The PDF backend expects info->fFontName to be the PostScript name.
Prior to this change the '<family> <sytle>' name was used instead.

Committed: https://skia.googlesource.com/skia/+/6d867d494a0e619ebf445a7c0b8e35bb65d5f027

[bungeman-skia, 2014-06-12 15:51:26]

Before it didn't seem to matter if we got the name right, however, there are
changes afoot which will make getting the name correct of some importance.

[bungeman-skia, 2014-06-12 22:07:05]

On 2014/06/12 15:51:26, bungeman1 wrote:
> Before it didn't seem to matter if we got the name right, however, there are
> changes afoot which will make getting the name correct of some importance.

I put together a Chromium build with Skia hacked up to never embed any font data
(just name the font in the descriptor). When not embedding font data, the GDI
back-end seems to work out when viewed with the internal viewer or Acrobat. When
using the DirectWrite backend without this patch one ends up with gibberish (as
expected), but then with this CL PS1 the preview appears to hang. With
DirectWrite but outputing the GDI names, I still get gibberish.

Does anything work? I took a look and we're supposed to be putting the
postscript name into the one required name field, and there are the other
optional name / style fields which we're not using. However, pdfium through
ppapi has no means of looking up fonts by postscript name, as far as I can tell.
I think the only reason anything works with the DirectWrite backend enabled is
because of embedded font data.

[vandebo (ex-Chrome), 2014-06-12 23:52:23]

On 2014/06/12 22:07:05, bungeman1 wrote:
> On 2014/06/12 15:51:26, bungeman1 wrote:
> > Before it didn't seem to matter if we got the name right, however, there are
> > changes afoot which will make getting the name correct of some importance.
> 
> I put together a Chromium build with Skia hacked up to never embed any font
data
> (just name the font in the descriptor). When not embedding font data, the GDI
> back-end seems to work out when viewed with the internal viewer or Acrobat.
When
> using the DirectWrite backend without this patch one ends up with gibberish
(as
> expected), but then with this CL PS1 the preview appears to hang. With
> DirectWrite but outputing the GDI names, I still get gibberish.
> 
> Does anything work? I took a look and we're supposed to be putting the
> postscript name into the one required name field, and there are the other
> optional name / style fields which we're not using. However, pdfium through
> ppapi has no means of looking up fonts by postscript name, as far as I can
tell.
> I think the only reason anything works with the DirectWrite backend enabled is
> because of embedded font data.

Was out for googleserve today...

Thanks for doing some leg work here (BTW, the Mac deltas look to be a bug, which
I will figure out tomorrow). 

I thought that PDFium used name as the primary look up mechanism for fonts, at
least that's what I thought thestig@ said.

That being said, this CL seems fine to me, but I'm not a Windows expert.  LGTM

[Lei Zhang, 2014-06-13 21:28:19]

+scottmg

[bungeman-skia, 2014-06-17 16:13:53]

After some experimentation, I have come up with PS2. This is wrong, but it was
wrong before; at least this new wrong somewhat works. With this change (and
blocking PDF from embedding anything) Chromium with DirectWrite at least does
something readable most of the time with pdfium.

[vandebo (ex-Chrome), 2014-06-17 16:17:05]

On 2014/06/17 16:13:53, bungeman1 wrote:
> After some experimentation, I have come up with PS2. This is wrong, but it was
> wrong before; at least this new wrong somewhat works. With this change (and
> blocking PDF from embedding anything) Chromium with DirectWrite at least does
> something readable most of the time with pdfium.

Does it do something reasonable in other readers? If so LGTM.  If not, please
file a bug against pdfium.

[bungeman-skia, 2014-06-17 17:16:06]

On 2014/06/17 16:17:05, vandebo wrote:
> On 2014/06/17 16:13:53, bungeman1 wrote:
> > After some experimentation, I have come up with PS2. This is wrong, but it
was
> > wrong before; at least this new wrong somewhat works. With this change (and
> > blocking PDF from embedding anything) Chromium with DirectWrite at least
does
> > something readable most of the time with pdfium.
> 
> Does it do something reasonable in other readers? If so LGTM.  If not, please
> file a bug against pdfium.

Adobe Reader seems to be able to handle the resulting pdf ok. I think there may
be multiple issues here, the first of which is that we should be putting the
PostScript name, the family name, and the style name into the pdf. The second is
that pdfium is depending on ppapi for fonts, and there doesn't seem to be any
means for it to find fonts by PostScript name. There's probably a lot of work
which could be done around this. In the future, I'll keep the idea of looking up
fonts by family/style name as well as PostScript name.

[bungeman-skia, 2014-06-17 17:17:13]

The CQ bit was checked by bungeman@google.com

[commit-bot: I haz the power, 2014-06-17 17:18:02]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/bungeman@google.com/324403010/20001

[commit-bot: I haz the power, 2014-06-17 17:48:10]

Change committed as 6d867d494a0e619ebf445a7c0b8e35bb65d5f027