It seems to me that cjk-gs-integrate can't add an arbitrary CJK font file. The font must be somewhere registered in its database, right? If this observation is correct, it should be explicitly mentioned in the script's --help output. If the observation is incorrect, it should also be mentioned how to add a single font.

I add some thing in cjkgs-founder.dat:

Name: 楷体_GB2312
Class: GB
TTFname: KaiTi_GB2312.ttf

Name: 方正黑体_GBK
Class: GB
TTFname:  FZHTK.TTF

Name: 方正细等线简体
Class: GB
TTFname:  FZXDXJW.TTF

use command perl cjk-gs-integrate.pl to generate cidfmap.local, it's show:

/方正细等线简体 << /FileType /TrueType
  /Path pssystemparams /GenericResourceDir get
  (CIDFSubst/FZXDXJW.TTF) concatstrings
  /CSI [(GB1) 5] >> ;

/方正黑体_GBK << /FileType /TrueType
  /Path pssystemparams /GenericResourceDir get
  (CIDFSubst/FZHTK.TTF) concatstrings
  /CSI [(GB1) 5] >> ;

/楷体_GB2312 << /FileType /TrueType
  /Path pssystemparams /GenericResourceDir get
  (CIDFSubst/KaiTi_GB2312.ttf) concatstrings
  /CSI [(GB1) 5] >> ;

use commandgs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dPDFSTOPONERROR -dNOOUTERSAVE -dCompressFonts=true -dSubsetFonts=false -dEmbedAllFonts=true -sColorConversionStrategy=RGB -dCompatibilityLevel=1.6 -sOutputFile=output.pdf 1000027661706311.pdf to convert pdf ,its error:

GPL Ghostscript 9.50 (2019-10-15)
Copyright (C) 2019 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
While reading gs_cidfm.ps:
Error: /syntaxerror in (binary token, type=150)
Operand stack:
(gs_cmap.ps\000gs_setpd.ps\000gs_fapi.ps\000gs_typ32.ps\000gs_frsd.ps\000gs_ll3.ps\000gs_icc.ps\000gs_mex_e.ps\000gs_mro_e.ps\000gs_pdf_e.ps\000gs_wan_e.ps\000pdf_ops.ps\000pdf_rbld.ps\000pdf_base.ps\000pdf_draw.ps\000gs_cff.ps\000gs_mgl_e.ps\000gs_ttf...)   (gs_cidfm.ps)   1   --nostringval--   FZBSJW--GB1-0   --dict:3/3(G)--   FZDBSJW--GB1-0   --dict:3/3(G)--   FZHTJW--GB1-0   --dict:3/3(G)--   FZHTK--GBK1-0   --dict:3/3(G)--   FZSSK--GBK1-0   --dict:3/3(G)--   FZXBSK--GBK1-0   --dict:3/3(G)--   FangSong   --dict:3/3(G)--   KaiTi   --dict:3/3(G)--   KaiTi_GB2312   --dict:3/3(G)--   MicrosoftYaHei   --dict:4/4(G)--   MicrosoftYaHei-Bold   --dict:4/4(G)--   MicrosoftYaHeiLight   --dict:4/4(G)--   NSimSun   --dict:4/4(G)--   SimHei   --dict:3/3(G)--   SimSun   --dict:4/4(G)--   WenQuanYiZenHei   --dict:4/4(G)--   WenQuanYiZenHei-Adobe-CNS1   --dict:4/4(G)--   WenQuanYiZenHeiMono   --dict:4/4(G)--   WenQuanYiZenHeiMono-Adobe-CNS1   --dict:4/4(G)--   WenQuanYiZenHeiSharp   --dict:4/4(G)--   WenQuanYiZenHeiSharp-Adobe-CNS1   --dict:4/4(G)--   YouYuan   --dict:4/4(G)--   
Execution stack:
   %interp_exit   --nostringval--   --nostringval--   %loop_continue   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   --nostringval--   --nostringval--   --nostringval--   1817   5   6   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push
