Hi!
I'm trying to package a web application with bundled fonts. These fonts are used by the web clients (browsers), and just served from the Fedora webapp. The case is similar to javascript .js files.
Trying to package the webfonts as dependencies I have run into problem together with my reviewer. Basically, we don't know what to do. Some questions:
- Where should webfonts be stored? A specific dir would be good, since some fonts exists in both a webfont and desktop variant with the same filenames. - How shoulld webapps get access to the system webfont? Is the apache config file approach used for ..js files, where the webapp gets access to specific system paths, usable also here? - Given that the primary concern about fonts seems to be licensing, is it really meaningful to unbundle them?
This is the short story. The somewhat longer: https://fedorahosted.org/fpc/ticket/277
Any help, out there?
--alec
On 04/27/2013 01:49 PM, Alec Leamas wrote:
I'm trying to package a web application with bundled fonts. These fonts are used by the web clients (browsers), and just served from the Fedora webapp. The case is similar to javascript .js files.
Trying to package the webfonts as dependencies I have run into problem together with my reviewer. Basically, we don't know what to do. Some questions:
- Where should webfonts be stored? A specific dir would be good, since
some fonts exists in both a webfont and desktop variant with the same filenames.
- How shoulld webapps get access to the system webfont? Is the apache
config file approach used for ..js files, where the webapp gets access to specific system paths, usable also here?
- Given that the primary concern about fonts seems to be licensing, is
it really meaningful to unbundle them?
This is the short story. The somewhat longer: https://fedorahosted.org/fpc/ticket/277
Any help, out there?
I had the same answer few months ago and got this answer: http://lists.fedoraproject.org/pipermail/packaging/2012-December/008783.html
On 04/29/2013 11:04 AM, Miroslav Suchý wrote:
On 04/27/2013 01:49 PM, Alec Leamas wrote:
I'm trying to package a web application with bundled fonts. These fonts are used by the web clients (browsers), and just served from the Fedora webapp. The case is similar to javascript .js files.
Trying to package the webfonts as dependencies I have run into problem together with my reviewer. Basically, we don't know what to do. Some questions:
- Where should webfonts be stored? A specific dir would be good, since
some fonts exists in both a webfont and desktop variant with the same filenames.
- How shoulld webapps get access to the system webfont? Is the apache
config file approach used for ..js files, where the webapp gets access to specific system paths, usable also here?
- Given that the primary concern about fonts seems to be licensing, is
it really meaningful to unbundle them?
This is the short story. The somewhat longer: https://fedorahosted.org/fpc/ticket/277
Any help, out there?
I had the same answer few months ago and got this answer: http://lists.fedoraproject.org/pipermail/packaging/2012-December/008783.html
Thanks! I knew I had seen this message somewhere, but lost it...
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".
Note that in my case the "fonts" are just just images and icons, which makes the normal font fallback mechanisms useless. They are needed, period.
--alec
On 04/29/2013 11:22 AM, Alec Leamas wrote:
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".
Me too :)
Note that in my case the "fonts" are just just images and icons, which makes the normal font fallback mechanisms useless. They are needed, period.
Well it is not defined in policy. You will be pioneer. Let package it as you think it is best. If somebody will disagree he will write bugzilla or will submit policy guidelines.
Le Ven 3 mai 2013 14:45, Miroslav Suchý a écrit :
Note that in my case the "fonts" are just just images and icons, which makes the normal font fallback mechanisms useless. They are needed, period.
Well it is not defined in policy.
Actually, the current policy forbids fonts anywhere but in the standard filesystem paths
https://fedoraproject.org/wiki/Packaging:FontsPolicy
“Packagers MUST package each font family in a separate (noarch.rpm) (sub)package” “Creating font packages or subpackages in Fedora is done using the fontpackages-devel package”
And fontpackages-devel won't let you install fonts anywhere but in the standard paths.
I'm not convinced at all this needs changing, since mod_alias permits mapping of system paths anywhere you want in your URL space.
"NM" == Nicolas Mailhot nicolas.mailhot@laposte.net writes:
NM> I'm not convinced at all this needs changing, since mod_alias NM> permits mapping of system paths anywhere you want in your URL space.
But selinux probably doesn't, so the issue is slightly more complicated.
- J<
Le Ven 3 mai 2013 16:24, Jason L Tibbitts III a écrit :
"NM" == Nicolas Mailhot nicolas.mailhot@laposte.net writes:
NM> I'm not convinced at all this needs changing, since mod_alias NM> permits mapping of system paths anywhere you want in your URL space.
But selinux probably doesn't, so the issue is slightly more complicated.
I don't think selinux will block web server accesses to /usr/share/fonts/something, since we deploy webapps in /usr/share/something_else, which is pretty much the same namespace.
If selinux wanted to filter accesses to /usr/share/fonts, a ro rule would be sufficient IMHO
"NM" == Nicolas Mailhot nicolas.mailhot@laposte.net writes:
NM> I don't think selinux will block web server accesses to NM> /usr/share/fonts/something, since we deploy webapps in NM> /usr/share/something_else, which is pretty much the same namespace.
Well, there are a whole lot of specific fcontext entries for content in /usr/share, including fonts which get their own type (fonts_t). I certainly wouldn't assume that it would simply work, though it would be fairly easy for the policy to adapt if it didn't. My point was simply that there are other configurations besides "fix it with mod_alias".
- J<
On Fri, 2013-05-03 at 10:15 -0500, Jason L Tibbitts III wrote:
"NM" == Nicolas Mailhot nicolas.mailhot@laposte.net writes:
NM> I don't think selinux will block web server accesses to NM> /usr/share/fonts/something, since we deploy webapps in NM> /usr/share/something_else, which is pretty much the same namespace.
Well, there are a whole lot of specific fcontext entries for content in /usr/share, including fonts which get their own type (fonts_t). I certainly wouldn't assume that it would simply work, though it would be fairly easy for the policy to adapt if it didn't. My point was simply that there are other configurations besides "fix it with mod_alias".
Yeah. Obviously the sensible thing is to check, but since httpd is such a sensitive component, it has a very restrictive selinux policy. I tend to treat it as a rule of thumb that httpd can't read anything unless it's httpd_sys_content_t or httpd_sys_rw_content_t . It's *certainly* not safe to assume that httpd can or should be able to 'at least read' any old thing in /usr , or /usr/share , or any other system path; vulnerabilities that let some webapp read /etc/passwd or some other sensitive file are a dime a dozen, and that's certainly one of the things SELinux aims to mitigate.
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).
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.
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"
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
Le Ven 3 mai 2013 21:06, Alec Leamas a écrit :
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.
Here is the current status of @font-face ttf/otf support in browsers: http://caniuse.com/ttf
Normal opentype files work in the latest versions of all browsers (except opera mini :p)
Adding special webfont formats is not worth the pain, and anyway the main use would be old ie versions, that require eot which is not a really open format.
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?
I think spot will agree there is no way we'll ever ship a font consisting of company logos, it's trademark hell (this is another example that proves the wisdom of checking every font, even 'special' 'embedded' ones)
On 05/03/2013 09:50 PM, Nicolas Mailhot wrote:
[cut]
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?
I think spot will agree there is no way we'll ever ship a font consisting of company logos, it's trademark hell (this is another example that proves the wisdom of checking every font, even 'special' 'embedded' ones)
My bad, here is no FB button. See the font overview in http://leamas.fedorapeople.org/tmp/zocial.png.
I'll bring this to the fedora-legal list.
--alec
On Fri, May 3, 2013 at 12:50 PM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
I think spot will agree there is no way we'll ever ship a font consisting of company logos, it's trademark hell
We ship *lots* of trademarked logos. In Firefox alone there are trademarked logos from Mozilla, Google, Amazon, Yahoo!, Microsoft, eBay, and Twitter. As long as we're complying with the trademark guidelines for them, it shouldn't be a problem.
-T.C.
Le Dim 5 mai 2013 06:40, T.C. Hollingsworth a écrit :
On Fri, May 3, 2013 at 12:50 PM, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
I think spot will agree there is no way we'll ever ship a font consisting of company logos, it's trademark hell
We ship *lots* of trademarked logos. In Firefox alone there are trademarked logos from Mozilla, Google, Amazon, Yahoo!, Microsoft, eBay, and Twitter. As long as we're complying with the trademark guidelines for them, it shouldn't be a problem.
There is a difference between sparse logo use in Firefox (which is almost sure to have been audited to hell Mozilla-side) and a huge collection of company logos in a random github repo. github is hardly known for good legal practices
On 05/03/2013 09:50 PM, Nicolas Mailhot wrote:
Le Ven 3 mai 2013 21:06, Alec Leamas a écrit :
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.
Here is the current status of @font-face ttf/otf support in browsers: http://caniuse.com/ttf
Normal opentype files work in the latest versions of all browsers (except opera mini :p)
Adding special webfont formats is not worth the pain, and anyway the main use would be old ie versions, that require eot which is not a really open format.
This seems to mean that we force web applications to exclude IE version 8 (and older) clients. As this seems to be a widely used IE version today, is this really the way to go?
In my specific case openerp7, a business server application often used in company environments, the IE8- share is probably larger than average. It's certainly the most common client used at many sites.
The argument that the format is non-open: is this really a blocker?
[cut]
--alec
On 2013-05-05 10:19 (GMT+0200) Alec Leamas composed:
Nicolas Mailhot wrote:
Here is the current status of @font-face ttf/otf support in browsers: http://caniuse.com/ttf ...
This seems to mean that we force web applications to exclude IE version 8 (and older) clients. As this seems to be a widely used IE version today...
Note that the current IE version is 8 for WinXP users. Minimum OS version for IE9+ is Vista, which explains the seeming popularity of IE8.
Le Dim 5 mai 2013 11:27, Felix Miata a écrit :
On 2013-05-05 10:19 (GMT+0200) Alec Leamas composed:
Nicolas Mailhot wrote:
Here is the current status of @font-face ttf/otf support in browsers: http://caniuse.com/ttf ...
This seems to mean that we force web applications to exclude IE version 8 (and older) clients. As this seems to be a widely used IE version today...
Note that the current IE version is 8 for WinXP users. Minimum OS version for IE9+ is Vista, which explains the seeming popularity of IE8.
And XP is out-of-support Microsoft-side. So any company use (that is what is being talked about here) is likely to stop soonish
On 2013-05-05 11:44 (GMT+0200) Nicolas Mailhot composed:
XP is out-of-support Microsoft-side.
For what definition of "out-of-support"?
http://www.microsoft.com/en-us/windows/endofsupport.aspx
Considering Fedora release lifetimes, WinXP seems to have abundant life left.
Le Dim 5 mai 2013 12:01, Felix Miata a écrit :
On 2013-05-05 11:44 (GMT+0200) Nicolas Mailhot composed:
XP is out-of-support Microsoft-side.
For what definition of "out-of-support"?
http://www.microsoft.com/en-us/windows/endofsupport.aspx
Considering Fedora release lifetimes, WinXP seems to have abundant life left.
If you take into account the time between new package creation, and its release as part of a new Fedora version, 'abundant' seems quite optimistic to me (not to mention that MS OS "support" is limited to the system itself, ie in the last years of windows 2000 "support" you could not find any supported app to install on it). Esp. when the package is a complex beast like an erp — that requires at least a few months of testing before going into production.
Le Dim 5 mai 2013 10:19, Alec Leamas a écrit :
This seems to mean that we force web applications to exclude IE version 8 (and older) clients. As this seems to be a widely used IE version today, is this really the way to go?
It seems to be a case of Fedora being first and Microsoft being last :p
In my specific case openerp7, a business server application often used in company environments, the IE8- share is probably larger than average. It's certainly the most common client used at many sites.
Are you sure it works well in IE8 at all? Because there are lots of other reasons a modern web site will fail in old ie versions
The argument that the format is non-open: is this really a blocker?
Generally speaking, it's a PITA to ship fonts in multiple formats, you're never quite sure they are properly synchronized and that a bug does not lurk in a specific implementation, and it's a space waster. I guess that for the specific case of ie-only eot fonts it could be done (woff is cleaner but does not gain you significant browser coverage compared to otf/ttf). However that would require : 1. generating eot fonts ourselves from the base fonts using eot-tools 2. defining where they are put on the filesystem (probably not in /usr/share/fonts since no linux app that I know can use them) 3. defining the naming of eot (sub)packages 4. adjusting guidelines, documenting on the wiki and getting them FPC-approved
I was sort of hopping the "problem" would go away with adoption of direct opentype support in all browsers, but if you want to do the work, be my guest :)
Regards,
On 05/05/2013 11:40 AM, Nicolas Mailhot wrote:
Le Dim 5 mai 2013 10:19, Alec Leamas a écrit :
This seems to mean that we force web applications to exclude IE version 8 (and older) clients. As this seems to be a widely used IE version today, is this really the way to go?
It seems to be a case of Fedora being first and Microsoft being last :p
In my specific case openerp7, a business server application often used in company environments, the IE8- share is probably larger than average. It's certainly the most common client used at many sites.
Are you sure it works well in IE8 at all? Because there are lots of other reasons a modern web site will fail in old ie versions
Double checking... and you're right, openerp only supports IE 9+.
Which means that I could indeed go for using ttf/otf only. Other folks might have interest in this, don't know, but as fas as I am concerned this resolves some loose ends.
I'm still not convinced that it makes sense to package a font like zocial like a regular desktop font (leaving legal issues aside here). There is also the case when a package contains both a webfont and a desktop font (with different ttf files). Something like a /usr/share/fonts/webfonts for fonts packaged solely as a web static resource might possibly be a solution, I guess (?)
--alec
Le Dim 5 mai 2013 12:30, Alec Leamas a écrit :
On 05/05/2013 11:40 AM, Nicolas Mailhot wrote:
Are you sure it works well in IE8 at all? Because there are lots of other reasons a modern web site will fail in old ie versions
Double checking... and you're right, openerp only supports IE 9+.
Which means that I could indeed go for using ttf/otf only. Other folks might have interest in this, don't know, but as fas as I am concerned this resolves some loose ends.
I'm still not convinced that it makes sense to package a font like zocial like a regular desktop font (leaving legal issues aside here).
Why not? People use all kind of symbol fonts in presentations and other documents (they *love* their symbol fonts, that was a major driver for dejavu adoption). As long as the font is technically sane and you've been careful enough to assign it a low priority in fontconfig there is no problem
Don't forget, that browsers also use system fonts, so if you don't install the fonts in a standard place you're forcing all your Fedora web clients to download it dynamically from the web site.
There is also the case when a package contains both a webfont and a desktop font (with different ttf files). Something like a /usr/share/fonts/webfonts for fonts packaged solely as a web static resource might possibly be a solution, I guess (?)
Well as we've established there: 1. the only "useful" webfont format is eot (to reach users of old ie versions, all major browsers except ie are easily upgradable and support normal opentype fonts and there is no restriction on using opentype for floss fonts) 2. it's only useful for the very narrow range of web applications that use bleeding-edge html5 tricks like webfonts but still work with the braindamaged web engines included in ie < 9
So if you wanted to do webfonts, the correct way would be to define a filesystem root such as /usr/share/eot-fonts (not a /usr/share/fonts/ subdirectory, that would pollute fontconfig space)
But I doubt the intersection of fedora packages, large ie < 9 population, html5-webapp, oldie-compatible-webapp amounts to much. So why bother.
Regards,
Hi,
I would like to reopen the discussion about packaging web fonts since its conclusion(below) is not very usable.
The issue I'm dealing with is that we want FreeIPA Web UI to use Open Sans and Font Awesome(FA) font. FA is being packaged and I planned to package Open Sans (Apache license v2). But TTF versions of both fonts will fail in IE.
OTF/TTF fails in all modern versions of IE when the font does not have embedding permissions set to 'installable' [1]. It's more common that one would say. This behavior is considered as a feature (probably won't be changed anytime soon).
Adding WOFF format would fix IE 9+ and IE mobile [2]. Adding EOT would fix IE 6+ [3].
Influencing upstream to fix the permission is not usable when upstream is dead or not clear.
IMHO packaging guidelines should not control which clients packaged web app should support, and therefore political discussion about IE is not very relevant when technical solution exists.
Those are the reasons why I don't agree with the statement that OTF/TTF should cover majority of cases and therefore we should not allow packaging/care about other formats.
So the questions is: *Should packaging of WOFF and EOT be explicitly allowed by packaging rules?*
Subsequent Qs like "Where?" and "What about the already packaged fonts" don't matter until the main Q is answered.
[1] http://caniuse.com/ttf [2] http://caniuse.com/woff [3] http://caniuse.com/eot
Regards,
Le Mer 27 novembre 2013 15:39, Petr Vobornik a écrit :
Hi,
I would like to reopen the discussion about packaging web fonts since its conclusion(below) is not very usable.
The issue I'm dealing with is that we want FreeIPA Web UI to use Open Sans and Font Awesome(FA) font. FA is being packaged and I planned to package Open Sans (Apache license v2). But TTF versions of both fonts will fail in IE.
OTF/TTF fails in all modern versions of IE when the font does not have embedding permissions set to 'installable' [1]. It's more common that one would say.
Of course it is very common, it's the default setting in most font authoring tools, and the authors of those tools were very much against web fonts in the first place. So font authors that actually want to do web fonts and actually choose free font licenses get betrayed by their tooling. And a lot of them do not care for ie at all anyway.
Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation.
This behavior is considered as a feature (probably won't be changed anytime soon).
MS started saying they would never support anything but eot Then they admitted they could do woff but really, never TTF/OTF Then they had to implement TTF/OTF anyway, but added this silly restriction.
Is that their last word? Who actually believes that? They're still losing market share
Regards,
Nicolas Mailhot wrote:
Le Mer 27 novembre 2013 15:39, Petr Vobornik a écrit :
OTF/TTF fails in all modern versions of IE when the font does not have embedding permissions set to 'installable' [1]. It's more common that one would say.
Of course it is very common, it's the default setting in most font authoring tools, and the authors of those tools were very much against web fonts in the first place. So font authors that actually want to do web fonts and actually choose free font licenses get betrayed by their tooling. And a lot of them do not care for ie at all anyway.
Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation.
Perhaps we should add this to the font packaging guidelines?
Flipping through the 235 packaged fonts installed on my system, I see that 26 of them have fsType fields that limit embedding rights. The ones affected are those from smaller "foundries" and OFLB, as you might expect, but also Droid Sans, which was a surprise.
On 11/28/2013 02:25 PM, Paul Flo Williams wrote:
Nicolas Mailhot wrote:
Le Mer 27 novembre 2013 15:39, Petr Vobornik a écrit :
OTF/TTF fails in all modern versions of IE when the font does not have embedding permissions set to 'installable' [1]. It's more common that one would say.
Of course it is very common, it's the default setting in most font authoring tools, and the authors of those tools were very much against web fonts in the first place. So font authors that actually want to do web fonts and actually choose free font licenses get betrayed by their tooling. And a lot of them do not care for ie at all anyway.
Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation.
OK, seems to be the easiest way. Originally, I wanted to avoid it because idk what is the correct way. I've created a simple script to do it:
#!/usr/bin/fontforge i=1 while ( i<$argc ) Open($argv[i]) SetOS2Value("FSType", 0) # set 'Embeddable' to 'Installable Font' fmflags = 0x800 # generate old kern table Generate($argv[i]:r + ".ttf", "", fmflags) i = i+1 endloop
The script is not good because it doesn't touch only OS/2 table but it regenerates the whole font file (different GPOS, dropping DSIG and without fmflags also dropping KERN table).
I've also tried to use ttx with a hope that it won't touch other tables, but it crashed on parsing OpenSans font.
Perhaps we should add this to the font packaging guidelines?
+1
Flipping through the 235 packaged fonts installed on my system, I see that 26 of them have fsType fields that limit embedding rights. The ones affected are those from smaller "foundries" and OFLB, as you might expect, but also Droid Sans, which was a surprise.
Petr Vobornik wrote:
Nicolas Mailhot wrote:
Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation.
OK, seems to be the easiest way. Originally, I wanted to avoid it because idk what is the correct way. I've created a simple script to do it:
[snip]
The script is not good because it doesn't touch only OS/2 table but it regenerates the whole font file (different GPOS, dropping DSIG and without fmflags also dropping KERN table).
I've also tried to use ttx with a hope that it won't touch other tables, but it crashed on parsing OpenSans font.
Considering changing fsType is just a change to 16 bits + a 32-bit checksum, it shouldn't be necessary to regenerate the entire font. In fact, Tom7 created a program to do just this job many years ago, called "embed":
http://carnage-melon.tom7.org/embed/
I've just improved this to recalculate the OS/2 table checksum correctly and handle multiple fonts in one go:
https://github.com/hisdeedsaredust/ttembed
If you'd like to package this as well, you could use it in your Open Sans package and you'd have something else to show sponsors :-)
On 11/30/2013 09:04 PM, Paul Flo Williams wrote:
Petr Vobornik wrote:
Nicolas Mailhot wrote:
Just write a fontforge or ttx script that flips this bit at rpm build time, assuming you've done your legal review correctly the bit is in contradiction with the font license (if the font was no installable we could not package it in the first place). You'll be doing nothing more than fixing a bug in upstream's font implementation.
OK, seems to be the easiest way. Originally, I wanted to avoid it because idk what is the correct way. I've created a simple script to do it:
[snip]
The script is not good because it doesn't touch only OS/2 table but it regenerates the whole font file (different GPOS, dropping DSIG and without fmflags also dropping KERN table).
I've also tried to use ttx with a hope that it won't touch other tables, but it crashed on parsing OpenSans font.
Considering changing fsType is just a change to 16 bits + a 32-bit checksum, it shouldn't be necessary to regenerate the entire font. In fact, Tom7 created a program to do just this job many years ago, called "embed":
http://carnage-melon.tom7.org/embed/
I've just improved this to recalculate the OS/2 table checksum correctly and handle multiple fonts in one go:
https://github.com/hisdeedsaredust/ttembed
If you'd like to package this as well, you could use it in your Open Sans package and you'd have something else to show sponsors :-)
This solution is much nicer and can be used by other font packages as well.
Here's the new package: https://bugzilla.redhat.com/show_bug.cgi?id=1036754
On Mon, Dec 2, 2013 at 8:33 AM, Petr Vobornik pvoborni@redhat.com wrote:
This solution is much nicer and can be used by other font packages as well.
Here's the new package: https://bugzilla.redhat.com/show_bug.cgi?id=1036754
Very awesome, thanks! I'll sponsor you and review. :-)
Luckily, I pushed off the web assets stuff for F21, so I can now add embedding to the list of things to check and file bugs for when I do that for the licensing metadata. I'm going to be doing that real soon now, so if there are any other issues that all the fonts in the distro need to be checked for, please speak up soon!
I'll also ask FPC to add a mention of this to the font guidelines so future fonts added to the distribution will have this bit set correctly.
-T.C.
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Alec Leamas -
Felix Miata -
Jason L Tibbitts III -
Miroslav Suchý -
Nicolas Mailhot -
Paul Flo Williams -
Petr Vobornik -
Reindl Harald -
T.C. Hollingsworth