On 05/03/2013 03:51 PM, Nicolas Mailhot wrote:
Le Lun 29 avril 2013 11:22, Alec Leamas a écrit :
The reply makes me feel a little more confused, on a higher level. How
does that reply translate to the packaging of a web application with
some bundled webfonts ? "scratching my head".
That means that you usually do not need a special format webfont. Serving
the system ttf/otf will work just as well, except for ie (and if your
webapp includes any semi-advanced js it won't work well in ie anyway). Non
ttf/otf webfont formats exist primarily to expose to the browser a file
that can't be used directly in another app (DRMish).
OK, thanks for explanation!
Still hesitating a here: if upstream has decided to support the widest
possible set of browsers (including IE): should we really just drop the
formats required by IE? From a user perspective, I don't really follow
this although I do understand your line of reasoning.
To serve the system ttf/otf font you 'just' need to expose
/usr/share/fonts/whatever in your url space (for example, using apache
alias directives + the usual file permission section)
If you don't want to write web server configuration you will need to write
complex rpm rules to copy at build or install time system fonts in your
webapp directory, and version-lock your package with the system font
packages to propagate changes in those packages in your webapp package. I
doubt it will much easier than writing web server config rules.
Web configuration is not that that scary, indeed ;). And here is an
obvious possibility to package this once and for all in a separate
package like apache-fonts-access exposing the complete font tree, I guess.
Note that in my case the "fonts" are just just images and icons, which
makes the normal font fallback mechanisms useless.
So you think. All fonts are "just images and icons"
I'm truly a font newbie. That said, is there really a meaningful
fallback for a font such as sozial
(https://github.com/adamstac/zocial)? I. e., is there a reasonable
fallback for a Facebook button?
--alec
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