Dictionary stack:
   --dict:918/1123(G)--   --dict:0/20(G)--   --dict:71/200(L)--   --dict:918/1123(G)--   --dict:9/14(G)--   --dict:1/1(G)--
Current allocation mode is global
Current file position is 2184

I guess ghostscript don't support Chinese ,and files all are ascii text. but I read your blog ：

Name: HiraKakuPro-W3
Class: Japan
Provides(40): GothicBBB-Medium
Provides(40): A-OTF-GothicBBBPro-Medium
Filename(20): ヒラギノ角ゴ Pro W3.otf
Filename(10): HiraKakuPro-W3.otf

some 漢字 とかたかな in config file ?

こんばんは，夜分に失礼致します。TeX Liveを再Installしましたところ，Hiraginoを使えなくなってしまいました。さっそく@doraTeXに相談しましたところ，

• cjk-gs-integrateがまだMojaveに対応しておらず，Mojave用のフォントデータベースが存在しない
• cjk-gs-integrateのMojave対応を待つしかない

と教えて下さいました。ただ，Releaseされる秋までHiraginoを使えないというのは，身勝手ながら耐えることができません。

この間，newpxtext.styが二重拡張子で使えなくなっていたときには，@norbusanに迅速に対応して頂いて助かったことがありましたので，Issuesにて助けを求めることに致しました。

Japanese TeX Development Communityの皆様，どうぞよろしくお願い致します。

Thank you very much for making us be easier to emigrate to El Capitan.
With your help, I am using TeXLive (including Japanese) on El Capitan as before.
Below, I report a problem about cjk-gs-integrate.pl which I met.

"gs --help" can output the following result:
...
Search path:
/sw/share/ghostscript/9.16/Resource/Init :
/sw/share/ghostscript/9.16/lib :
/sw/share/ghostscript/9.16/Resource/Font : /sw/share/ghostscript/fonts :
...

So, please modify cjk-gs-integrate.pl as follows (or in some improved way):
--- cjk-gs-integrate.pl.org 2015-10-03 07:13:29.000000000 +0900
+++ cjk-gs-integrate.pl 2015-10-10 16:20:48.000000000 +0900
@@ -982,9 +982,7 @@
for (@ret) {
if (m!Resource/Font!) {
$foundres = $_;

•    $foundres =~ s/^\s*//;
  

•    $foundres =~ s/\s_:\s_$//;
  

•    $foundres =~ s!/Font!!;
  

•    $foundres =~ s!^._\s(\S_Resource)/Font._\n_$!$1!;
   last;
  

  }
  }

Thank you very much in advance.

SourceHanSerif-Light-UniJIS-UTF8-H
SourceHanSans-Medium-UniJIS-UTF8-H
などのように AI0 フォントに AJ1 用の CMap を繋げた snippet が生成されるようですが、これらはまともに動作せず、盛大な文字化けを引き起こします。以下の PostScript ファイル

/HaranoAjiMincho-Light-UniJIS-UTF8-H findfont 12 scalefont setfont
100 500 moveto
(HaranoAjiMincho-Light 日本語いろはにほへと) show
/HaranoAjiGothic-Medium-UniJIS-UTF8-H findfont 12 scalefont setfont
100 480 moveto
(HaranoAjiGothic-Medium 日本語いろはにほへと) show
/SourceHanSerif-Light-UniJIS-UTF8-H findfont 12 scalefont setfont
100 460 moveto
(SourceHanSerif-Light 日本語いろはにほへと) show
/SourceHanSans-Medium-UniJIS-UTF8-H findfont 12 scalefont setfont
100 440 moveto
(SourceHanSans-Medium 日本語いろはにほへと) show

を Ghostscript で PDF に変換すると、源ノフォントでは「日本語いろはにほへと」の部分が文字化けします。アルファベットの部分は文字化けしませんでしたが、たまたま同じ CID が同じ文字に割り当たっていただけで、化けても不思議ではないものと思います。
test-sourcehan.pdf

