- From: AUDRAIN LUC <LAUDRAIN@hachette-livre.fr>
- Date: Wed, 2 Dec 2015 07:37:21 +0100
- To: Leonard Rosenthol <lrosenth@adobe.com>, Ivan Herman <ivan@w3.org>, Daniel Weck <daniel.weck@gmail.com>
- CC: Dave Cramer <Dave.Cramer@hbgusa.com>, Tzviya Siegman <tsiegman@wiley.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Good point. Count me in. Luc Le 02/12/2015 06:18, « Leonard Rosenthol » <lrosenth@adobe.com> a écrit : >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 06:37:51 UTC