Re: Fonts (was Re: follow up on service workers for publishing platform)

The biggest font challenge is going to be licensing.  One of the GOOD
things about the internet, is that it's "easier" to catch offenders (as the
stock photography companies are doing today) of people improperly using
your files.

On the technical side, W3C should probably reach out to some font
creators/distributors to get feedback on what the proper way of protecting
the licenses/rights are.  getting into font-focused DRM may not really be a
way W3C wishes to go.  I honestly don't think a technical solution is the
right way to go, but a legal solution and framework is, which - to my
understanding - is way beyond W3C scope

-Nick

On Wed, Dec 2, 2015 at 1:10 PM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> >EPUB has tackled this SOMEWHAT with font obfuscation.  Additionally, many
> fonts are selling distributable licenses that make it legal.
> >
> For desktop fonts, this is true, Nick.   However, those same rules do not
> apply to web fonts (eg. Adobe TypeKit, Monotype, Fonts.com).
>
> Leonard
>
> From: Nick Ruffilo <nickruffilo@gmail.com>
> Date: Wednesday, December 2, 2015 at 10:04 AM
> To: Leonard Rosenthol <lrosenth@adobe.com>
> Cc: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotype.com>, Ivan
> Herman <ivan@w3.org>, Daniel Weck <daniel.weck@gmail.com>, Dave Cramer <
> Dave.Cramer@hbgusa.com>, Tzviya Siegman <tsiegman@wiley.com>, W3C Digital
> Publishing IG <public-digipub-ig@w3.org>, "chris@w3.org" <chris@w3.org>
> Subject: Re: Fonts (was Re: follow up on service workers for publishing
> platform)
>
> EPUB has tackled this SOMEWHAT with font obfuscation.  Additionally, many
> fonts are selling distributable licenses that make it legal.
>
> What I think PWP should address is:
> 1) An easy way to include any rights language (some things provided by GPL
> or purchased licenses require you distribute the license with the file)
> 2) A way to obfuscate/encrypt certain files (if that is even really
> possible/probably)
>
> In my dealings, Fonts are more a headache for the publisher/designers as
> they have a limited pallet to work with when it comes to digital
> publications, but technical issues shouldn't be the gating item.
>
> -Nick
>
>
> On Wed, Dec 2, 2015 at 12:53 PM, Leonard Rosenthol <lrosenth@adobe.com>
> wrote:
>
>> Font is a four letter word beginning with F - it’s nothing if not
>> gruesome :).
>>
>> I am not trying to portray doom and gloom, but I am raising a topic that
>> needs deep investigation both from a technical as well as a legal
>> perspective for not only ourselves but the users of PWP.  It would be wrong
>> of us developing a standard to do so known that there are pitfalls for
>> users.
>>
>> Web font formats (eg. WOFF) can certainly be referenced from EPUB
>> content, but they are not permitted to be embedded inside of the EPUB.  For
>> that, you would need the TTF/OTF version.   And if you then took the EPUB
>> with TTF/OTF and unbundled it on a server, there is no guarantee that the
>> server and/or the client/UA would be able to do the right thing.  And then
>> there is the potential for running afoul of licensing considerations.
>>
>> Leoanrd
>>
>>
>>
>>
>> On 12/2/15, 8:07 AM, "Levantovsky, Vladimir" <
>> Vladimir.Levantovsky@monotype.com> wrote:
>>
>> >I believe that the reality isn't as gruesome as pictured in the example
>> below. Most of the font foundries offer different kind of licenses for
>> different uses - adding e.g. web font license provisions to EPUB license or
>> vice versa would be easy to do and in some cases incur no incremental costs
>> (e.g. Monotype's professional tier web font license gives unlimited access
>> to the whole library and free license for desktop font uses).
>> >And most of the web font formats are already supported by EPUB.
>> >
>> >Thank you,
>> >Vlad
>> >
>> >
>> >-----Original Message-----
>> >From: Leonard Rosenthol [mailto:lrosenth@adobe.com]
>> >Sent: Wednesday, December 02, 2015 8:34 AM
>> >To: Ivan Herman
>> >Cc: Daniel Weck; Dave Cramer; Tzviya Siegman; W3C Digital Publishing IG;
>> Chris Lilley
>> >Subject: Re: follow up on service workers for publishing platform
>> >
>> >PWP specific - particularly the reuse of a packaged publication being
>> served in a non-packaged fashion (or vice-versa).
>> >
>> >For example, while most font foundries allow for fonts to be embedded
>> into an EPUB because of the methods used (e.g. Subsetting and/or
>> obfuscation), those same foundries do not allow their fonts to be used as
>> “web fonts” (or at least not without a separate license).  In the same
>> vein, the web font vendors only license their fonts for web use and not for
>> packaging.
>> >
>> >On a related note, there is also the question of what font format(s)
>> can/should be supported within a PWP since those used today for EPUB aren’t
>> necessary compatible with OWP technologies.
>> >
>> >(and there is more - but this should give you a taste)
>> >
>> >As Heather notes, the issues could be solved with a best practices type
>> of guide - but until the details are exposed, reviewed and resolved - it’s
>> unclear what the correct vehicle(s) would be.
>> >
>> >Leonard
>> >
>> >
>> >
>> >
>> >On 12/2/15, 12:14 AM, "Ivan Herman" <ivan@w3.org> wrote:
>> >
>> >>Leonard,
>> >>
>> >>> On 2 Dec 2015, at 06:18, Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>> >>>
>> >>> At some point, this group should probably start a subgroup focused on
>> various font-related issues as there are a number of both technical and
>> legal issues that come up in the content of non-packaged publications and
>> their use of fonts.
>> >>
>> >>I do not question the fact that there may be issues with fonts (I copy
>> >>Chris explicitly, because he is much more knowledgable than I am).
>> >>However, the question is whether these issues are publication specific
>> >>or general Web issues. If the latter, then I am not sure that type of
>> >>work is in the scope of this IG…
>> >>
>> >>Can you be more specific what you have in mind to be able to decide
>> this?
>> >>
>> >>Thanks
>> >>
>> >>Ivan
>> >>
>> >>
>> >>
>> >>>
>> >>> Leonard
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On 12/1/15, 9:09 AM, "Ivan Herman" <ivan@w3.org> wrote:
>> >>>
>> >>>>
>> >>>>> On 1 Dec 2015, at 18:03, Daniel Weck <daniel.weck@gmail.com> wrote:
>> >>>>>
>> >>>>> On Tue, Dec 1, 2015 at 4:50 PM, Ivan Herman <ivan@w3.org> wrote:
>> >>>>>>
>> >>>>>> I understand this for Acme. However, thinking it further in
>> >>>>>> direction of a more sophisticated reader: is it necessary to store
>> all the file references?
>> >>>>>> After all, I would expect the Service Worker may find out on the
>> >>>>>> fly that a resource is to be cached.
>> >>>>>>
>> >>>>>> This may be important for the production site. This means I do not
>> >>>>>> have to list the references of all the images, js and css files,
>> >>>>>> etc, just the 'top level' files to trigger the process and those
>> could be cached.
>> >>>>>>
>> >>>>>> Of course, there is a danger that the reader would cache too much,
>> >>>>>> eg, remote references that the content refers to. So maybe the
>> >>>>>> manifest could contain some sort of URI patterns, saying to the
>> >>>>>> reader: "if the URI matches one of these patterns, cache it".
>> >>>>>>
>> >>>>>
>> >>>>> I would assume that all of the reading system's app resources would
>> >>>>> be cached "immediately" (i.e. as early as possible in the bootstrap
>> >>>>> process), so that the reading system itself is available offline.
>> >>>>
>> >>>> Absolutely.
>> >>>>
>> >>>>> However, publication content would be cached according to a
>> >>>>> particular strategy (on-demand vs. preload, LRU eviction, etc.), in
>> >>>>> terms of offline-ing multiple publications, but also in terms of
>> >>>>> offline-ing resources within a given publication (partial fetch vs.
>> full cache).
>> >>>>
>> >>>> Right. But, additionally, I think providing some level of content
>> provider option may be necessary (inclusion patterns, exclusion patterns,
>> etc.).
>> >>>>
>> >>>> We used this example before: a publication may refer to very large
>> font files. In some cases, those fonts are for fanciness; ie, it is
>> perfectly o.k. if the reader does not cache those and, in case it is
>> offline, falls back to some system fonts. In other cases those fonts are
>> essential because, for example, they display mathematical symbols or
>> musical notes: in this case the font must be cached, too, for proper
>> offline use. This cannot really be covered algorithmically; it is up to the
>> creator of the publication to control this.
>> >>>>
>> >>>> Ivan
>> >>>>
>> >>>>
>> >>>>> Dan
>> >>>>
>> >>>>
>> >>>> ----
>> >>>> Ivan Herman, W3C
>> >>>> Digital Publishing Lead
>> >>>> Home: http://www.w3.org/People/Ivan/
>> >>>> mobile: +31-641044153
>> >>>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >>----
>> >>Ivan Herman, W3C
>> >>Digital Publishing Lead
>> >>Home: http://www.w3.org/People/Ivan/
>> >>mobile: +31-641044153
>> >>ORCID ID: http://orcid.org/0000-0003-0782-2704
>> >>
>> >>
>> >>
>> >>
>>
>
>
>
> --
> - Nick Ruffilo
> @NickRuffilo
> http://Aerbook.com
> http://twitch.tv/TheWizardLlewyn
> http://ZenOfTechnology.com <http://zenoftechnology.com/>
>
>


-- 
- Nick Ruffilo
@NickRuffilo
http://Aerbook.com
http://twitch.tv/TheWizardLlewyn
http://ZenOfTechnology.com <http://zenoftechnology.com/>