Current cjk-gs-integrate.pl doesn't distinguish uppercase/lowercase file names.

I think kpathsea on Unix-like environment cares about uppercase/lowercase. On MacOSX:

$ kpsewhich batang.ttf
/usr/local/texlive/2016dev/texmf-dist/fonts/truetype/public/baekmuk/batang.ttf

$ kpsewhich Batang.ttf
/Library/Fonts/Microsoft/Batang.ttf

However, cjk-gs-integrate.pl doesn't distinguish these two.

Some test cases on MacOSX with MSOffice. Consider following example;

Prepare "database.txt" as follows:

# baekmuk package (free)
Name: Baekmuk-Batang
Class: Korea
Provides(41): HYSMyeongJo-Medium
Filename(20): batang.ttf
Filename(10): Baekmuk-Batang.ttf
# Microsoft Mac Office fonts
Name: Batang
Class: Korea
Provides(40): HYSMyeongJo-Medium
Filename(50): Batang.ttf

and run

$ sudo perl cjk-gs-integrate.pl --debug --debug --force --link-texmf --fontdef=/path/to/database.txt 2>database-test.log

The debug log says

cjk-gs-integrate [DEBUG]: filename: batang.ttf
cjk-gs-integrate [DEBUG]: type: ttf
cjk-gs-integrate [DEBUG]: filename: Baekmuk-Batang.ttf
cjk-gs-integrate [DEBUG]: type: ttf
cjk-gs-integrate [DEBUG]: Dumping fontfiles for Baekmuk-Batang: $VAR1 = {
  'batang.ttf' => {
    'priority' => '20',
    'type' => 'TTF'
  },
  'Baekmuk-Batang.ttf' => {
    'type' => 'TTF',
    'priority' => '10'
  }
};
cjk-gs-integrate [DEBUG]: filename: Batang.ttf
cjk-gs-integrate [DEBUG]: type: ttf
cjk-gs-integrate [DEBUG]: Dumping fontfiles for Batang: $VAR1 = {
  'Batang.ttf' => {
    'type' => 'TTF',
    'priority' => '50'
  }
};
cjk-gs-integrate [DEBUG]: checking for kpsewhich  "batang.ttf"  "Baekmuk-Batang.ttf"  "Batang.ttf" 
cjk-gs-integrate [DEBUG]: Found files /Library/Fonts/Microsoft/batang.ttf /Library/Fonts/Microsoft/Batang.ttf
cjk-gs-integrate [DEBUG]: dumping font database before file check:
cjk-gs-integrate [DEBUG]: $VAR1 = {
  'Baekmuk-Batang' => {
    'class' => 'Korea',
    'provides' => {
      'HYSMyeongJo-Medium' => '41'
    },
    'ttfname' => 'Baekmuk-Batang.ttf',
    'files' => {
      'batang.ttf' => {
        'priority' => '20',
        'type' => 'TTF'
      },
      'Baekmuk-Batang.ttf' => {
        'type' => 'TTF',
        'priority' => '10'
      }
    }
  },
  'Batang' => {
    'ttfname' => 'Batang.ttf',
    'provides' => {
      'HYSMyeongJo-Medium' => '40'
    },
    'class' => 'Korea',
    'files' => {
      'Batang.ttf' => {
        'type' => 'TTF',
        'priority' => '50'
      }
    }
  }
};
cjk-gs-integrate [DEBUG]: dumping basename to filename list:
cjk-gs-integrate [DEBUG]: $VAR1 = {
  'Batang.ttf' => '/Library/Fonts/Microsoft/Batang.ttf',
  'batang.ttf' => '/Library/Fonts/Microsoft/batang.ttf'
};
cjk-gs-integrate [DEBUG]: dumping font database:
cjk-gs-integrate [DEBUG]: $VAR1 = {
  'Baekmuk-Batang' => {
    'files' => {
      'batang.ttf' => {
        'type' => 'TTF',
        'target' => '/Library/Fonts/Microsoft/batang.ttf',
        'priority' => 20
      }
    },
    'type' => 'TTF',
    'available' => 1,
    'subfont' => 0,
    'target' => '/Library/Fonts/Microsoft/batang.ttf',
    'class' => 'Korea',
    'provides' => {
      'HYSMyeongJo-Medium' => '41'
    },
    'ttfname' => 'Baekmuk-Batang.ttf'
  },
  'Batang' => {
    'type' => 'TTF',
    'files' => {
      'Batang.ttf' => {
        'priority' => 50,
        'type' => 'TTF',
        'target' => '/Library/Fonts/Microsoft/Batang.ttf'
      }
    },
    'target' => '/Library/Fonts/Microsoft/Batang.ttf',
    'provides' => {
      'HYSMyeongJo-Medium' => '40'
    },
    'class' => 'Korea',
    'ttfname' => 'Batang.ttf',
    'available' => 1,
    'subfont' => 0
  }
};
cjk-gs-integrate [DEBUG]: dumping aliases:
cjk-gs-integrate [DEBUG]: $VAR1 = {
  'HYSMyeongJo-Medium' => {
    '40' => 'Batang',
    '41' => 'Baekmuk-Batang'
  }
};

