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

Correction: Vlad co-chaired web-fonts and Chris L was team contact. Thanks for the note, Vlad. :-)

Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com 


-----Original Message-----
From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@monotype.com] 
Sent: Wednesday, December 02, 2015 3:58 PM
To: Siegman, Tzviya - Hoboken; Leonard Rosenthol; Ivan Herman
Cc: Daniel Weck; Dave Cramer; W3C Digital Publishing IG; Chris Lilley
Subject: RE: Fonts (was Re: follow up on service workers for publishing platform)

Hi Tzviya, all,

Thank you for raising these important questions. I would argue (repeating Patrick’s and my own sentiment) that any part that constitutes a publication should be treated as essential component. It’s a prerogative of authors to choose a word, a font, an illustration, etc. and it’s and not up to us to decide whether it is essential or not - I'd say that I am happy to put this particular issue aside. ;-)

As to other things font related:
- When it comes to fonts I’d argue that we need to only be concerned with enabling their use by authors, the technical decisions we make need not be concerned with pleasing any particular font vendor to satisfy their wishes or special interests. The font industry as a whole is at peace with web font technology – the widespread web font adoption (and a commercial success enjoyed by Adobe Typekit , Monotype and other players in the market) is a testament to this. If there is a foundry that is not willing to adapt to the changing environment – it’s their sole decision, I am a strong believer that the market forces will take care of them.
- I believe that things like font obfuscation and encryption are definitely out of the scope for this group, in my opinion. DPUB will be using existing web technologies and can definitely influence the direction of their development if there is a new use case to consider, but unless it is justified by the use cases – I don’t see the need to even bring it up. 
- Font subsetting is a different story – whether it is done to reduce the glyph set to only those used in the particular publication or to support one [of many] scripts supported by the same font is again, in my view, a publisher decision and it is the one that has no bearing on the underlying technology that enables the use of fonts in DPUB - I look at it as content optimization step. Whether a font resource supports only Latin, or a subset of Latin is only a concern if there are missing characters or if there are too much extra data that will need to be transferred but never used – again, not a technology issue but primarily a usability issue.
- I don’t believe there are significant differences between foundries when it comes to licensing conditions, but there are always going to be cost-related considerations for publishers. It’s one thing if a commercial license is deemed restrictive because it limits valid uses (and publishers have every right to demand that font licenses allow all the uses they need to enable) but I think it is also inevitable that commercial licenses will always be more restrictive when it comes to e.g. allowing unlimited duplications and/or distribution of derivative works (which most of the open fonts licenses are okay with). There are also unavoidable cost considerations – ‘free’ vs. ‘paid up’ vs. ‘pay for use’ are different cases and, when it comes to this, it is up to a publisher / font vendor to decide and agree on.

And thank you for recognizing the expertise this group has on the subject. I am also happy to admit that I serve as a chair of the Web Fonts WG in W3C with Chris Lilley being our W3C Team contact and an invaluable source of knowledge and expertise on all things font related.

Thank you,
Vlad


-----Original Message-----
From: Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com]
Sent: Wednesday, December 02, 2015 3:34 PM
To: Levantovsky, Vladimir; Leonard Rosenthol; Ivan Herman
Cc: Daniel Weck; Dave Cramer; W3C Digital Publishing IG; Chris Lilley
Subject: RE: Fonts (was Re: follow up on service workers for publishing platform)

Hi All,

As a reminder, we do have representation from font experts in our midst. Vlad Levantovsky is with Monotype, and Chris Lilley chaired the Web Fonts WG in W3C. A few points to consider as we consider fonts:

Leaving aside the issue of whether fonts are "essential" to the publication, is anything specific to PWP/DPUB to focus on regarding fonts? 

Are issues of obfuscating/encrypting/subsetting unique because of portability? Is this a technical requirement brought about by legal issues?  Would the technical steps I take for Adobe fonts be the same as those for Monotype fonts? 

We are, of course, happy to take this up, if it is a DPUB-issue and can result in a document that makes it easier for people to use fonts. We can also recommend that another group takes that up if it is a broader Web issue.

I will also add a "moderator note" (which I almost never do). This is really not the appropriate place to discuss what is possible/valid etc. in EPUB. If you have a recommendation about EPUB, please add an issue to the IDPF Repository [1]

[1] https://github.com/IDPF/epub-revision/issues 

Tzviya Siegman
Digital Book Standards & Capabilities Lead Wiley
201-748-6884
tsiegman@wiley.com 


-----Original Message-----
From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky@monotype.com]
Sent: Wednesday, December 02, 2015 1:53 PM
To: Leonard Rosenthol; Ivan Herman
Cc: Daniel Weck; Dave Cramer; Siegman, Tzviya - Hoboken; W3C Digital Publishing IG; Chris Lilley
Subject: RE: Fonts (was Re: follow up on service workers for publishing platform)

On Wednesday, December 02, 2015 12:53 PM Leonard Rosenthol wrote:

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

I guess the major contention point on my side is that I disagree that DPUB (or W3C as an entity) needs to be concerned with the licensing / legal aspects of using fonts. Yes, font IP is valuable and fonts as resources need to be properly licensed, but I disagree that DPUB should do anything about it other than to maybe say somewhere in the spec that the use of fonts as part of the publication needs to be properly licensed. The conditions of the license, what it does and doesn’t cover depends on the particular publication uses and does not require any technical  solution from us as a group.

> Web font formats (eg. WOFF) can certainly be referenced from EPUB 
> content,

Yes, which means that the technology is in place to make it happen and this is what we as a group need to do.

> but they are not permitted to be embedded inside of the EPUB.  
.
Not permitted by whom? The spec doesn't impose any limitations and technical solutions are in place to make it happen. If a particular vendor's license doesn’t permit this kind of use - I'd say "good luck with that, there are other font vendors that do allow this to happen".

> For that, you would need the TTF/OTF version.   

Again, says who? Certainly there is nothing in the spec that specifically mandates the use of one data format over another.

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

Yes, and it goes back to what I mentioned previously - a publisher needs to get the font license that allows them to do what they need to do. If they need to make their content available both online and offline they'd need to use WOFF files and they need a license that allows WOFF files be embedded in EPUB. (If a particular font vendor is not permitting this kind of use - there are others that will.) The particular conditions of that license (and how much it costs) is something that forms a contractual relationship between a client and a vendor - neither W3C nor DPUB / EPUB / PWP specs need to be concerned with that part.

Regards,
Vlad





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

>>
>>
>>
>>

Received on Wednesday, 2 December 2015 21:04:30 UTC