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, -- Nicolas Mailhot -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