Therefore, both symlinks "batang.ttf" and "Baekmuk-Batang.ttf" points to /Library/Fonts/Microsoft/Batang.ttf, which is an unexpected result.

Thanks for providing this tool to configure gs CJK fonts!

For tex users, it's reasonable to assume kpsewhich is always available. But in my case, I use this script for non-tex reasons. If I don't have texlive installed, running gs_cjk_intergrate.pl will ruin my ghostscript.

I think it's better to check if kpsewhich is available, and the script should exit if kpsewhich is not found.

It would be probably better to have the font database ordered by font files with a set of alias/possible file names. Maybe ...

The current --remove operation only removes the files that would be generated for the fonts found at the time the script is run.

It would be nice to have a general cleanup operation to remove all the stuff that could have been generated by the script.

A first try with make_all_fonts_available in the remove case did not work out, because we cannot determine the type of the representative.

Would needs to be done is loop over all fonts stanza, and loop over all candidate fonts / filenames, and check whether the respective file is present, and if it is a link, remove it.

[devel:155] 以降の「cjk-gs-integrate のリンク」の議論を経て，「cjk-gs-integrate を2回以上実行したときにリンクが壊れる」という現象が起きなくなりました。見つかったファイルが（symlink ではなく）実際のファイルかどうか check するコードを入れていただきありがとうございます。

さて，最後の commit 1f9649d で誤って消されてしまったコードがあることに気づきました。今のものでは --link-texmf に argument を付けずに実行することができなくなっていますが，以下のパッチで直ると思います。

--- cjk-gs-integrate.pl.orig    2016-01-14 19:14:54.000000000 +0900
+++ cjk-gs-integrate.pl 2016-01-14 19:31:25.000000000 +0900
@@ -282,6 +282,21 @@
   $Data::Dumper::Indent = 1;
 }

+if (defined($opt_texmflink)) {
+  my $foo;
+  if ($opt_texmflink eq '') {
+    # option was passed but didn't receive a value
+    #  -> use TEXMFLOCAL
+    chomp( $foo = `kpsewhich -var-value=TEXMFLOCAL`);
+  } else {
+    # option was passed with an argument
+    #  -> use it
+    $foo = $opt_texmflink;
+  }
+  $opt_texmflink = $foo;
+}
+
+
 main(@ARGV);

 #

hira-aliases ブランチの cjk-gs-integrate.pl を試してみましたが，うまくいきませんでした。

• Sierra上の美文書第7版TeX環境（hiragino-elcapitan-pron設定）に対して $ sudo perl cjk-gs-integrate.pl --debug --link-texmf --force を実行したときの出力
• 生成された cidfmap.aliases
• $ gs -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=hoge.pdf -c .setpdfwrite -f hoge.ps の出力

cidfmap.aliases に手動で

