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/>