adobe-fonts / source-han-serif Goto Github PK

I am wondering whether the kana of SHSerif is mostly optimized for vertical texts (looks really beautiful to me). However, I couldn't find a way (like that in SHSans) to enable proportional kana for SHSerif at this moment. I am afraid it is not fair to the designer for leaving such question here or giving my opinions to this question until there is an approach to enable proportional kana.

Glyph 啟(U+555f) and 啓(U+5553) with wrong mapping in Traditional Chinese version.

In MOE standard, 戶 part should be started with 撇 (left-falling stroke), not 點 (dot).
Source Han Serif TC map to the SC ones, but they was correct in Source Han Sans.
It's good to mapping to Korean style ones.

Nuked.

所使用的字型：NotoSerifCJKtc-Black.otf 【注意是tc】

^在Android中顯示為中國（大陸）標準字形，此為錯誤顯示。

^在Windows 7中顯示為臺灣的國字標準字體，此為正確顯示。

The CN Design for characters containing 界 is rather odd in that the bottom 介 is written with 人 under 田 instead of 八 under 田:

As far as the code charts are concerned, the CN glyphs should match the JP glyphs with legs departing from 田 instead of departing under 田.

This issue is meant for tracking and submitting suggestions for character/glyph additions, meaning characters that are within the scope of coverage that are not yet supported, or that a supported character lacks an appropriate glyph for a supported language or region.

Special Note: If a character falls outside of a supported standard, meaning GB 18030 for China, Big Five for Taiwan, JIS (X 0208, X 0213, and X 0212) for Japan, or KS (X 1001 or X 1002) for Korea, please refrain from making a suggestion at this time. We need to make sure that support for these standards is adequate before we start to expand the scope of character/glyph coverage.

Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following glyphs were added in Version 1.001:

• Added CN glyphs for U+35EB 㗫, U+385C 㡜, U+5015 倕, U+618F 憏, U+63EF 揯, U+6456 摖, U+6660 晠, U+66A9 暩, U+68B1 梱, U+6F08 漈, U+78DC 磜, U+7A44 穄, U+92EE 鋮, U+969B 際, U+9BCE 鯎, and U+9C36 鰶, uni35EB-CN, uni385C-CN, uni5015-CN, uni618F-CN, uni63EF-CN, uni6456-CN, uni6660-CN, uni66A9-CN, uni68B1-CN, uni6F08-CN, uni78DC-CN, uni7A44-CN, uni92EE-CN, uni969B-CN, uni9BCE-CN, and uni9C36-CN, respectively, per Issue #27.
• Added CN glyph for U+7808 砈, uni7808-CN, per Issue #36.
• Added TW glyphs for U+4FB9 侹, U+5EAD 庭, U+5EF7 廷, U+633A 挺, U+6883 梃, U+6D8F 涏, U+6DEB 淫, U+73FD 珽, U+7D8E 綎, U+7F54 罔, U+8713 蜓, U+8DA3 趣, U+92CC 鋌, U+95AE 閮, and U+9832 頲, uni4FB9-TW, uni5EAD-TW, uni5EF7-TW, uni633A-TW, uni6883-TW, uni6D8F-TW, uni6DEB-TW, uni73FD-TW, uni7D8E-TW, uni7F54-TW, uni8713-TW, uni8DA3-TW, uni92CC-TW, uni95AE-TW, and uni9832-TW, respectively, per Issue #39.
• Added CN glyph for U+76E4 盤 and U+7A07 稇, uni76E4-CN and uni7A07-CN, respectively, per Issue #39.
• Added CN glyphs for U+57F5 埵, U+7BA0 箠, U+83D9 菙, and U+9318 錘, uni57F5-CN, uni7BA0-CN, uni83D9-CN, and uni9318-CN, respectively.

Post Version 1.001 Additions:

• Add TW glyph for U+5433 吳, uni5433-TW, per Issue #39.
• Add CN glyphs for U+3A17 㨗 and U+2967F 𩙿, uni3A17-CN and u2967F-CN, respectively, per Issue #55.
• Add a CN for U+5DC6 巆, uni5DC5-CN, per Issue #56.
• Add a CN glyph for U+8D17 贗, uni8D17-CN, by renaming then removing its TW glyph, uni8D17-TW, per Issue #56.
• Add a CN glyph for U+3402 㐂, uni3402-CN, per Issue #57.
• Add a KR glyph for U+5002 倂, uni5002-KR, per Issue #59.
• Add JP glyphs for For U+54E5 哥 and U+68D7 棗, uni54E5-JP (aka Adobe-Japan1-6 CID+4378) and uni68D7-JP (aka Adobe-Japan1-6 CID+5224), respectively, per Issue #60.
• Add a KR glyph for U+8F27 輧, uni8F27-KR, per Issue #60.
• Add KR glyphs for U+6424 搤, U+7662 癢, U+970C 霌, and U+9714 霔, uni6424-KR, uni7662-KR, uni970C-KR, and uni9714-KR, respectively, per Issue #61.
• Add a CN glyph for U+69F1 槱, uni69F1-CN.
• Add a KR glyph for UTC-00791, u00791-KR.
• Add a full-width glyph for U+00B7 ·, uni00B7-FW, that is a clone of uni30FB, and that interacts with the 'locl' GSUB feature.
• Add a TW glyph for U+674E 李, uni674E-TW.

Version 2.000 Additions:

• Add HK supported in terms of both characters and additional HK glyphs per Issue #4.
• Add KR glyphs per Noto CJK Issue 80 (a glyph for U+284DC 𨓜 is not necessary, because it will be mapped to uni9038-JP).
• Add glyphs for <U+30D0,U+30FC,U+30C4> バーツ, uni30D0uni30FCuni30C4 (Adobe-Japan1-6 CID+11914) and uni30D0uni30FCuni30C4-V (Adobe-Japan1-6 CID+11998), respectively, which will be made accessible via the 'dlig' and 'vert' GSUB features, respectively.

A version of Source Han Serif using the traditional orthography would be great.

Currently, the orthography of the Korean region is the most conservative and fits into the traditional orthography commonly seen in books printed in Hong Kong and Taiwan today and also in China before the 1970s. However, the number of characters in the Korean version are severely limited that it is not usable for daily typesetting for Traditional Chinese users who wish to use traditional orthography.

Traditional-orthgraphy is also preferred for specific Japanese use, notably in place names and personal names. Tradtional-orthography stands as the lowest common denominator for truly pan-CJK use.

