To support SVG enabled builds of Firefox and SeaMonkey on OS/2 we need to ship an extra DLL (called mzfntcfg.dll). It is needed to support the font functions in the OS/2 port of cairo, no Mozilla build that depends on it would even start without it, and it would be difficult to make all users aware that it is needed. It would hence not be nice to only offer it as a seperate download. Well, at least this is how I see matters at the moment... There are two components to this bug: 1. Add the FreeType license to about:license (FreeType will be linked into these builds!) 2a. Actually copy the DLL when creating ZIP package or installer 2b. Add to packaging lists for installer
Created attachment 240848 [details] [diff] [review] Add FreeType License to about:license OK, this is for point 1, it adds the FreeType license to about:license for both XPFE and Toolkit builds. I followed the suggestion that Gerv made in mozilla.legal (Thread "Shipping extra DLL", MID SfWdnbTd5q9arpzYnZ2dnUVZ_sednZ2d@mozilla.org).
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Created attachment 240850 [details] [diff] [review] Copy and package mzfntcfg.dll OK, this addresses items 2a and 2b, seems to work.
Hmm, the more I work on this cairo stuff the more it seems to me that this setup sucks big time. All this seems very ugly and hackish. Am I the only one who has this impression? Mike, are your nightlies and releases not SVG enabled for the same reason? I wonder if we should check the mzfntcfgft library files into Mozilla CVS, make them part of the build. That would alleviate any problems with the setup before the build (and the instructions), and we wouldn't even need to copy the DLL afterwards, as it gets copied to dist/bin when it's created. Too late for branch, but maybe something to think about for trunk...
(In reply to comment #3) > Hmm, the more I work on this cairo stuff the more it seems to me that this > setup sucks big time. All this seems very ugly and hackish. Am I the only one > who has this impression? > Mike, are your nightlies and releases not SVG enabled for the same reason? Yes. I've thought about going through the pain, but it seems like a lot of work for not a ton of gain. Have we compared performance of trunk builds with/without Cairo on OS/2? Is anyone using SVG on OS/2?
(In reply to comment #4) > Have we compared performance of trunk builds with/without Cairo on OS/2? I haven't rigorously tested that with numbers, but it doesn't "feel" any different than builds without. The only influence it should have is to startup performance because of the larger DLL/EXE size, right? Yes, measuring that sould be done... > Is anyone using SVG on OS/2? Well, there are lots of SVG games out there and some are really nice. As for serious use, the German statistics agency publishes results of some of their studies as SVG. I saw that Wikipedia starts using SVG graphics, too.
#In reply to comment #4 > Have we compared performance of trunk builds with/without Cairo on OS/2? I've just done some informal testing with Seamonkey trunk (pulled Sep 30). The Cairo enabled Seamonkey seems about 10% faster. 10 secs for cairo enabled vs 11 sec for noncairo on one CPU intensive site (transparent pngs - freedesktop.org). Also starting up to displaying my home pages Cairo enabled takes 15 secs vs 17 secs for non-Cairo. A couple of other pages also seem faster but it is hard to measure accurately. These informal tests need to be taken with a grain of salt as other factors may come into play, eg builds existing on different partitions so disk access varies, fragmentation etc. Still I would say Cairo enabled Seamonkey is at least as fast and probably faster. Also the Cairo enabled Seamonkey has some nice features such as big thumbnail preview of tab when mouse hovering over tab instead of text.
Comment on attachment 240848 [details] [diff] [review] Add FreeType License to about:license OK, whatever we do regarding building and packaging the Freetype bits in the OS/2 builds, we need to ship them somehow. So I ask for a review of the license change patch.
Attachment #240848 - Flags: review?(gerv)
Comment on attachment 240848 [details] [diff] [review] Add FreeType License to about:license This includes far too much :-) According to the licence text itself, binary distributions only need to give a copyright notice/disclaimer, such as: Portions of the OS/2 version of this software are copyright © 1996-2002 <a href="http://www.freetype.org/">The FreeType Project</a>. All rights reserved. Please add that to "Other Required Notices", turning it and the existing text into a two-bullet list. Thanks, Gerv
Attachment #240848 - Flags: review?(gerv) → review-
Created attachment 245335 [details] [diff] [review] Add FreeType copyright notice to about:license Gerv, thanks for the suggestions. This should be better.
Attachment #245335 - Flags: review? → review?(gerv)
Comment on attachment 245335 [details] [diff] [review] Add FreeType copyright notice to about:license r=gerv. Gerv
Attachment #245335 - Flags: review?(gerv) → review+
(In reply to comment #2) > Created an attachment (id=240850)  > Copy and package mzfntcfg.dll > > OK, this addresses items 2a and 2b, seems to work. In the meantime I realized that it would perhaps be more clever, if both mozft.lib and mzfntcfg.lib were static libs. Then we would not need to copy anything afterwards... I therefore updated the support package and uploaded it to Hobbes as mozfntcfgft_26Nov2006.zip. Seems to work fine for me. (I will now also update the build instructions for this package.)
I talked with Lelik over IRC the other day and there is a possibility that ft2lib could be expanded to be used in the place of mzftcfg. It includes basically all of freetype2 now but the functions aren't exported. He is considering exporting them and he said he might possibly add the fontconfig. I am thinking about my next project to be adding the Mozilla freetype support for OS/2. I got the header for ft2lib from Lelik and will look and see if there is anything else we can do with ft2lib within Mozilla.
If you can get it to work without adding another external _requirement_ for Mozilla apps, I am all for it. All the work I did in this regard was so that users can run the apps just like that without having to download another DLL. From what I have seen so far it will be difficult getting to dynamically link to ft2lib at runtime, especially since that would mean that all the changes for that would probably have to go into the cairo library. Or I am not fully getting what you are trying to do.
Well there are 2 parts, one is that if ft2lib is updated as I mentioned then mzftcfg could be replaced with ft2lib so there is less duplication of code. The other thing is only related because I would use either mzftcfg (or ft2lib if it replaces the other) to implement the freetype 2 stuff. If I add anything specific to ft2lib it will be similar to, and maybe use, the MOZILLA_USE_EXTENDED_FT2LIB=T env. variable.
I checked in the reviewed copyright notice addition to trunk. Once Andy has an improved ft2lib we can re-evaluate how this will influence packaging and shipping and if this notice is still needed. With this (and the new "mzfntcfgft", comment 11) I regard this bug as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 245335 [details] [diff] [review] Add FreeType copyright notice to about:license I was previously told that there are l10n concerns about getting this into branch. But as I just noticed that in bug 403164 this was allowed, I just have to try it, too. This should then finally enable us to provide the contributed OS/2 branch releases with SVG/Canvas support, too.
Attachment #245335 - Flags: approval18.104.22.168?
Comment on attachment 245335 [details] [diff] [review] Add FreeType copyright notice to about:license approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #245335 - Flags: approval126.96.36.199? → approval188.8.131.52+
Comment on attachment 240850 [details] [diff] [review] Copy and package mzfntcfg.dll This patch was obsoleted several months ago by the static mzfntcfgft library.
Attachment #240850 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.