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

出力したPDFの文字がK100にならないケースがある #276

Open
UskeS opened this issue Apr 23, 2022 · 2 comments
Open

出力したPDFの文字がK100にならないケースがある #276

UskeS opened this issue Apr 23, 2022 · 2 comments
Labels

Comments

@UskeS
Copy link
Member

UskeS commented Apr 23, 2022

black-check

憶測ですが、概ね下記のようなルールで文字の色がおかしくなるもようです。

  • コードスパンがページ中に存在する
  • コードスパン以降の文字
  • コードスパンがあるページの句読点

--press-readyオプションがあってもなくても、Create Bookのテンプレートから出力したPDFで再現します。

@MurakamiShinyu
Copy link
Member

こちらでもChromeで出力したPDFをAcrobat Proの出力プレビューで見てみたところ次のことがわかりました。

  • 1ページすべてのテキストの色が黒(color: black = #000000 で背景色なし)ならば、そのページのテキストはすべて K100 になる。
  • ページ内に黒くないテキストがあるならば、ページの先頭から最初の黒くないテキストの前までは K100 になり、そのあとページの終わりまで黒のテキストでもK100にならない。(シミュレーションプロファイルがJapan Color 2001 Coatedの場合、C93 M88 Y89 K80 になる)

(「コードスパン」のスタイルではテキスト色と背景色の指定があるので上記の条件に該当。句読点はtext-spacing処理に問題がありPDF内でのテキストの順番がページの最後になるため上記の条件に該当する)

Chrome (Chromium) 以外ではどうかと、Firefox と Safari でのPDF出力を調べたところ、ページ内の黒以外のテキストの有無に関わらず、K100にはなりません(C93 M88 Y89 K80 になる)。

ブラウザ出力のRGBからCMYKへの変換で、Japan Color 2001 Coatedなどプロファイルを使うとき、K100にならないのが普通で、Chrome (Chromium)の場合、ページ内に黒しか使われてないうちは特別にK100になるということなのかもしれません。

@spring-raining
Copy link
Member

ご確認ありがとうございます。Webは原則的にRGBで色情報を取り扱うので、自動的にK100で出力するChromeがある意味特殊で、C93 M88 Y89 K80で出力する他のブラウザの動作が正しいといえると思います。もしこの問題に対処するのであれば、PDFの後処理としてVivliostyle CLI or press-readyがK100に変換する処理を入れる必要がありそうです。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants