- From: Behdad Esfahbod <behdad@google.com>
- Date: Fri, 24 Apr 2015 11:52:15 -0700
- To: Ken Lunde <lunde@adobe.com>
- Cc: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotype.com>, Jonathan Kew <jfkthame@gmail.com>, WOFF Working Group <public-webfonts-wg@w3.org>, Jungshik Shin <jungshik@google.com>
- Message-ID: <CAOY=jUSm5wEhs=9L7dgHVLMdNqTq=XOnA5rpbgBqieJ5dU2+Zw@mail.gmail.com>
Thanks Ken. Jungshik already tried some of these (original, desubroutinized, desubroutinized and resubroutinized using our internal subroutinizer [that I'll open source soon] / otf, woff, woff2) a couple subsets of Noto. Jungshik, can you please share your findings? b On Fri, Apr 24, 2015 at 8:40 AM, Ken Lunde <lunde@adobe.com> wrote: > Behdad, > > I suggest that you start by using the "Source" fonts that we make > available on GitHub, specifically the Source Han Sans (though you can > instead use Noto Sans CJK because their CFFs are identical in terms of the > actual glyph data), Source Sans Pro, Source Serif Pro, and Source Code Pro > families. This should be enough to provide preliminary results across a > variety of glyph sets to determine whether further investigation, which > would include a larger corpus of OpenType/CFF fonts, has any merit. > > Regards... > > -- Ken > > > On Apr 24, 2015, at 1:03 AM, Behdad Esfahbod <behdad@google.com> wrote: > > > > Thanks Ken and Vlad. > > > > The first step would be to get a good corpus of CFF fonts. After that, > we have all the bits and pieces to try. There are quite a few combinations > (~10 to 20), but that's doable in a couple of weeks I would say, assuming I > can get help from Jungshik and Rod. > > > > So, Ken, Vlad, which one of you can contribute a CFF corpus for testing > purposes for this project? > > > > Cheers, > > > > behdad > > > > On Thu, Apr 23, 2015 at 6:47 AM, Levantovsky, Vladimir < > Vladimir.Levantovsky@monotype.com> wrote: > > I think that this is definitely something we need to investigate, and we > need to do it soon (as in "now"). The WOFF2 spec is still a working draft > so it is not unreasonable to expect it to be changed (sometimes > dramatically, as was the case with e.g. layout feature support in CSS > Fonts), and the changes like this one won't really put anything in jeopardy > - the existing WOFF2 fonts will work fine while the spec and CTS evolve, > and the implementations will eventually be updated. > > > > If there are significant gains to be realized due to CFF preprocessing > we ought to consider it but, as Jonathan mentioned, the final decision will > depend on the tradeoffs between potential benefits of reducing the > compressed size vs. possible increase of the uncompressed font size. > > > > Behdad, how long do you think it would take for you to get at least a > rough estimates of compression gains and CFF size increase due to > de-subroutinization? > > > > Thank you, > > Vlad > > > > > > -----Original Message----- > > From: Jonathan Kew [mailto:jfkthame@gmail.com] > > Sent: Thursday, April 23, 2015 2:16 AM > > To: Behdad Esfahbod; WOFF Working Group > > Cc: Ken Lunde; Jungshik Shin > > Subject: Re: CFF table processing for WOFF2? > > > > On 23/4/15 02:03, Behdad Esfahbod wrote: > > > Hi, > > > > > > Is the working group open to adding processed CFF table to WOFF2 or is > > > it too late? Maybe we can do that in a compatible way? > > > > > > There's already rumour on the net (which we have anecdotically > > > confirmed) that CFF fonts compress better in WOFF2 if desubroutinized. > > > It's unintuitive but makes some sense, if Brotli is great at capturing > > > redundancy, it should perform at least as well as the subroutinization. > > > > This is an interesting possibility, but I do have a concern... unless > the decoder can "re-subroutinize" the font (which seems like it would add > substantial complexity to the decoder) this has the potential to > significantly increase the in-memory footprint of the decoded font. For > memory-constrained devices, that might be a poor tradeoff. > > > > (I have no actual statistics to support or deny this. Both the potential > savings of compressed size and the resulting change to the uncompressed > size would be interesting to know...) > > > > > > > > I have only one transform on top of that in mind right now: drop the > > > offsets to charstrings. At reconstruction time, split charstring array > > > on endchar. > > > > > > If there is interest I can prototype it and report savings. > > > > > > Cheers, > > > > > > behdad > > > > > > > >
Received on Friday, 24 April 2015 18:53:00 UTC