A large amount of glyphs needed could be repurposed from the Korean or Japanese version.

Since Adobe has the original tools to programmatically generate outlines from strokes, it is much easier for Adobe to maintain such a version than for the community to maintain a fork using the munged outlines. A traditional-orthography based font could serve useful purposes for standardization in Unicode Code Charts as the lowest common denominator too.

I have discovered some CID glyphs are not present in any Region-specific Subset OTFs but show up when using JP/KR's language-specific OTFs. They also show up using CN/TW's language-specific OTFs when the language is set back to JP/KR.

An excerpt of CIDs are here:
2444
2483
2488
2492
15087
26366
26471
27595
45811

The involved CID glyphs I have found so far satisfy all of the following criteria:

• does not appear in any Region-specific subset OTFs
• used by default by the JP Language-specific Subset OTFs
• used by default by the KR Language-specific Subset OTFs
• not used by default by the CN Language-specific Subset OTFs
• not used by default by the TW Language-specific Subset OTFs

Any CIDs that are shared across the CN/TW & JP/KR boundary do not exhibit this issue.

U+6641: There is no practical difference between the two different forms by the CN and JP glyph.

Legend: CN, TW, JP, KR, CN/JP overlaid

First of all, congratulations and thanks for the great product.

The current release of Source Han Serif doesn't include most of the codepoints covered by HKSCS that included in Unicode as CJK Extension B or later. Looks to me that roughly about 1,700 codepoints have been excluded.

I have read the Adobe CJK Blog article. While I fully understand the rationale behind this move, this unfortunately renders the current revision of Source Han Serif not very usable for Hong Kong people, as a number of those Ext-B HKSCS characters are frequently used in our region and are missing.

As I am unable to predict how long we need to wait for the new version of HKSCS and the HK variant of Source Han Sans and Serif to be released, I would like to suggest to include some more HKSCS characters to the current Traditional Chinese variant as an interim solution, so that it can be more usable to Hong Kong users. Of course, this is not needed if the release date is not far off.

I am going to suggest 61 characters to be added. They are further divided into 3 levels base on their frequency of use.

Level 1: 35 characters. Frequently used, lacking those will certainly impact daily experience.

Level 2: 11 characters. Usually seen, so suggest to include.

Level 3: 15 characters. Even less frequently used, although still occasionally seen. May bring minor inconvenience when ignored.

The problem of this list is that it is crafted in an hour base on my personal experience, so they cannot be considered fully scientific (The H-source in IICORE still lacks some frequently used characters so cannot be fully relied upon). That said, I am quite confident that Level 1 characters are badly needed for Hongkongers.

Thank you for considering my request.

Level 1

Level 2

These 11 characters are sometimes used.

Level 3

These 15 characters are even less frequently used, although still occasionally seen.

#: Also in IICORE when "H" source.
*: HK glyph different from TW as per standard.

I've noticed that fontconfig does not seem to be able to handle Super OTC's Source Han Serif Regular and Source Han Serif Bold.

$ fc-list "Source Han Serif"
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif:style=Regular
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif,Source Han Serif SemiBold,源ノ明朝 SemiBold:style=SemiBold,Regular
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif,Source Han Serif Light,源ノ明朝 Light:style=Light,Regular
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif,Source Han Serif ExtraLight,源ノ明朝 ExtraLight:style=ExtraLight,Regular
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif,Source Han Serif Heavy,源ノ明朝 Heavy:style=Heavy,Regular
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif:style=Bold
/home/trueroad/.local/share/fonts/SourceHanSerif/SourceHanSerif.ttc: 源ノ明朝,Source Han Serif,Source Han Serif Medium,源ノ明朝 Medium:style=Medium,Regular

For Source Han Sans Super OTC, it is no problem.

$ fc-list "Source Han Sans"
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans Bold,源ノ角ゴシック Bold:style=Bold,Regular
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans Light,源ノ角ゴシック Light:style=Light,Regular
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans Normal,源ノ角ゴシック Normal:style=Normal,Regular
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans Regular,源ノ角ゴシック Regular:style=Regular
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans Medium,源ノ角ゴシック Medium:style=Medium,Regular
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans ExtraLight,源ノ角ゴシック ExtraLight:style=ExtraLight,Regular
/home/trueroad/.local/share/fonts/SourceHanSans/SourceHanSans.ttc: 源ノ角ゴシック,Source Han Sans,Source Han Sans Heavy,源ノ角ゴシック Heavy:style=Heavy,Regular

If I understand correctly, the cause is that some names are inconsistent.
The names of Regular and Bold do not contain its weight name, others contain its weight name.

For Source Han Sans Super OTC, the names seem to be consistent.

Here is the inconsistent names I found.

• Index 0: SourceHanSerif-ExtraLight

  • Font Family name: Source Han Serif ExtraLight, 源ノ明朝 ExtraLight
  • Full font name: Source Han Serif ExtraLight, 源ノ明朝 ExtraLight
    • Both Font Family name and Full font name contain its weight name.
      It is no problem.

• Index 4: SourceHanSerif-Light

  • Font Family name: Source Han Serif Light, 源ノ明朝 Light
  • Full font name: Source Han Serif Light, 源ノ明朝 Light
    • Both Font Family name and Full font name contain its weight name.
      It is no problem.

• Index 8: SourceHanSerif-Regular

  • Font Family name: Source Han Serif, 源ノ明朝
  • Full font name: Source Han Serif, 源ノ明朝
    • Both Font Family name and Full font name do not contain its weight name.
      So fontconfig cannot select it.

• Index 12: SourceHanSerif-Medium

  • Font Family name: Source Han Serif Medium, 源ノ明朝 Medium
  • Full font name: Source Han Serif Medium, 源ノ明朝 Medium
    • Both Font Family name and Full font name contain its weight name.
      It is no problem.

• Index 16: SourceHanSerif-SemiBold

  • Font Family name: Source Han Serif SemiBold, 源ノ明朝 SemiBold
  • Full font name: Source Han Serif SemiBold, 源ノ明朝 SemiBold
    • Both Font Family name and Full font name contain its weight name.
      It is no problem.

• Index 20: SourceHanSerif-Bold

  • Font Family name: Source Han Serif, 源ノ明朝
  • Full font name: Source Han Serif Bold, 源ノ明朝 Bold
    • Font Family name does not contain its weight name.
      So fontconfig cannot select it.

