#277 Clarification request: webfonts
Closed: Invalid None Opened 10 years ago by leamas.

While trying to package openerp7 [1], I have run into problems with bundled webfonts. Since I didn't know how to handle this, I sent a message to the mailing list, getting answers [2] [3] boiling down to that I should unbundle the webfonts and package them as dependencies.

Doing so, I filed three font review requests [4] [5] [6].

Orion Poplawski started a review of [4], which basically stalled since neither he nor me really understood how to handle this. In order to resolve this I would appreciate if FPC could clarify how webfonts should be handled:
- Where should webfonts be stored? The only webfont I find is
kurdit-unikurd-web-fonts. This uses /usr/share/fonts. Thios is not
ideal since a package like [4] contains two fonts with same name,
one for use a webfont, one as a desktop font.
- Should webfonts be registered in fontconfig files?
- How should web applications get access to webfonts? Should we use the same
mechanism as for js files, where we install a apache config file which opens
up access to the systrem path and patches application accordingly?
- For cases like [6], a pure webfont, does it really make sense to package it
separately? The copy-on-build scheme suggested in [3] seems a bit of
overkill to me at a second thought.
- Out of sheer curiosity, in a package like [4], what's the difference
between the desktop font and the webfont in general?
- If the answers to these questions are not obvious, would it be possible
to get a bundling exception until this is cleared out? My plan is then to
package each webfont in a subpackage with clearly stated license terms.

[1] openerp7 https://bugzilla.redhat.com/show_bug.cgi?id=957339
[2] mail1 http://lists.fedoraproject.org/pipermail/devel/2013-April/181759.html
[3] mail2 http://lists.fedoraproject.org/pipermail/devel/2013-April/181770.html
[4] entypo https://bugzilla.redhat.com/show_bug.cgi?id=956127
[5] zocial https://bugzilla.redhat.com/show_bug.cgi?id=956120
[6] mnmlicons https://bugzilla.redhat.com/show_bug.cgi?id=956134

I raise this to najor since my review is blocked by these issues.


And here is the naming question. Is a plain -font suffix a suitable naming scheme for webfonts?

My own thoughts after a few nigths sleep on this:

In some ways ways webfonts are like regular desktop fonts. In particular, they have the same licensing issues. This is the primary reason to unbundle, but is it strong enough?

In other ways, webfonts are very different from regular fonts. They are typically not intended to be used in the same way as desktop fonts. A webfont like sozial with a number of large button objects is one example. This also illustrates that the normal font fallback procedures are not really always useful (this is true for all of my three webfonts). Also, of the four formats regularly used (eot, ttf, woff, svg) only the ttf variant could be used on the desktop.

Some tentative ideas:
- The basic webfont package is just a static web resource. No fontconfig file, no -font suffix.
- For clarity, it might make sense to use a specific package name suffix (-webfont?).
- It might make sense to package the ttf webfont as a regular font in a subpackage. This should be on a case-by-case basis. If upstream provides a desktop variant, this should of course be used.
- webfonts should be stored in a specific place (/usr/share/fonts/webfonts?) making it easier to provide access to them for web applications (which can just use the entire tree). This also provides natural locations for upstreams providing both a desktop and a webfont variant of the font e. g., [4]
.
Other remarks:
- The apache config file to provide access should work (using a Directory directive). This should be used in favor of the copy-on-build approach suggested in [3].
- fedora-review tool has a new test for embedded fonts which is likely to spot more of these issues
- Nicolas Chauvet is on holiday.

If this cannot be decided on today's meeting I would appreciate if the FPC provides some kind of temporary solution so that I could proceed with my original openerp7 request. One way would be to grant a temporary bundling exception for the fonts I have open review requests for (sozial, mnmlicons, entypo). The primary concern licensing is clearly sorted out in the review requests for these IMHO.

Another solution would be to allow me to package my three webfonts just as static web resources, leaving the packaging of them as regular fonts aside until we have resolved when/how this should be done. This would be easier if a provisionary location and name suffix was decided upon.

This complete mess has now been stopped by legal issues. This means that I'm putting my attempts to package openerp7 on ice, and I have thus no interest in these issues for the time being.

From my perspective this issue could be closed (that is not to say that I feel that the issue has been resolved, it's just that it does not affect me for the time being)

Login to comment on this ticket.

Metadata