Description of problem: When going to open Noto CJK fonts on fontforge, fontforge opens an error dialog that claims no cidmap file found. Version-Release number of selected component (if applicable): fontforge-20200314-5.fc32.x86_64 How reproducible: always Steps to Reproduce: 1.fontforge /usr/share/fonts/google-noto-cjk/NotoSansCJK-Regular.ttc 2.Select any family names in the list 3. Actual results: Open an error dialog claims: FontForge was unable to find a cidmap file for this font. It is not essential to have one, but some things will work better if you do. if you have not done so you might want to download the cidmaps from: http://FontForge.sourceforge.net/cidmaps.tgz and then gunzip and untar them and move them to: /usr/share/fontforge Expected results: should start loading a font Additional info:
These files looks static files not changed in last 10 years. Is that fine to package them in fontforge? These files don't need any update? Like they need to be updated for latest Unicode standard release?
Apparently some files are outdated. The format itself looks different but it cames from the character collections defined by Adobe. The latest version of: - Adobe Japan1 is 7: https://github.com/adobe-type-tools/Adobe-Japan1 - Adobe CNS1 is 7: https://github.com/adobe-type-tools/Adobe-CNS1 - Adobe GB1 is 5 (updated): https://github.com/adobe-type-tools/Adobe-GB1 - Adobe KR is 9: https://github.com/adobe-type-tools/Adobe-KR
BTW Adobe Japan2 has been merged and deprecated by Adobe-Japan1-6.
Sine the files are not kept in sync with fontforge releases and are derived from other stuff it would probably be smarter to package them in a different srpm, that can live an independent life version and release-wise
Maybe package adobe-type-tools and make it generate a subpackage in fontforge format that fontforge can depend on?
Perhaps. but currently file format shipped by fontforge is different compared to the original from Adobe. if we are going to ship it as is from github.com/adobe-type-tools, we will need some changes in fontforge. and fortunately or unfortunately we already have in adobe-mappings-cmap as a package in Fedora, which is used for ghostscript.
Well that means we need to consolidate things a bit, to have a single source of truth for the whole text stack. And this is plumbing work… that I understand quite well, given the weeks of plumbing dev I already wasted to adapt font macros to the rpm 4.15 parser changes rpm devs dumped on us just so they could make a 10-line code cleanup
If we get some reply then we can update cidmap files from upstream https://github.com/fontforge/fontforge/issues/4350 and change the License of package to "GPLv3+ and BSD". I think cidmap files are under BSD license.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
The upstream PR https://github.com/fontforge/fontforge/pull/4707 is still in progress. Let's move this to Fedora Linux 35 as we anyway not build new upstream releases for older Fedora Linux releases.
Upstream issue seems merged. we can make some progress on it then?
This is fixed already as part of new upstream release 20220308 built in F36+