• Index 24: SourceHanSerif-Heavy

  • Font Family name: Source Han Serif Heavy, 源ノ明朝 Heavy
  • Full font name: Source Han Serif Heavy, 源ノ明朝 Heavy
    • Both Font Family name and Full font name contain its weight name.
      It is no problem.

Names of different weight of Source Han Serif TW are not consistent. When I install them in Mac, most of them go under the font family "Source Han Serif TW", while "Regular" and "Bold" go under the font family "思源宋體 TW". Hence, the latter two weights are in a different font family than other weights.
Moreover, it should be called "思源明體 TW" instead.

I use Libreoffice and source-han-serif-heavy TC Export PDF will Error
http://i.imgur.com/EGTRqBf.png
then use Libreoffice and source-han-serif TC Export PDF then can be fine
example: http://i.imgur.com/yhfW61E.png
but use Libreoffice and source-han-serif TW Export PDF will OK
can you check source-han-serif TC Building?

compare to Source Han Sans
the character 关 has larger width on Source Han Sans K to Source Han Sans
while, it has wrong width for Serif K comparing to Serif.

The Source Han Serif fonts are really easy to use.
I appreciate this project.
At the same time, I wanted to know about the character form principle of Source Hans Serif #TC.
While using the fonts, I noticed that the Traditional Chinese characters seem different from the Source Han Sans fonts.
For example, the left “radical” in 迌 (U+8FCC) is different between Sans and Serif.
The same applies to逈(U+9008) and 迁 (U+8FC1).
I want to use these fonts to the full, so I will appreciated it very much if I could know the Glyph design principle.

Glyphs in Source Han Serif: (CN/TW/JP/KR)

Glyphs U+4EBD in Code Charts:

According to Unihan, the definition for U+4EBD is a kwukyel and the GK source is in agreement with that. Therefore, the KR glyph should be CID 9777 instead of CID 9776.

Meanwhile, CID 9776 should actually be a variant of U+4EBC instead of U+4EBD. That variant is encoded in Extension B as U+204DB:

The yellow circle shows the intersection part is too small or too thin.

This issue is meant for tracking and submitting suggestions for glyph sharing changes that result in glyphs no longer being necessary. Any such changes in Version 1.xxx will be implemented via mapping changes, and the unused glyphs will be targeted for removal as part of the Version 2.000 update. Issues that were submitted before this consolidation issue was opened are referenced by issue number.

• Remove the JP glyphs for U+35EB 㗫, U+618F 憏, U+6456 摖, U+66A9 暩, U+6C77 汷, and U+78DC 磜, uni35EB-JP, uni618F-JP, uni6456-JP, uni66A9-JP, uni6C77-JP, and uni78DC-JP, respectively, per Issue #27.
• Remove the CN glyphs for U+4F8D 侍, U+6641 晁, and U+6C35 氵, uni4F8D-CN, uni6641-CN, and uni6C35-CN, respectively, per Issue #28.
• Remove the TW glyph for U+504F 偏, uni504F-TW per Issue #28.
• Remove the JP glyph for U+4EBD 亽, uni4EBD-JP, per Issue #34.
• Remove the TW glyph for U+77A2 瞢, uni77A2-TW, per Issue #36.
• Remove the TW glyphs for U+76EC 盬 and U+8B04 謄, uni76EC-TW and uni8B04-TW, respectively, per Issue #39 (but first swap them with their CN glyphs, uni76EC-CN and uni8B04-CN, respectively; the latter requires adjustment).
• Remove the JP glyphs for U+72B3 犳 and U+7300 猀, uni72B3-JP and uni7300-JP, respectively, per Issue #59.
• Remove the JP glyphs for U+5125 儥, U+58B0 墰, U+6D2C 洬, and U+83C2 菂, and U+970C 霌, uni5125-JP, uni58B0-JP, uni6D2C-JP, uni83C2-JP, uni970C-JP, respectively, per Issue #61.
• Remove the KR glyph for U+4E7C 乼, uni4E7C-KR, per Issue #61.
• Remove the CN glyphs for U+62FF 拿, U+6301 持, U+6DE6 淦, U+6DFC 淼, U+6EB4 溴, U+732A 猪, and U+81EC 臬, uni62FF-CN, uni6301-CN, uni6DE6-CN, uni6DFC-CN, uni6EB4-CN, uni732A-CN, and uni81EC-CN, respectively.
• Remove the JP glyph for U+6EA3 溣, uni6EA3-JP.
• Remove the HK glyph for U+9FD2 鿒, uni9FD2-HK.
• Remove the KR glyph for U+7199 熙, uni7199-KR.
• Remove the KR glyph for U+52FB 勻, uni52FB-KR.
• Remove the KR glyph for U+7A3D 稽, uni7A3D-KR.

Note To Self: I have not yet checked this report and after.

The fallback glyph for U+6902 (椂) on TW is currently CID 21954 which follows the CN conventions instead of the TW conventions.

A better fallback glyph already exists as 21953, which is more suitable for TW than 21954.

A. 彳 (U+5F73)

彳 (U+5F73) is a word, so its glyph is supposed to be centre-aligned instead of offseted to the left. The same happens to Source Han Sans and had been reported before.

B. 民 (U+6C11, TW & CN)

The overall position of 民 (U+6C11) in TW/CN stays the same as JP/KR despite the stroke difference. This causes the glyph look unbalaned. Again, this had also been reported before in the Source Han Sans issue tracker.

C. 魘 (U+9B58, JP & KR)

There is an issue with the interpolation of 魘 (U+9B58) for JP and KR.

For some reason, when specifying zh-TW and Source Han Serif (the Japanese language-specific version), 27527 is not substituted with 27526. However, when the language is set to zh-HK, there is no problem.

The error does not occur in Source Han Serif TW (the Taiwanese regional-specific subset version).

Demo: https://codepen.io/anon/pen/Emjaxq

The current download readme and the download guide is still too much text and complicated in my opinion.

I would suggest reworking the download page to be more user-friendly.
In particular:

1. Since Super OTC will eventually be the preferred format of Source Han
   (Sans or Serif) installations, at least on desktop system, I think it's best to
   put them as the first one on the page.

2. It's good to also mention the OS requirements just above the links on the
   readme, since it plays a big role on choosing which format to download.
   (TODO: mention also Linux/Unix requirements. Since there are so many
   distributions out there, it's better to mention the FreeType and fontconfig
   versions instead.)