/HiraMinProN-W3 /IPAexMincho ;
/HiraKakuProN-W6 /IPAexGothic ;

などと書き加えれば，gs が通り，IPAex が正しく埋め込まれました。

Currently we link only the target to the texmf tree, but we should name the link according to the "canonical name": For CID fonts this is just the PSName (head in the target), for TTF fonts we need to think about what to do, probably add another field "CanonicalName"

先日、macOS 10.15 Catalina Beta 1が降ってきましたので、ひとまず、 @aminophen さんの query.sh による手法 に必要なデータを吐き出しました。

• CatalinaBeta1-FontList-mod.txt
• CatalinaBeta1-fcquery.txt

参考： macOS 10.15 Catalina Beta 1 に同梱されているフォント置き場

• /Library/Fonts: 何も入っていない。
• /System/Library/Fonts : 入っている。加えて、macOS Mojaveの /Library/Fonts/ 以下が /System/Library/Fonts/Supplemental/ に入った感じ！？
• /System/Library/AssetsV2/com_apple_MobileAsset_Font6: これまで /System/Library/Assets/com_apple_MobileAsset_Font{3,4,5} だった場所が変わった。

High Sierra のリリースが9/26に迫ってきましたので，GM版をインストールして，和文フォントの状況を調べてみました。ざっと調べてみた感じでは，この表のようになっているようでした。

Sierra からの変更点

1. ヒラギノ丸ゴ ProN W4.ttc が /Library/Fonts から /System/Library/Fonts に移動した。
2. /System/Library/Assets/ 以下の深いところにあったファイル群が一律に/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Support/FontSubsets に移動した。 /System/Library/Assets/com_apple_MobileAsset_Font3 以下の深いところにあったフォントファイルが，/System/Library/Assets/com_apple_MobileAsset_Font4 以下の深いところに移動した。
3. 凸版文久のファイル名に，PS Name と同じ Pr6N や StdN という文字列が追加された。
4. ヒラギノ明朝 ProN W3.ttc と ヒラギノ明朝 ProN W6.ttc が合体して ヒラギノ明朝 ProN.ttc になった。

[1] に関しては，cjk-gs-integrate を実行すれば /System/Library/Fonts をサーチしたときに ヒラギノ丸ゴ ProN W4.ttc が発見されるから問題ないでしょう。

[2] に関しては，cjk-gs-integrate のサーチパスに当該パス名を加えればよいでしょう。

[3] に関しては，2通りのアプローチがあると思います。1つは，シンボリックリンク名はSierraと同様にPr6N/StdNなしで作成するように設計するという方法です。その場合，ptex-fontmaps の toppanbunkyu-sierra の設定はそのまま流用できるというメリットがあります。デメリットとしては，実フォント名にもPS名にもPr6NがついているのにシンボリックリンクだけPr6Nが付かないことになる，という気持ち悪さでしょうか。

もう1つの方法としては，Pr6NありのHigh Sierra用凸版文久フォント設定を，Sierra用凸版文久フォント設定とは別に用意するという方法です。この場合，ptex-fontmapsの toppanbunkyu-sierra とは別に，フォント名に Pr6N などを加えた toppanbunkyu-highsierra という設定を新規に増設する必要があります。また，それに加えて，ToppanBunkyuGothic.ttc と ToppanBunkyuGothicPr6N.ttc の間には，[4] で述べるヒラギノ明朝と同様のOTCシンボリックリンク名決定問題が生じます。

[4] のヒラギノ明朝について，どうするべきか悩んでいます。例えば

Name: HiraMinProN-W6
Class: Japan
Provides(30): FutoMinA101-Bold
Provides(30): FutoMinA101Pro-Bold
OTFname(20): ヒラギノ明朝 ProN W6.otf
OTFname(19): ヒラギノ明朝 ProN W6.otf
OTFname(10): HiraMinProN-W6.otf
OTCname(30): ヒラギノ明朝 ProN W6.ttc(0)
OTCname(29): ヒラギノ明朝 ProN W6.ttc(0)
OTCname(28): HiraginoSerif-W6.ttc(0)
OTCname(27): ヒラギノ明朝 ProN.ttc(2)
OTCname(26): ヒラギノ明朝 ProN.ttc(2)
OTCname(25): HiraginoSerif.ttc(2)

