Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Outdated or wrong CIDMaps? #1831

Open
ahyangyi opened this issue Oct 21, 2014 · 9 comments
Open

Outdated or wrong CIDMaps? #1831

ahyangyi opened this issue Oct 21, 2014 · 9 comments
Labels
CID duplicate

Comments

@ahyangyi
Copy link
Contributor

I noticed that some glyphs are missing when I use Fontforge to open Noto Sans CJK SC. The fonts can be downloaded at https://www.google.com/get/noto/cjk.html .

An example would be the character '量', which, according to all systems and applications, are present in Noto Sans CJK SC. Also it's a commonly used character in all variants of CJK languages. But If you use fontforge to import the fonts you won't be able to find this character.

I am still using the old CIDMaps from the old fontforge website. Does anyone know of a newer version, or is there any potential fix to this problem?
@adrientetar
Copy link
Member

Possibly a duplicate of #1534, #1582.

@HinTak
Copy link

HinTak commented Jun 9, 2017

I think it is a variation of #3085 and #3080 . Noto Sans CJK fonts have about 400 glyphs encoding to two code points. About a dozen to 3 code points, actually.

@HinTak
Copy link

HinTak commented Jun 9, 2017

It would be nice if MultipleEncodingsToReferences() does the right thing - it currently does not.

@HinTak
Copy link

HinTak commented Jun 9, 2017

What's happening is that the Source CJK fonts / Noto CJK fonts have about 400 glyphs having more than 2 coding points; actually about a dozen have 3. All but one is silently dropped by fontforge. So you get about 400 coding points missing when re-encoding.

The worst part of fontforge behaviour is that it uses the last one it sees as authoritative - that's often the CJK Compat variant range, rather than the lower CJK Unified region. So the lower and more often-used CJK Unified code range ended up having about 400 glyphs missing.

@HinTak
Copy link

HinTak commented Jun 9, 2017

fontforge cannot cope with glyphs mapping to multiple encoding points. In summary.

@HinTak
Copy link

HinTak commented Jun 9, 2017 •
edited

The cidmap is not wrong - it is just that fontforge cannot currently cope. The author(s) of fontforge seems not to be able to comprehend the need for one glyph to multiple coding points properly. Source CJK/Noto CJK have about 400 of those, and the glyphs are missing from the lower CJK Unified range, as fontforge prefers to use the upper Compat variant as authoritative encoding for such glyphs. When you list the glyphs by the encoding vector (i.e. Unicode).

@HinTak
Copy link

HinTak commented Jun 9, 2017 •
edited

My freetype-py script to fix fontforge's encoding problem is up at

https://github.com/HinTak/freetype-py/blob/fontval-diag/examples/subfonts-script-generate.py

@jtanx jtanx added the CID label May 4, 2020
@ctrlcctrlv ctrlcctrlv mentioned this issue Jan 9, 2021
Closed
@ahyangyi
Copy link
Contributor Author

@yg8ijvjvjv OpenType OTF and CID are not mutually exclusive concepts.

https://www.adobe.com/content/dam/acom/en/devnet/font/pdfs/5149.OTFname_Tutorial.pdf

@skef skef mentioned this issue Jan 21, 2021
Merged
ctrlcctrlv added a commit that referenced this issue Apr 15, 2021
@ctrlcctrlv
Install cidmaps by default
686b941 
There's no reason not to do this. We already distribute them as part of
the repository.

* Closes #4411.
* Closes #4350.
* Related also to #1831. After we make it so we're installing the
  cidmaps in the repo, it would make sense to assure that they're
  actually the most up-to-date ones.
This was referenced Apr 15, 2021
Merged
Closed
jtanx pushed a commit that referenced this issue Oct 5, 2021
@ctrlcctrlv @jtanx
Install cidmaps by default
393ee87 
There's no reason not to do this. We already distribute them as part of
the repository.

* Closes #4411.
* Closes #4350.
* Related also to #1831. After we make it so we're installing the
  cidmaps in the repo, it would make sense to assure that they're
  actually the most up-to-date ones.
jtanx pushed a commit that referenced this issue Oct 5, 2021
@ctrlcctrlv @jtanx
Install cidmaps by default
d22ffc5 
There's no reason not to do this. We already distribute them as part of
the repository.

* Closes #4411.
* Closes #4350.
* Related also to #1831. After we make it so we're installing the
  cidmaps in the repo, it would make sense to assure that they're
  actually the most up-to-date ones.
jtanx pushed a commit that referenced this issue Oct 5, 2021
@ctrlcctrlv @jtanx
Install cidmaps by default
f97a2cd 
There's no reason not to do this. We already distribute them as part of
the repository.

* Closes #4411.
* Closes #4350.
* Related also to #1831. After we make it so we're installing the
  cidmaps in the repo, it would make sense to assure that they're
  actually the most up-to-date ones.
Omnikron13 pushed a commit to Omnikron13/fontforge that referenced this issue May 31, 2022
@ctrlcctrlv @jtanx
Install cidmaps by default
1a78c66 
There's no reason not to do this. We already distribute them as part of
the repository.

* Closes fontforge#4411.
* Closes fontforge#4350.
* Related also to fontforge#1831. After we make it so we're installing the
  cidmaps in the repo, it would make sense to assure that they're
  actually the most up-to-date ones.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CID duplicate
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ahyangyi @adrientetar @jtanx @HinTak and others