Spec URL: http://wenq.org/release/unibit/wqy-unibit.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-1.0.0-1.src.rpm Description: The Wen Quan Yi Unibit is designed as a dual-width (16x16,16x8) bitmap font to provide the most complete international symbol coverage, serving as the system-wide fall-back font. This font has covered 46362 Unicode code points in BMP as to Sep. 2007. It is indented to supersede the outdated GNU Unifont. This font was created by merging the latest update of GNU Unifont [GPL] (by Roman Czyborra and David Starner et al., the font was last updated in 2004??), WenQuanYi Bitmap Song [GPL] 0.8.1 (by Qianqian Fang and WenQuanYi contributors) and Fixed-16x8 [public domain] bitmap fonts from X11 core fonts. The entire CJK Unified Ideographics (U4E00-U9FA5) and CJK Unified Ideographics Extension A(U3400-U4DB5) blocks were replaced by high-quality glyphs from China National Standard GB19966-2005 (public domain). Near a thousand of non-CJK characters were improved by WenQuanYi contributors via their collaborative font editing website at http://wenq.org/eindex.cgi?Unicode_Chart_EN Note 1: I wrote the spec file based on wqy-bitmap-fonts (#230560) for FC5-F7, I built and tested the srpm/rpm on FC6, validated by rpmlint. If the new font mechanism is needed for F8, please let me know and I will write another spec file based on wqy-bitmap-fonts-f8. Note 2: the Hanzi blocks in GNU Unifont are neither complete nor optimized; this font will offer much better bitmap glyphs. A side-by-side comparison between the two fonts can be found at http://wenq.org/gallery/thumbnails.php?album=search&search=wqy-unibit Note 3: the naming of the package follows wqy's existing and coming fonts (wqy-zenhei will be uploaded soon): wqy-unibit, wqy-bitmap-fonts, wqy-zenhei and wqy-univec will all located under %{_datadir}/fonts/wenquanyi for easy management.
Can we call it wqy-unibit-fonts? :)
Thanks for the submission. > Note 1: I wrote the spec file based on wqy-bitmap-fonts > (#230560) for FC5-F7, I built and tested the srpm/rpm on > FC6, validated by rpmlint. If the new font > mechanism is needed for F8, please let me know and > I will write another spec file based on wqy-bitmap-fonts-f8. Usually the package is reviewed for devel (ie that would be F8 currently) so yes it would be better to use %catalogue and not chkfontpath. Also it is preferred that font packages do not explicitly require fontconfig, etc.
I changed the package name to wqy-unibit-fonts, updated the spec file with F8-style commands, and bumped the version to 1.0.0-2. Spec URL: http://wenq.org/release/unibit/wqy-unibit-fonts.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-fonts-1.0.0-2.src.rpm rpmlint complained about the symbol link, however I think those commands were recommended ones, so, I left as is. do you suggest dropping fontconfig from Requires? I am worrying that we have to remove the fc-cache lines from %post/%postun as well, and I don't know if fontconfig will see this font.
(In reply to comment #3) > I changed the package name to wqy-unibit-fonts, updated the spec file with > F8-style commands, and bumped the version to 1.0.0-2. Thanks for the update. :) > rpmlint complained about the symbol link, however I think those commands were > recommended ones, so, I left as is. wqy-unibit-fonts.noarch: W: file-not-utf8 /usr/share/doc/wqy-unibit-fonts-1.0.0/README This would should be fixed IMHO. You could use iconv to do this if you want to keep the upstream encoding. wqy-unibit-fonts.noarch: W: symlink-should-be-relative /etc/X11/fontpath.d/wqy-unibit-fonts/wqy-unibit /usr/share/fonts/wenquanyi/wqy-unibit Right this has been waived in other fonts packages, though IMHO it would not hurt to fix this too, but I do not take it as a blocker. :) > do you suggest dropping fontconfig from Requires? I am worrying that we have > to remove the fc-cache lines from %post/%postun as well, and I don't know if > fontconfig will see this font. No, just the calls to fc-cache should be conditionalized to check that fc-cache is available that is all. See the scriplets in the fonts section: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-4863fc4c93cec14292719d8901d83f5d90c3e477 Most installs normally have fontconfig anyway so it is not such a serious problem I think, but some server configurations might not say.
> See the scriplets in the fonts section: > http://fedoraproject.org/wiki/Packaging/ScriptletSnippets (Sorry nevermind - I see you're already using those. :)
rpmlint on my FC6 did not give the "file-not-utf8" warning. Anyway, I checked the README file, the only place could be no-ascii is the copyright symbol at the header of the file. I removed the symbol and recompiled the rpm, the new spec/srpm can be found at Spec URL: http://wenq.org/release/unibit/wqy-unibit-fonts.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-fonts-1.0.0-3.src.rpm can you help me check if this solves the not-utf8 issue? if it does, I will update the upstream file to match the checksum (I know normally it goes the other way around).
Does it make sense to gzip /usr/share/fonts/wenquanyi/wqy-unibit/wqy-unibit.pcf? Most installed .pcf files seem to be compressed to .pcf.gz - though I don't know the performance implications of doing that? It would be good if upstream would version the directory in the tarball IMHO. (In reply to comment #6) > rpmlint on my FC6 did not give the "file-not-utf8" warning. Probably it is an older version of rpmlint. > Anyway, I checked > the README file, the only place could be no-ascii is the copyright symbol at > the header of the file. I removed the symbol and recompiled the rpm, the new > spec/srpm can be found at Ok, I am not sure what encoding/charset you were using for the (c) sign. > can you help me check if this solves the not-utf8 issue? Yep it does. That should be fine.
A comment on the versioning of the tarball. Rather than wqy-unibit-bdf-1.0.0-1 I would suggest naming it say wqy-unibit-bdf-1.0.0.1 since it is a bit confusing having a release number in the upstream source file. At least for Fedora the idea is that the version number reflects all upstream changes to the source and the release number fedora specific changes.
Created attachment 195561 [details] wqy-unibit-fonts.spec-1.patch The Fedora packaging guidelines suggest not to explicitly require fontconfig. The catalogue symlink should not be in a subdir.
I found a bug in the bdf merging scripts and now there are 80 more glyphs added to the font. I bumped the minor version number and rename the submitted package to 1.1.0-1. the new files can be found at Spec URL: http://wenq.org/release/unibit/wqy-unibit-fonts.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-fonts-1.1.0-1.src.rpm the spec file was patched, and the README file was cleaned. To your questions, gzip the font is not preferred. There has been numerous report on the performance degradation using the gzipped wqy-bitmapsong in the past, for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384149 For big bitmap fonts (with more than 10000 glyphs), gzip the pcf file will produce noticeable latency when firefox loading webpages, causing the CPU load surging to 100%. If space is not a big issue, leaving the font un-zipped is preferred. Need to mention, the best bitmap format is SFNT TTF/OTF, in this case, it will only take <1M and has faster rendering. however, currently freetype/fontconfig does not support this format very well, please see http://www.nabble.com/SFNT-TTF-support-in-fontconfig-tf2132908.html#a5886457 On upstream version number, it is true that our current numbering scheme is different from Fedora's and some others. The last number is an accumulative major release number, rather than the update number for a particular release. However, to change this may cause some other problems, such as nightly build and cvs. So, let's leave it for now, and for packages submitted to Fedora, simply ignore the last number from upstream and use the update number instead.
Ok, thanks, that is all ok. Sorry to keep you waiting so long. Below is my review. Good: + rpmlint is ok wqy-unibit-fonts.noarch: W: symlink-should-be-relative /etc/X11/fontpath.d/wqy-unibit-fonts /usr/share/fonts/wenquanyi/wqy-unibit (this can be waived or you can make it relative by prepending "../.." if you wish. + naming is based on upstream name + meets packaging guidelines + license is gplv2 and included + spec file is clear + source is pristine 751dacd1326cd49b44486b45c592cfa6 wqy-unibit-bdf-1.1.0-1.tar.gz + noarch package builds correctly + buildreqs listed + filelist ok Except the following, all must items are satisfied AFAICS. Needs attention: - both wqy-bitmap-fonts and this package own /usr/share/fonts/wenquanyi Personally I don't feel it is a blocker, but it is against the packaging guidelines: you should probably consider just using /usr/share/fonts/wenquanyi-unibit for this package and similarly for the other package. - Do you think there will be a wqy-unibit-ttf say one day? (just worrying if the name were to be too general)
Jens, can you point me to the link where says this directory arrangement is prohibited (or not preferred)? I thought I read the guideline very carefully. my thought was to use a two-level directory structure to provide a better separation of this font to other fonts in the system, so that the users can easily manage wenquanyi fonts on their system (I thought /usr/share/fonts/zh_CN/TrueType/... is similar). yes, there will be a truetype equivalence for unibit, my plan was to name it as wqy-univec-ttf, this font will probably be released in a couple of months. there is another fonts, wqy-zenhei-ttf is now in public testing http://sourceforge.net/project/showfiles.php?group_id=128192&package_id=242056 I will soon pack it up for Fedora. indeed, the directory structure you proposed is ok with me, if you and the guideline consider it as a better structure, I will change both packages to follow this. let me know.
(In reply to comment #12) > Jens, can you point me to the link where says this directory arrangement is > prohibited (or not preferred)? I thought I read the guideline very carefully. Well it appears on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines: "MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time." > my thought was to use a two-level directory structure to provide a better > separation of this font to other fonts in the system, so that the users can > easily manage wenquanyi fonts on their system (I thought > /usr/share/fonts/zh_CN/TrueType/... is similar). (cjkunifonts is now actually in a separate package for F8 with each font in its own subpackage and subdir.) But anyway fonts-chinese owned both zh_CN/ and zh_CN/TrueType/ and did not share them with any other package in fedora afaik. Perhaps the requirement can be waived for your packages, but I am just pointing out that it does go somewhat against the strict packaging guidelines. > yes, there will be a truetype equivalence for unibit, my plan was to name it > as wqy-univec-ttf, this font will probably be released in a couple of months. Ok, then probably it can be called something like wqy-univec-fonts... > there is another fonts, wqy-zenhei-ttf is now in public testing : > I will soon pack it up for Fedora. Great.
I see, I think the requirement for not-sharing-ownership is quite reasonable. I will move this package to /usr/share/fonts/wenquanyi-unibit and update the spec/srpm by the end of the day. thank you Jens
the new spec/srpm (1.1.0-2) were uploaded to Spec URL: http://wenq.org/release/unibit/wqy-unibit-fonts.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-fonts-1.1.0-2.src.rpm the install directory was changed to /usr/share/fonts/wqy-unibit the relative path seems a little bit confusing to me because of %{buildroot}. so, for this update, I kept the absolute path. maybe in the future, if I get better understanding, I will correct this problem.
sorry, I think /usr/share/fonts/wenquanyi-unibit might be better than .../wqy-unibit Spec URL: http://wenq.org/release/unibit/wqy-unibit-fonts.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-fonts-1.1.0-3.src.rpm
Few more comments: - you don't need %fontconfdir - please use %{version} in Source field - not sure if %wqyroot is really necessary if it is only used in one place - don't need to create (touch) fonts.dir in %install One more time about the name: wqy-unibit-fonts is fine but if you prefer it could also be wqy-unibit-bdf-fonts which seems closer to the upstream name. Either is fine and it is up to you, as long as we keep consistent naming within fedora and relative to upstream.
thanks Jens for the careful review, suggested changes were patched into the spec/srpm Spec URL: http://wenq.org/release/unibit/wqy-unibit-fonts.spec SRPM URL: http://wenq.org/release/unibit/wqy-unibit-fonts-1.1.0-4.src.rpm I prefer the current package name, it is indeed a pcf format font (the upstream package is a bdf source file, but when build the rpm, it was converted to pcf), so, wqy-unibit-fonts is more accurate than -bdf-.
Thanks for the update. AFAICS all issues have been addressed now and the package looks fine to me. :-) I think the changelog would be easier to read with the usual spaces between entries (like you also do for wqy-bitmap-fonts). Package is APPROVED.
Please follow http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure to request adding the module to cvs. Thank you for your contribution again to Fedora.
thank you Jens!
New Package CVS Request ======================= Package Name: wqy-unibit-fonts Short Description: A dual-width bitmap font for maximum unicode coverage Owners: fangqq Branches: FC-5 FC-6 F-7 InitialCC: petersen Cvsextras Commits: yes
2 notes for future requests: - Please use your fedora account name, not email address. - We no longer do FC-5 branches. FC-5 is end of life and no longer supported. cvs done.
Qianqian, please import and build when you're ready.
sorry for the delay. Package was imported to devel/F-7/F-6 and built with no problems. I also pushed the package for testing on bodhi system; if it turns out no other problem, I will push it to release. one side question: where can I find the "CVE" string for this package? it was asked on Bodhi new update page, I can not find it on http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAF
Thanks! You don't need to worry about CVE for this update - it is for security updates.
wqy-unibit-fonts-1.1.0-4.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update wqy-unibit-fonts'
wqy-unibit-fonts-1.1.0-4.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.