のように書いたとすると，Sierra の /System/Library/ヒラギノ明朝 ProN W6.ttc を，TEXMFLOCAL内にHiraginoSerif.ttc という名前でsymlink作成してしまうのではないでしょうか。正しくは，

• （HiraMinProN-W6 を含んでいる） ヒラギノ明朝 ProN W6.ttc が存在する場合は HiraginoSerif-W6.ttc という名前でsymlinkを作成する。
• （HiraMinProN-W6 を含んでいる） ヒラギノ明朝 ProN.ttc が存在する場合は HiraginoSerif.ttc という名前でsymlinkを作成する。

という挙動をしてほしいわけです。これは設計上可能でしょうか？

It seems that cjk-gs-integrate doesn't recognize fonts from the SourceHan or NotoCJK families.

gs-9.27 にアップデートしてから，今の cjk-gs-integrate の設定方法では「dvips + ps2pdf (gs)」での日本語フォント埋め込みがうまくいかないようです。

• win32 版 TeX Live 2019 付属の tlgs
• macOS に MacPorts でインストールした gs

の両方で試して判明したことを書いておきます。

テスト方法

kanji-config-updmap-sys で ipaex フォント埋め込みの設定になっている前提で

\documentclass{article}
\begin{document}
これは日本語の文章です。
\end{document}

というファイル (dvipstest.tex) を用意して

$ platex dvipstest.tex
$ dvips dvipstest.dvi
$ rungs -sDEVICE=pdfwrite -dBATCH -dNOPAUSE -sOutputFile=dvipstest.pdf dvipstest.ps

を実行します。

cjk-gs-integrate を使った設定が有効な場合

$ cjk-gs-integrate --link-texmf --force

を実行した状態で上のテストを実行すると

GPL Ghostscript 9.27 (2019-04-04)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Loading IPAexMincho-H font from C:/texlive/2019/tlpkg/tlgs/Resource/Font/IPAexMincho-H... Loading a TT font from C:/texlive/2019/tlpkg/tlgs/Resource/CIDFSubst/ipaexm.ttf to emulate a CID font IPAexMincho ... Done.
Can't find font with non-string name: false.
Querying operating system for font files...
Didn't find this font on the system!
Substituting font Courier for false.
Loading NimbusMonL-Regu font from C:/texlive/2019/tlpkg/tlgs/fonts/ucrr8a.pfb... 6096084 4721258 2039384 735064 1 done.

となります。cjk-gs-integrate が作成した「IPAexMincho-H」という snippet を見つけてしまい，これが失敗して欧文フォントが使われて PDF が文字化けします。

このような挙動が起きる gs のバージョンは，macOS (MacPorts) で過去の gs を巻き戻して調べた限りでは

• [email protected]_1+x11 (最新) or [email protected]_0+x11 で起こる
• [email protected]_0+x11 では起きない（現行 cjk-gs-integrate でも大丈夫）

のようです。

tlgs (win32) の初期状態の場合

tlgs (win32) はもともと頑張って設定されているはずなので，試しに

$ cjk-gs-integrate --link-texmf --cleanup

を実行して cjk-gs-integrate の設定を消してみると，

GPL Ghostscript 9.27 (2019-04-04)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.
Querying operating system for font files...
Loading a TT font from C:/texlive/2019/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf to emulate a CID font IPAexMincho ... Done.

となって，「ipaexm.ttf」を正しく見つけ出してくれました。

疑問点

この挙動を考えると，gs-9.27 以降はどうやら「cjk-gs-integrate が作った TrueType フォントの snippet」があると良くないようです。ただ，もう少し調査が必要です。