3. OTCs should be packed as one ZIP file per weight, instead of multiple
   weights together. Reason: Users who would download these are probably people
   who only need specific weights. And the ZIP files aren't solid compression, so
   there's little size saving when they were packed together. Packing them as
   individual weights would help user same bandwidth if he needs, for example,
   only Regular and Bold.

Below is the download readme page I would propose:

## Downloading Source Han (Sans or Serif)

### Super OTC

Download this if you want all languages and all weights.

This format requires OS X 10.8 (Mountain Lion) or later, iOS 7 or later, or
Windows 10 Version 1703 (Creators Update) or later.

[Super OTC part 1] + [Super OTC Part 2]

The ZIP file for the Super OTC has been necessarily split into two parts, due
to GitHub's 100MB file size limit. Unfortunately, the built-in
_Archive Utility_ app of macOS doesn't support split ZIP files, and we
therefore recommend that you download and installed the
[Unarchiver](http://unarchiver.c3.cx/unarchiver) app. To unzip, either drag the
Part 2 file (the one with ".zip" extension) onto the _Unarchiver_ app,
or use Control-Click to open it by specifying that app (after installing the
_Unarchiver_ app, you may also be able to simply double-click the Part 2 file).
Either of these actions will combine the two parts and unzip them. For Windows,
select the Part 2 file, then use the "Extract All" context menu to combine the
two parts and unzip them.

### OTCs

Download this if you want all languages but only specific weights.

This format requires OS X 10.8 (Mountain Lion) or later, iOS 7 or later, or
Windows 10 Version 1607 (Anniversary Update) or later.

[Extra Light], [Light], [Regular], [Medium], [SemiBold], [Bold], [Heavy]

### Language-specific OTFs

Download this if you prefer only one language in your deployment, but wish to
have Pan-CJK support of the characters. (Or when the aforementioned OTC format
doesn't work with your operating system.)

Glyphs of other regional variants may be accessed by labeling the text with a
language. Your software needs to support OpenType 'locl' (Localized Forms) GSUB
feature. For example, in Adobe InDesign, you may use Language menu in the
Character panel to tag languages.

Font names containing the "HW" letters are variants that use half-width Latin
and digits by default.

If you only need specific weights, download individual files from
[the OTF directory](OTF).

Simplified Chinese:
[ExtraLight + Light + Regular + Medium] & [SemiBold + Bold + Heavy] & [HW Regular + HW Bold]

Traditional Chinese:
[ExtraLight + Light + Regular + Medium] & [SemiBold + Bold + Heavy] & [HW Regular + HW Bold]

Japanese:
[ExtraLight + Light + Regular + Medium] & [SemiBold + Bold + Heavy] & [HW Regular + HW Bold]

Korean:
[ExtraLight + Light + Regular + Medium] & [SemiBold + Bold + Heavy] & [HW Regular + HW Bold]

### Region-specific Subset OTFs

Download this if you need only characters of a particular language or region,
or you need to use regional variants on software that doesn't support
language-tagging or 'locl' GSUB feature. **Choose this if you're not sure
which format you should choose.**

The ZIP files contains all weights. If you only need specific weights, download
individual files from [the SubsetOTF directory](SubsetOTF).

[China], [Taiwan], [Hong Kong], [Japan], [Korea]

In the separate CN glyphs produced by Sinotype, the 日 component is nearly consistently too long in the Light weight.

Below are examples of characters where the CN glyph (red) is overlaid with the JP glyph (white). Some of them have different glyphs for CN and some of them share the same glyph between CN and JP. When the glyphs are not shared, CN's 日 is usually too long.

This leads to all other weights except Black being affected. The difference may seen subtle when characters are isolated but affects the rhythm of reading and causes whole blocks of text to look unbalanced.

https://github.com/adobe-fonts/source-han-serif/tree/release

[Super OTC Part 1](https://github.com/adobe-fonts/source-han-serif/raw/release/SuperOTC/SourceHanSerif.ttc.z01) + [Super OTC Part 2](https://github.com/adobe-fonts/source-han-serif/raw/release/SuperOTC/SourceHanSerif.ttc.zip)

Information for package libreoffice:
------------------------------------
Repository     : openSUSE-20170403-0            
Name           : libreoffice                    
Version        : 5.3.1.2-1.3                    
Arch           : x86_64                         
Vendor         : openSUSE                       
Installed Size : 269.0 MiB                      
Installed      : Yes                            
Status         : up-to-date                     
Source package : libreoffice-5.3.1.2-1.3.src    

The version of Source Han Serif I'm currently installing is "language-specific OTF".
I can confirm the problem on both OTF and SuperOTC versions.

This problem is also observed on Windows, where Mojibake is shown instead.

I'm not sure it is totally LibreOffice's fault. I'll cross-post after confirmed.

Four characters were found in Source Han Serif SC that have different design with Source Han Sans SC.
They are 䙛(U+465B),⻞(U+2EDE),㨗(U+3A17),渉(U+6E09).

Yesieung (ㆁ), not ieung (ㅇ). This includes .tjmo0[1-4] glyphs of those three hangul jamo characters as well.

As shown above, Noto Serif CJK SC doesn't contain some letters in Polish and Czech, those have been fallbacked to Calibri. Compare to Helvetica Neue at the top lines.

The TW glyph for U+4FB9 is in error. The second stroke of the top right hand component should be the shortest.

The Korean name of Source Han Serif, “본명조”, transcribed in Hanja is “本明朝”, which is identical to another Mincho typeface in Japan: “本明朝”.

See: http://www.morisawa.co.jp/fonts/specimen/1770

1. The nominal form of U+1178 ᅸ is wrong. U+1178 is ㅑ + ㅗ, not ㅑ + ㅛ (ㅑ + ㅛ is U+1179 ᅹ).
2. The nominal form and the vjmo01 glyph of U+D7B5 ힵ are wrong. U+D7B5 is ㅜ + ㅕ, not ㅗ + ㅕ (ㅗ +ㅕ is U+D7B0 ힰ).

Nuked.

Take a look at the reference font provided by Taiwan MOE website, U+58F3 is 士冖一几,
while U+58F3 in 思源宋體 is 土冖几.

There is a glyph already created in the OTF file,
just next to the glyph that the font currently using.

This issue is for me to convey information about a forthcoming release, and is mainly to state that there has been a cutoff with regard to addressing new issues. As a result, this issue has been locked so that comments are not possible.

Version 1.001 Release: While I cannot reveal the actual release date, the cut-off date for incorporating changes based on new issues was effective 2017-04-22. The first post in Issues #36, #37, #39, and #40 have been updated to indicate what changes are expected to be made (Issue #38 is for explicitly specifying glyphs to be removed in Version 2.000).

Also, after the Version 1.001 release, I will use the Wiki to provide information about upcoming releases, and not this issue, which will be closed.

There is supposed to be a long horizontal stroke like in Chinese but it seems to share a glyph with the Japanese version. This issue is also present in Source Han Sans.

http://www.zdic.net/z/18/zy/5BE7.htm
http://hanja.naver.com/hanja?q=%E5%AF%A7

OpenType specification introduced font variation in 1.8, as Type is Beautiful, this technology has following advantages for CJK typefaces: it’s easy to adjust the gray scale, proportion, alignments with Western scripts, easy to implement multiple font weight and style within single font file, save unwhispered expenses for meticulous and global hinting and so on. If Source Han Serif adapt this technology, it would get better quality visual appearences.

This issue is meant for tracking and submitting suggestions for mapping changes, meaning that a character might be better mapped to a different but existing glyph. Note that mapping changes, especially for ideographs, will trigger changes to GSUB features, such as the language-specific lookups of the 'locl' GSUB feature. Because tools are used to build the language-specific lookups of the 'locl' GSUB feature by using the CMap resources, such suggestions cannot be accepted as pull requests, and should instead be posted here. Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following changes were made in Version 1.001:

• Mapped U+3164 HANGUL FILLER to uni1160.
• Mapped U+2D544 to uni2E8D-JP.
• Mapped U+2EC1 ⻁, U+2EEA ⻪, and U+2F2C ⼬ to uni864EuE0101-JP, uni9EFE-CN, and uni5C6E-CN, respectively.
• Mapped U+2F22 ⼢ and U+2F58 ⽘ to uni590A-CN and uni723B-CN, respectively, in the CN CMap resource.
• Mapped U+5173 关 to uni5173-CN in the KR CMap resource per Issue #5.
• Mapped U+5553 啓 and U+555F 啟 to uni5553uE0101-JP and uni555F-JP, respectively, in the TW CMap resource per Issue #13.
• Mapped U+5BE7 寧 to uni5BE7uE0100-JP in the KR CMap resource per Issue #20.
• Mapped U+58F3 壳 to uni58F3-JP in the TW CMap resource per Issue #26.
• Mapped U+58FE 壾 and U+591A 多 to uni58FE-JP and uni591A-JP, respectively, in the TW CMap resource per Issue #27.
• Mapped U+4F8D 侍, U+6641 晁, and U+6C35 氵 to uni4F8D-JP, uni6641-JP, and uni6C35-JP, respectively, in the CN CMap resource per Issue #28.
• Mapped U+6902 椂, U+6903 椃, U+6947 楇, U+7171 煱, and U+9BF1 鯱 to uni6902-JP, uni6903-JP, uni6947-JP, uni7171-JP, and uni9BF1-JP, respectively, in the TW CMap resource per Issue #32.
• Mapped U+4EBD 亽 to uni4EBD-CN in the JP—and by extension KR—CMap resource per Issue #34.
• Mapped U+627F 承 and U+77A2 瞢 to uni627F-JP and uni77A2uE0101-JP, respectively, in the TW CMap resource per Issue #36.
• Mapped U+62FF 拿, U+6301 持, U+6DE6 淦, U+6DFC 淼, U+6EB4 溴, and U+81EC 臬 to uni62FF-JP, uni6301-JP, uni6DE6-JP, uni6DFC-JP, uni6EB4-JP, and uni81EC-JP, respectively, in the CN CMap resource per Issue #38.
• Mapped U+504F 偏 to uni504FuE0101-JP in the TW CMap resource per Issue #38.
• Mapped U+76EC 盬 and U+8B04 謄 to uni76EC-CN and uni8B04-CN, respectively, in the TW CMap resource per Issue #39.
• Mapped U+2F61 ⽡ to uni74E6-JP in the TW CMap resource per Issue #43.
• Mapped U+61DC 懜, U+77D2 矒, U+8019 耙, and U+803B 耻 to uni61DC-JP, uni77D2-JP, uni8019-JP, and uni803B-JP, respectively, in the TW CMap resource.
• Mapped U+2FCC ⿌ to uni9EFD-JP in the TW CMap resource.

Post Version 1.001 Mapping Changes:

• Map U+732A 猪 to uni732A-JP in the CN CMap resource per Issue #38.
• Map U+5009 倉 to uni5009-JP in the TW CMap resource per Issue #53.
• Map U+2EDE ⻞ to u2967F-CN in the CN CMap resource per Issue #55.
• Map U+7300 猀 to uni7300-CN in the JP and KR CMap resources per Issue #59.
• Map U+526A 剪, U+5881 墁, U+688F 梏, U+6ADD 櫝, U+6C4B 汋, U+7006 瀆, U+70B7 炷, U+7258 牘, U+72A2 犢, U+72B3 犳, and U+7431 琱 to uni526A-CN, uni5881-CN, uni688F-CN, uni6ADD-CN, uni6C4B-CN, uni7006-CN, uni70B7-CN, uni7258-CN, uni72A2-CN, uni72B3-CN, and uni7431-CN, respectively, in the KR CMap resource per Issue #59.
• Map U+501C 倜, U+5192 冒, U+52C7 勇, U+553E 唾, U+5DFD 巽, U+641C 搜, U+73F9 珹, U+7A20 稠, U+7C3F 簿, U+8983 覃, and U+8D16 贖 to uni501C-CN, uni5192-CN, uni52C7-CN, uni553E-CN, uni5DFD-CN, uni641C-CN, uni73F9-CN, uni7A20-CN, uni7C3F-CN, uni8983-CN, and uni8D16-CN, respectively, in the KR CMap resource per Issue #60.
• Map U+4E7C 乼, U+5125 儥, U+58B0 墰, U+60C6 惆, U+6D2C 洬, U+6E54 湔, U+83C2 菂, U+83DF 菟, U+86C0 蛀, U+8729 蜩, U+8CD9 賙, U+90DC 郜, U+99B0 馰, U+9C4F 鱏, U+9D69 鵩, and U+9EF7 黷 to uni4E7C-CN, uni5125-CN, uni58B0-CN, uni60C6-CN, uni6D2C-CN, uni6E54-CN, uni83C2-CN, uni83DF-CN, uni86C0-CN, uni8729-CN, uni8CD9-CN, uni90DC-CN, uni99B0-CN, uni9C4F-CN, uni9D69-CN, and uni9EF7-CN, respectively, in the KR CMap resource per Issue #61.
• Map U+3B6D 㭭 and U+5225 別 to uni3B6D-JP and uni5225-JP, respectively, in the TW CMap resource.
• Map U+5A66 婦 and U+7199 熙 to uni5A66uE0101-JP and uni7199-JP, respectively, in the KR CMap resource.
• Map U+2F2C ⼬ to uniFA3C-JP in the JP (and, by extension, KR) CMap resource, and to uni5C6E-CN in the CN (and, by extension, TW) CMap resource.
• Map U+284DC 𨓜 to uni9038-JP in the JP (and by extension, all) CMap resource.
• Map U+8056 聖 and U+83BD 莽 to uni8056-TW and uni83BD-JP, respectively, in the KR CMap resource.
• Investigate the U+F92C 郎 issue that affects the 'locl' GSUB feature.

思源明體 k 和 cn，「气」裏面的部件應該寬而扁，像思源黑體 cn 那樣。

氰氳氫氯

Bopomofo letter V, NG and GN don't have the same designs as others.

The longer left-falling stroke (撇) of 化 (U+5316) looks uncomfortable for users with Simplified Chinese background.

Problem with the crossing of the right component

The center seems too high.

And the extended part of the stroke is a bit too short.

The extended part from the cross is almost invisible in smaller font size. That makes the glyph looks strange and may confuse a user with Simplified Chinese background as a typo. It would probably result in low legibility of this common glyph. And I have to say that it should not be considered as a feature, but an error. Even for typefaces known for its wide counter (like FounderType Boya Song as shown above), the extended 撇 is much more visible.

In other glyphs

花 (U+82B1) meets the same problem, however 讹 (U+8BB9) and 华 (U+534E) look fine, causing inconformity of the component.

There is an extra scrollbar in banner when browser width is around 500px ~ 768px

https://source.typekit.com/source-han-serif/

Workaround 1:
remove padding-bottom: 0 for .banner, or set a other value of scrollbar width

Workaround 2:
use flexbox & flex-wrap for .banner layout. ;)

This issue is meant for tracking and submitting suggestions for glyph corrections. Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following changes were made in Version 1.001:

• Fixed the glyphs uni11ED, uni11ED.tjmo01 through uni11ED.tjmo04 (4), uniD7F5, uniD7F5.tjmo01 through uniD7F5.tjmo04 (4), uniD7F6, and uniD7F6.tjmo01 through uniD7F6.tjmo04 (4) per Issue #6. Also to be fixed are the glyphs uni118C.vjmo01, uni1190.vjmo01, uni1192.vjmo01, and uni1112uni119Euni11D9 per Sandoll's designer.
• Fixed the CN glyphs for U+5F73 彳 and U+6C11 民, uni5F73-CN and uni6C11-CN, respectively, so that they are centered of more balanced within the em-box per Issue #11.
• Fixed the interpolation issue in the JP glyph for U+9B58 魘, uni9B58-JP (Adobe-Japan1-6 CID+7307), per Issue #11.
• Fixed the CN glyphs for U+5316 化 and U+82B1 花, uni5316uE0101-JP (Adobe-Japan1-6 CID+13665) and uni82B1uE0101-JP (Adobe-Japan1-6 CID+13666), respectively, per Issue #14.
• Fixed the glyphs uni1178, uniD7B5, and uniD7B5.vjmo01 per Issue #25.
• Fixed the glyphs uni1140uni1175uni11D9 and uni114Cuni116Funi11D9 per Issue #27. Also to be adjusted are the glyphs for U+C625 옥 and U+C73D 윽, uniC625 and uniC73D, respectively, per Sandoll's designer.
• Fixed the CN glyph for U+4FB9 侹, uni4FB9-CN, so that the second stroke of the top-right component is the shortest per Issue #27.
• Fixed the TW glyph for U+5FB5 徵, uni5FB5-TW, so that the 9th stroke is shorter than the 8th and 11th ones per Issue #27.
• Fixed the CN glyphs for U+4F5B 佛, U+602B 怫, U+62C2 拂, U+6C1F 氟, U+6CB8 沸, U+7829 砩, and U+7ECB 绋, uni4F5B-CN, uni602B-CN, uni62C2-CN, uni6C1F-CN, uni6CB8-CN, uni7829-CN, and uni7ECB-CN, respectively, so that the two common vertical strokes are of uniform weight per Issue #27.
• Fixed the JP glyph for U+3CDA 㳚, uni3CDA-JP, so that the dot touches the curved stroke to its left per Issue #27.
• Fixed the CN glyph for U+2CD9F 𬶟, u2CD9F-CN, so that the center element is a box per Issue #36.
• Fixed the TW glyph for U+5A6C 婬, uni5A6C-TW, so that the 9th stroke is shorter than the 8th and 11th ones.
• Fixed the JP glyph for U+8285 芅, uni8285-JP, to remove its final stroke.
• Fixed the TW glyph for U+83E1 菡, uni83E1-TW so that the four dots are not touching the vertical stroke.
• Fixed the CN glyphs for U+3E76 㹶, U+414D 䅍, U+4A60 䩠, U+4BD5 䯕, U+4C53 䱓, U+5A17 娗, U+5EAD 庭, U+5EF7 廷, U+633A 挺, U+6883 梃, U+6D8F 涏, U+70F6 烶, U+73FD 珽, U+7D8E 綎, U+8121 脡, U+8247 艇, U+8713 蜓, U+8A94 誔, U+92CC 鋌, U+94E4 铤, U+95AE 閮, and U+9F2E 鼮, uni3E76-CN, uni414D-CN, uni4A60-CN, uni4BD5-CN, uni4C53-CN, uni5A17-CN, uni5EAD-CN, uni5EF7-CN, uni633A-CN, uni6883-CN, uni6D8F-CN, uni70F6-CN, uni73FD-CN, uni7D8E-CN, uni8121-CN, uni8247-CN, uni8713-CN, uni8A94-CN, uni92CC-CN, uni94E4-CN, uni95AE-CN, and uni9F2E-CN, respectively, so that the center horizontal stroke of the upper-right portion of the common 廷 component is the longer of the three horizontal strokes.
• Fixed the JP glyph for U+7669 癩, uni7669-JP, by fixing the connection of the 13th and 14th strokes (SemiBold through Heavy).
• Fixed the TW glyph for U+750B 甋, uni750B-TW, by making its dot touch the stroke to its left.
• Fixed the TW glyph for U+7D73 絳, uni7D73-TW, by adjusting its ExtraLight master so that the diagonal stroke in the lower-right component does not penetrate the horizontal stroke to which it connects.

Post Version 1.001 Fixes:

• Fix the TW glyphs for U+64FB 擻, U+6578 數, U+7C54 籔, and U+85EA藪, uni64FB-TW, uni6578-TW, uni7C54-TW and uni85EA-TW, respectively, so that the third stroke of the Radical 38 component is horizontal, not diagonal, per Issue #36.
• Fix the TW glyph for U+9AD3 髓, uni9AD3-TW, so that the lower-right stroke doesn't extend outside the em-box per Issue #36.
• Fix the CN glyphs for 䙶 U+4676, 䜛 U+471B, and 䞅 U+4785, uni4676-CN, uni471B-CN, and uni4785-CN, respectively, per Issue #56.
• Fix the TW glyph for U+5DD5 巕, uni5DD5-TW, by changing its lower-right component from 子 (Radical 39) to 女 (Radical 38).
• Fix the CN glyph for U+8A7C 詼, uni8A7C-CN, by fixing the LE connection error in the lower-left component (Heavy master only).
• Adjust the glyph for U+20DE, uni20DE, by shifting it to the left of the origin (0,0), making it zero-width, and adding it to the 'vert' GPOS (not GSUB) feature. This is the same treatment as the glyph for U+20DD, uni20DD.
• Adjust the glyphs for U+2015 and U+FE31, uni2015 (Adobe-Japan1-6 CID+661) and uniFE31 (Adobe-Japan1-6 CID+7892), respectively, to match those of Source Han Sans in that they do not touch the edges of the em-box.
• Fix the LE issue in the lower-right component of the Heavy master of the JP glyph for U+5D1E 崞, uni5D1E-JP, which is outside the scope of Adobe-Japan1-6 and slated for removal in Version 2.000 to make room for HK glyphs.
• Adjust the glyph for U+4E3F 丿, uni4E3F-JP (Adobe-Japan1-6 CID+4097), by adjusting its stroke so that it better fills the em-box or is centered within the em-box, like it does in Kozuka Mincho and Source Han Sans.

@imbushuo reported that he is using SuperOTC smoothly on 15063. The "which file to use" part of the READMEs for Source Han Sans and Source Han Serif should be updated on the next release.

I generated some documents in XeLaTeX with the help of CTEX and xeCJK packages, under the latest version of macOS Sierra, and Super OTC version of Noto Serif CJK SC. Characters in documents looking correct, but in document properties of Adobe Acrobat Reader (Cmd+D), the embedded font appears as Noto Sans CJK JP.

I am not quite sure if that is a Super OTC issue, or Noto Serif CJK issue instead of Source Han Serif.

In spite of the new subroutinizer, Source Han Serif also has some unused subroutines. The same issue as adobe-fonts/source-han-sans#162.

$ ttx --version
3.9.2

$ ttx -t CFF -o cff.ttx SourceHanSerifJP-Regular.otf
Dumping "SourceHanSerifJP-Regular.otf" to "cff.ttx"...
Dumping 'CFF ' table...

$ grep -e FontName -e raw cff.ttx
          <FontName value="SourceHanSerifJP-Regular-Alphabetic"/>
          <FontName value="SourceHanSerifJP-Regular-AlphabeticDigits"/>
          <FontName value="SourceHanSerifJP-Regular-Bopomofo"/>
          <FontName value="SourceHanSerifJP-Regular-Dingbats"/>
              <CharString index="446" raw="1">
              <CharString index="589" raw="1">
          <FontName value="SourceHanSerifJP-Regular-DingbatsDigits"/>
          <FontName value="SourceHanSerifJP-Regular-Generic"/>
              <CharString index="95" raw="1">
          <FontName value="SourceHanSerifJP-Regular-HDingbats"/>
          <FontName value="SourceHanSerifJP-Regular-HHangul"/>
          <FontName value="SourceHanSerifJP-Regular-HKana"/>
          <FontName value="SourceHanSerifJP-Regular-HWidth"/>
          <FontName value="SourceHanSerifJP-Regular-HWidthCJK"/>
          <FontName value="SourceHanSerifJP-Regular-HWidthDigits"/>
          <FontName value="SourceHanSerifJP-Regular-Hangul"/>
              <CharString index="166" raw="1">
          <FontName value="SourceHanSerifJP-Regular-Ideographs"/>
              <CharString index="2909" raw="1">
              <CharString index="5982" raw="1">
              <CharString index="7105" raw="1">
              <CharString index="7456" raw="1">
              <CharString index="8238" raw="1">
              <CharString index="9527" raw="1">
              <CharString index="9568" raw="1">
              <CharString index="9640" raw="1">
              <CharString index="9814" raw="1">
              <CharString index="9876" raw="1">
              <CharString index="10332" raw="1">
              <CharString index="11191" raw="1">
              <CharString index="11266" raw="1">
              <CharString index="11318" raw="1">
              <CharString index="11328" raw="1">
              <CharString index="11373" raw="1">
              <CharString index="11517" raw="1">
              <CharString index="11573" raw="1">
              <CharString index="11709" raw="1">
              <CharString index="11752" raw="1">
              <CharString index="11762" raw="1">
              <CharString index="12120" raw="1">
              <CharString index="12296" raw="1">
              <CharString index="12474" raw="1">
              <CharString index="14534" raw="1">
              <CharString index="14632" raw="1">
              <CharString index="14728" raw="1">
              <CharString index="14743" raw="1">
              <CharString index="14746" raw="1">
              <CharString index="14788" raw="1">
              <CharString index="14805" raw="1">
              <CharString index="14817" raw="1">
              <CharString index="15003" raw="1">
              <CharString index="15145" raw="1">
              <CharString index="15158" raw="1">
              <CharString index="15206" raw="1">
              <CharString index="15300" raw="1">
              <CharString index="16084" raw="1">
              <CharString index="16086" raw="1">
              <CharString index="16915" raw="1">
              <CharString index="16993" raw="1">
              <CharString index="17004" raw="1">
              <CharString index="17016" raw="1">
              <CharString index="17039" raw="1">
              <CharString index="17141" raw="1">
              <CharString index="17167" raw="1">
              <CharString index="17286" raw="1">
              <CharString index="17335" raw="1">
              <CharString index="17372" raw="1">
              <CharString index="17392" raw="1">
              <CharString index="17675" raw="1">
              <CharString index="18153" raw="1">
              <CharString index="18155" raw="1">
              <CharString index="18189" raw="1">
              <CharString index="18190" raw="1">
              <CharString index="18191" raw="1">
              <CharString index="18379" raw="1">
              <CharString index="18468" raw="1">
              <CharString index="18526" raw="1">
              <CharString index="18527" raw="1">
              <CharString index="18551" raw="1">
              <CharString index="18559" raw="1">
              <CharString index="18567" raw="1">
              <CharString index="18568" raw="1">
              <CharString index="18575" raw="1">
              <CharString index="18579" raw="1">
              <CharString index="18666" raw="1">
              <CharString index="18710" raw="1">
              <CharString index="18738" raw="1">
              <CharString index="18757" raw="1">
              <CharString index="18773" raw="1">
              <CharString index="18779" raw="1">
              <CharString index="18784" raw="1">
              <CharString index="18809" raw="1">
              <CharString index="18810" raw="1">
              <CharString index="18856" raw="1">
              <CharString index="18865" raw="1">
              <CharString index="19080" raw="1">
              <CharString index="19101" raw="1">
              <CharString index="19118" raw="1">
              <CharString index="19120" raw="1">
              <CharString index="19125" raw="1">
              <CharString index="19134" raw="1">
              <CharString index="19147" raw="1">
              <CharString index="19162" raw="1">
              <CharString index="19167" raw="1">
              <CharString index="19206" raw="1">
              <CharString index="19214" raw="1">
              <CharString index="19769" raw="1">
              <CharString index="19774" raw="1">
              <CharString index="19839" raw="1">
              <CharString index="19916" raw="1">
              <CharString index="20107" raw="1">
              <CharString index="20399" raw="1">
              <CharString index="20457" raw="1">
              <CharString index="20663" raw="1">
              <CharString index="20687" raw="1">
              <CharString index="20757" raw="1">
              <CharString index="20925" raw="1">
              <CharString index="20978" raw="1">
          <FontName value="SourceHanSerifJP-Regular-Kana"/>
          <FontName value="SourceHanSerifJP-Regular-Proportional"/>
          <FontName value="SourceHanSerifJP-Regular-ProportionalCJK"/>
          <FontName value="SourceHanSerifJP-Regular-ProportionalDigits"/>
          <FontName value="SourceHanSerifJP-Regular-VKana"/>

Three characters were found in Source Han Serif TC that have different mapping with Source Han Sans TC.
They are倉(U+5009), 釉(U+91C9) and 隉(U+9689).

It would be useful if they were mapped as the following, as they are in their equivalent San-serif fonts.
倉(U+5009) → cid10273
釉(U+91C9) → cid42210
隉(U+9689) → cid44061

This issue is meant for tracking and submitting suggestions for redesigning glyphs, meaning that the glyphs are technically correct in structure, but could benefit from adjustment in order to become more usable for more languages or regions, or simply for aesthetic reasons (see the note below).

Please do not use this issue to nitpick the typeface design. Keep in mind that there are 64K glyphs in this typeface, which provides a live's worth of nitpicking.

Issues that were submitted before this consolidation issue was opened are referenced by issue number.

The following changes were made in Version 1.001:

• Adjusted the final stroke of the JP glyph for U+6C2B 氫, uni6C2B-JP, to be better balanced.
• Adjusted the right-most vertical stroke of the JP glyph for U+595C 奜, uni595C-JP.
• Adjusted the JP glyphs for U+3D93 㶓 and U+81F7 臷, uni3D93-JP and uni81F7-JP.
• Adjusted the JP glyphs for U+507D 偽 and U+70BA 為, uni507D-JP and uni70BA-JP, respectively, to be better balanced, and adjust the CN glyph for U+6E88 溈, uni6E88-CN, in the same way.
• Adjusted the TW glyphs for U+511A 儚, U+5922 夢, U+61F5 懵, U+750D 甍, U+858E 薎, U+85A8 薨, U+8609 蘉, and U+9138 鄸, uni511A-TW, uni5922-TW, uni61F5-TW, uni750D-TW, uni858E-TW, uni85A8-TW, uni8609-TW, and uni9138-TW, respectively so that their common Radical #140 component is more proportionate.
• Adjusted the TW glyph for U+7AC5 竅, uni7AC5-TW, so that the top and lower-left components are less wide.
• Adjusted the CN glyphs for U+596E 奮 and U+5957 套, uni596E-CN and uni5957-CN, respectively, so that at least the two middle horizontal strokes are the same length, though the top one may need to remain short.
• Adjusted the TW glyph for U+FF0C ，, uniFF0C-TW, by making its shape the same as the JP glyph, uniFF0C.
• Adjusted the CN glyph for U+FF1B ；, uniFF1B-CN, by making its comma component the same as that of the JP glyph, uniFF1B.

Post Version 1.001:

• Consider redesigning the glyphs for bopomofo per Issue #17
• Consider redesigning the TW glyphs that contain 辶 as a component per Issue #15.
• Consider adjusting CN glyphs for design consistency per Issue #29.
• Redesign the glyph for U+3025 〥, uni3025, to better match the glyphs for related characters, such as bopomofo.
• The counters of many CN and TW glyphs for ideographs are too wide.
• Adjust the 寺 component of the CN glyph for U+5D75 嵵, uni5D75-CN, so that its two parts do not connect.
• Adjust the TW glyph for U+FF0C ，, uniFF0C-TW, by shifting it slightly downward.
• Adjust the JP glyph for U+7B01 笁, uni7B01-JP, to have better balance and proportions between the top and bottom components.
• Adjust the TW glyph for U+85AA 薪, uni85AA-TW, so that the lower-right component is taller.
• Adjust the glyphs for U+3191 ㆑ through U+319F ㆟, uni3191 through uni319F, to be generic in terms of weight (see Noto CJK Issue #159)

There are Source Han Serif K for Korean, Soure Han Serif SC for Simplified Chinese, Sourcce Han Serif TC for Traditional Chinese,
but why Japanese version called Source Han Serif, not Source Han Serif J?