In a large package (openerp7) I have found some bundled .ttf and .otf font files. One of these (Inconsolata) seems to exist in Fedora as levien-inconsolata-fonts, the others (see below) I cannot find with a quick search.
The fonts are parts of specific addons (a. k. a. plugins). They are referenced with explicit paths in various .css or css/* files.
The entypo-webfont.ttf seems to have a working upstream http://www.entypo.com. I cannot find an upstream for mnmliconsv21-webfont.ttf, hint is that it's generated by "Font Squirrel" ?! There seem to be an upstream for zocial-regular-webfont.ttf, at https://github.com/adamstac/zocial, providing a woff file.
Now, what should I do with these? Packaging GL tells me to "avoid" bundling ttf/otf files. What's this in this case?
Utterly confused. Any hint, out there?
--alec
On Tue, Apr 23, 2013 at 03:37:03PM +0200, Alec Leamas wrote:
In a large package (openerp7) I have found some bundled .ttf and .otf font files. One of these (Inconsolata) seems to exist in Fedora as levien-inconsolata-fonts, the others (see below) I cannot find with a quick search.
The fonts are parts of specific addons (a. k. a. plugins). They are referenced with explicit paths in various .css or css/* files.
The entypo-webfont.ttf seems to have a working upstream http://www.entypo.com. I cannot find an upstream for mnmliconsv21-webfont.ttf, hint is that it's generated by "Font Squirrel" ?! There seem to be an upstream for zocial-regular-webfont.ttf, at https://github.com/adamstac/zocial, providing a woff file.
Now, what should I do with these? Packaging GL tells me to "avoid" bundling ttf/otf files. What's this in this case?
Utterly confused. Any hint, out there?
We had a similar problem with a package a few weeks ago:
http://lists.fedoraproject.org/pipermail/packaging/2013-April/009046.html
The first thing to work out: Does simply deleting the font file(s) make any difference to the documentation / package? In our case, the packager could simply delete the file [in %install] and it appeared to make absolutely no difference to the rendered HTML documentation, thus problem solved :-)
Rich.
On 2013-04-23 16:17, Richard W.M. Jones wrote:
On Tue, Apr 23, 2013 at 03:37:03PM +0200, Alec Leamas wrote:
In a large package (openerp7) I have found some bundled .ttf and .otf font files. One of these (Inconsolata) seems to exist in Fedora as levien-inconsolata-fonts, the others (see below) I cannot find with a quick search.
The fonts are parts of specific addons (a. k. a. plugins). They are referenced with explicit paths in various .css or css/* files.
The entypo-webfont.ttf seems to have a working upstream http://www.entypo.com. I cannot find an upstream for mnmliconsv21-webfont.ttf, hint is that it's generated by "Font Squirrel" ?! There seem to be an upstream for zocial-regular-webfont.ttf, at https://github.com/adamstac/zocial, providing a woff file.
Now, what should I do with these? Packaging GL tells me to "avoid" bundling ttf/otf files. What's this in this case?
Utterly confused. Any hint, out there?
We had a similar problem with a package a few weeks ago:
http://lists.fedoraproject.org/pipermail/packaging/2013-April/009046.html
The first thing to work out: Does simply deleting the font file(s) make any difference to the documentation / package? In our case, the packager could simply delete the file [in %install] and it appeared to make absolutely no difference to the rendered HTML documentation, thus problem solved :-)
Rich.
Thanks for reply.... I'm tempted, but here is a test problem. This is about real webpages, and to be frank I'm not quite sure how to test thoroughly. Just removing feels like it could introduce bugs I will not catch. And maintenance would be a problem...
Digging deeper, I find that all references seem to be part of @font-face definitions like
@font-face{ ... src: url('zocial-regular-webfont.eot'); src: url('zocial-regular-webfont.eot?#iefix') format('embedded-opentype'), url('zocial-regular-webfont.woff') format('woff'), url('zocial-regular-webfont.ttf') format('truetype'), url('zocial-regular-webfont.svg#ZocialRegular') format('svg'); ...}
So one question would be what happens in such a definition if none of the src: elements are found.
But even if it would be possible to use a fallback for some fonts, things like entypo-webfont really can't be substituted: it's a symbol font with pictograms, not likely to be replaceable. Seems that zocial-regular-webfont and mnmlicons are the same kind.
Reading Nicholas's reply to "your" thread I get the impression that the browser would download these fonts if they are not installed on the machine running to browser. Ergo: - At least some fonts are not replaceable - The web page must be able to provide the font to the client if requested.
Does the GL general bundling exception for "javascript intended to be served to a web browser" cover this? In that case, this might be solved, I guess.
Otherwise, is there any way to avoid the need to package these fonts (for those with an upstream) and patch the css paths? The latter part seem problematic to me since the complete filesystem isn't really available in the webserver context. Or is it? (i. e., can a web application for sure use a resource under /usr/share?)
Still confused, but on a higher level.
--alec
Le Mar 23 avril 2013 17:55, Alec Leamas a écrit :
So one question would be what happens in such a definition if none of the src: elements are found.
The browser will try to display something with its system fonts. If the missing fonts used standard encoding, it may even work perfectly. Anyway it's bad practice to provide only src rules in css font rules, src rules should be a fallback only.
But even if it would be possible to use a fallback for some fonts, things like entypo-webfont really can't be substituted: it's a symbol font with pictograms, not likely to be replaceable.
You'll be surprised at how many symbols have a standardised codepoint in unicode, and Fedora systems at least ship with huge symbol fonts.
Otherwise, is there any way to avoid the need to package these fonts (for those with an upstream) and patch the css paths? The latter part seem problematic to me since the complete filesystem isn't really available in the webserver context. Or is it? (i. e., can a web application for sure use a resource under /usr/share?)
It can if you configure the web server properly (I don't think selinux blocks ro /usr/share/fonts access from web servers right now). You can even alias paths in the web server config (expose a path under a different name from the filesystem one)
If you can't identify the upstream of a font, Fedora can't ship it in any form, since you won't have any reliable licensing info that confirm it can be shipped at all.
Regards,
On 04/23/2013 09:37 AM, Alec Leamas wrote:
In a large package (openerp7) I have found some bundled .ttf and .otf font files. One of these (Inconsolata) seems to exist in Fedora as levien-inconsolata-fonts, the others (see below) I cannot find with a quick search.
The fonts are parts of specific addons (a. k. a. plugins). They are referenced with explicit paths in various .css or css/* files.
The entypo-webfont.ttf seems to have a working upstream http://www.entypo.com. I cannot find an upstream for mnmliconsv21-webfont.ttf, hint is that it's generated by "Font Squirrel" ?! There seem to be an upstream for zocial-regular-webfont.ttf, at https://github.com/adamstac/zocial, providing a woff file.
Now, what should I do with these? Packaging GL tells me to "avoid" bundling ttf/otf files. What's this in this case?
Utterly confused. Any hint, out there?
For fonts that are already packaged, you can Require them, and then make symlinks (or patch it to the system location).
For unpackaged fonts with a clear independent upstream, they should be packaged, then see above. ;)
For unpackaged fonts with no clear upstream... I'd check to make sure you know the license on them first. If the upstream for them is the same as the source they come with (and you know this for sure, not assume it), and the license is okay, you can have it go into a fonts subpackage.
Hope that helps,
~tom
== Fedora Project
devel@lists.stg.fedoraproject.org