RE: follow up on service workers for publishing platform

I agree that we need to consider all relevant technical issues, not sure if the same is true for legal / licensing stuff. We can’t mandate how various font vendors deal with it and what their licenses should or should not allow - all we can do [at best] is to make authors aware that certain content uses may require special licensing provisions.

Regards,
Vlad


-----Original Message-----
From: Leonard Rosenthol [mailto:lrosenth@adobe.com] 
Sent: Wednesday, December 02, 2015 12:18 AM
To: Ivan Herman; Daniel Weck
Cc: Dave Cramer; Tzviya Siegman; W3C Digital Publishing IG
Subject: Re: follow up on service workers for publishing platform

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.

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

>
>
>
>

Received on Wednesday, 2 December 2015 15:55:47 UTC