• snippet の中身が良くないのか，snippet が存在してはいけないのか？
• gs-9.26 以前でも 9.27 以降でも大丈夫な設定方法は？
• 問題は TTF だけなのか？

This is my (HY's) TODO list:

In tlgs.win32, cidfmap contains a line

(cidfmap.TeXLive) .runlibfile

and, in the pre-shipped cidfmap.TeXLive lie the following entries

% Aliases for Windows XP and later versions
% =========================================

/AdobeHeitiStd-Regular  /SimHei ;
/AdobeSongStd-Light     /SimSun ;
/AdobeMingStd-Light     /MingLiU ;
/KozMinPr6N-Regular     /MS-Mincho ;
/AdobeMyungjoStd-Medium /Batang ;

These aliased fonts might be actually available as real CID (.otf) fonts. However, in the current setting, the real fonts are not used because the CID fonts are overridden by the above aliases. To avoid this problem, these entries should be disabled when the corresponding real fonts are found.

I believe that it is safe and better enough to remove the line (cidfmap.TeXLive) .runlibfile when our (= cjk-gs-integrate) settings are effective.

But first, we have to ensure that all features supported by cidfmap.TeXLive are also available with our cidfmap.local. Below is the list of lines which are currently unavailable in ours:

Font database

/ArialUnicodeMS-KR <<
  /FileType /TrueType
  /SubfontID 0
  /CSI [(Korea1) 3]
  /Path (ARIALUNI.TTF) >> ; % W7
/ArialUnicodeMS-CNS <<
  /FileType /TrueType
  /SubfontID 0
  /CSI [(CNS1) 2]
  /Path (ARIALUNI.TTF) >> ; % W7
/ArialUnicodeMS-JP <<
  /FileType /TrueType
  /SubfontID 0
  /CSI [(Japan1) 3]
  /Path (ARIALUNI.TTF) >> ; % W7
/ArialUnicodeMS-GB <<
  /FileType /TrueType
  /SubfontID 0
  /CSI [(GB1) 2]
  /Path (ARIALUNI.TTF) >> ; % W7

Aliases

/HeiseiKakuGo-W5        /MS-Gothic ;
/HeiseiMin-W3           /MS-Mincho ;

I don't know what HeiseiKakuGo-W5 and HeiseiMin-W3 are and where they are used. (native CID fonts in ancient days, which are not available in .otf format?)

While trying to add a .dat file for Adobe's SourceHan fonts, I noticed that the syntax of such files isn't documented.

日本語の priority は morisawa → … → ipa と決められていますが、**語と韓国語の priority も決めたいと思っています。いまのものだと Nanum の priority が Adobe の次に早いのですが、Nanum は JFM に比べて幅がせまいので、うまくいかない可能性があり、あまり早くしたくないです。

Nanum を embed すると、font の幅が 90% くらいしかなく、環境によっては文字がずれるかもしれないと思います。幅がせまいというのは PDF を見てください（わかりにくいですが、download していただき、PDF Viewer で drag して文字を選択すると、少しせまいです）。

• kfont-nanum.pdf
• kfont-baekmuk.pdf

個人的なメモとして、書いておきます：私の PDF は以下のようにして作りました。（HiraMinProN-W3 の snippet / symlink は最初から setup が完了している状態で、はじめます）

まず、次の二つのファイルを作りました：

kfont.map

uphysmjm-h HYSMyeongJo-Medium-UniKS-UTF16-H
uprml-h HiraMinProN-W3-UniJIS-UTF16-H

kfont.tex

\documentclass[uplatex]{jsarticle}
\usepackage[english]{babel}
\usepackage{pxbabel}
\begin{document}
ああああああ\par
\foreignlanguage{korean}{내가득합니다}\par
あ\par
\foreignlanguage{korean}{니}\par
\end{document}

そして、kfont.ps をつくります：

$ uplatex kfont.tex
$ dvips -u kfont.map kfont.dvi

次に、kfont.dat もつくります：

Name: NanumMyeongjo
Class: Korea
Provides(20): HYSMyeongJo-Medium
Filename: NanumMyeongjo.ttc(0)

Name: Baekmuk-Batang
Class: Korea
Provides(40): HYSMyeongJo-Medium
Filename(20): batang.ttf
Filename(10): Baekmuk-Batang.ttf

そして

$ sudo perl cjk-gs-integrate.pl --link-texmf --force --fontdef=kfont.dat
$ ps2pdf kfont.ps

これを実行すると、HYSMyeongJo-Medium が NanumMyeongjo に置換されて埋め込まれます。こうしてつくったのが kfont-nanum.pdf です。

次に kfont.dat の中で Baekmuk-Batang の priority を 40 から 10 に変えて

$ sudo perl cjk-gs-integrate.pl --link-texmf --force --fontdef=kfont.dat
$ ps2pdf kfont.ps

を実行します。すると、今度は HYSMyeongJo-Medium が Baekmuk-Batang に置換されて埋め込まれます。こうしてつくったのが kfont-baekmuk.pdf です。

データベースに登録されている OTF / TTF について otfinfo を走らせていると，以下の3つが変です：

/Applications/Microsoft Word.app/Contents/Resources/Fonts/malgun.ttf
[DEBUG]: ... PSName returned by otfinfo (MalgunGothic) is
[DEBUG]: different from our database (MalgunGothicRegular), discarding!

/Applications/Microsoft Word.app/Contents/Resources/Fonts/yumindb.ttf
[DEBUG]: ... PSName returned by otfinfo (YuMincho-Demibold) is
[DEBUG]: different from our database (YuMincho-DemiBold), discarding!

/usr/local/texlive/2018dev/texmf-dist/fonts/truetype/public/unfonts-core/UnDinaruLight.ttf
[DEBUG]: ... PSName returned by otfinfo (UnDinaru-Bold) is
[DEBUG]: different from our database (UnDinaru-Light), discarding!

最初の2つは「Office for Mac 2016 でインストールされるフォントとデータベースが合っていない」という状態のようなので，調べます。（単に私が入力ミスしただけかもしれないし，Windows 7 / 8.1 のフォントと Office for Mac 2016 が違うのかもしれない）

最後の UnDinaruLight.ttf はそもそも unfonts-core に入っているフォントファイルが不正なようです。

データベースをいちいち作るのがめんどくさくなってきたので，「スクリプトを走らせると，見つかる全ての CJK フォントに対するデータベースを作る」というようなことができないか？と考え始めています。

必要な処理は

• [1] cjk-gs-integrate のサーチ対象になるディレクトリにある全フォントのうち
• [2] 日本語・**語・韓国語に使えるフォントに絞り，（このとき Class を得る）
• [3] それが OTF/OTC/TTF/TTC のどれかを判定し
• [4] PSName を（及びコレクションの場合は index も）出力する

ということになると思いますが，何か良い案はないでしょうか？

（さすがに Provides を自動生成するのは無理そうなので，それは手動になるでしょう。）

最初に思いついたのは fontconfig ですが

• fc-list すれば [1] は一部実現できそう（ただし，TEXMF ツリーを探すために別途設定が必要なはず）
• fc-query などを使えば [3] や [4] はできるかも
  • OTC/TTC の判定は fontformat=CFF か fontformat=TrueType かでわかる。
  • PSName と index はそれぞれ postscriptname と id でわかる。

という感じです。[2] のやり方がわからないのと，[1] の「fontconfig に TEXMF ツリーも探させるやり方」がわかれば進むかもしれません。

他のやり方があれば提案していただけると助かります。LuaTeX あるいは XeTeX でこのような処理ができれば better だと思うので，そういうのがあればありがたいです。

In check_for_files() function, the following comment is found:

      # other dirs to check, for normal unix?

For normal unix, there is a quite large possibility of having

• "/usr/local/etc/fonts/fonts.conf",
• "/etc/fonts/fonts.conf"

How feasible is it to parse these files to obtain extra directories?