linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akira Yokosawa <akiyks@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: "Wu X.C." <bobwxc@email.cn>, SeongJae Park <sj38.park@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Akira Yokosawa <akiyks@gmail.com>
Subject: [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art
Date: Thu, 24 Jun 2021 21:06:59 +0900	[thread overview]
Message-ID: <386938dc-6290-239c-4b4f-c6153f3d98c5@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

Subject: [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art

Hi all,

This is another attempt to improve translations' pdf output.
I see there is a mismatch in the font choice for CJK documents, which
causes poor-looking ascii-art where CJK characters and Latin letters
are mixed used.

One of noticeable examples of such ascii-art can be found in
Korean translation of memory-barriers.txt.

Hence the author of Korean translation of memory-barriers.txt is
in the CC list.

At first, I thought the issue could be fixed by simply selecting
"Noto Sans Mono CJK SC" as both of monofont and CJKmonofont.
It fixed the mis-alignment in the Chinese translation, but failed
in the Korean translation.

It turns out that Hangul characters in "Noto Sans Mono CJK SC"
are slightly narrower than Chinese and Japanese counterparts.
I have no idea why the so-called "mono" font has non-uniform
character widths.

GNU Unifont is an alternative monospace font which covers
almost all Unicode codepoints.
However, due to its bitmap-font nature, the resulting document
might not be acceptable to Korean readers, I guess.

As a compromise, Patch 2/3 enables Unifont only when it is available.

A comparison of some of ascii-art figures before and after this change
can be found in the attached PDF.

Patch 1/3 is a preparation of Patch 2/3.
It converts font-availability check in python to LaTeX and make the
resulting LaTeX code portable across systems with different sets of
installed fonts.

Patch 3/3 is an independent white space fix (or a workaround of Sphinx
mis-handling of tabs behind CJK characters) in Korean translation
of memory-barriers.txt.

Any feedback is welcome!

Side note:

In Korean translation's PDF, I see there is another issue of missing
white spaces between Hangul "phrase groups" in normal text.
Looks like the pair of xelatex + xeCJK just ignores white spaces
between CJK characters.

There is a package named "xetexko", which might (or might not) be
a reasonable choice for Korean translation.

It should be possible to use a language-specific preamble once
we figure out the way to load per-directory Sphinx configuration
and move translation docs into per-language subdirectories.  

As I am not familiar with Korean LaTeX typesetting, I must defer to
those who are well aware of such conventions.

        Thanks, Akira
--
Akira Yokosawa (3):
  docs: pdfdocs: Refactor config for CJK document
  docs: pdfdocs: Add font settings for CJK ascii-art
  docs: ko_KR: Use white spaces behind CJK characters in ascii-art

 Documentation/conf.py                         | 26 +++++++++++--------
 .../translations/ko_KR/memory-barriers.txt    | 14 +++++-----
 2 files changed, 22 insertions(+), 18 deletions(-)

-- 
2.17.1


[-- Attachment #2: ascii-art-alignment.pdf --]
[-- Type: application/pdf, Size: 197513 bytes --]

             reply	other threads:[~2021-06-24 12:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-24 12:06 Akira Yokosawa [this message]
2021-06-24 12:08 ` [RFC PATCH 1/3] docs: pdfdocs: Refactor config for CJK document Akira Yokosawa
2021-06-24 12:11 ` [RFC PATCH 2/3] docs: pdfdocs: Add font settings for CJK ascii-art Akira Yokosawa
2021-06-24 12:14 ` [RFC PATCH 3/3] docs: ko_KR: Use white spaces behind CJK characters in ascii-art Akira Yokosawa
2021-06-24 12:59 ` [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art Mauro Carvalho Chehab
2021-06-25  6:55 ` Wu X.C.
2021-06-25  7:50   ` Mauro Carvalho Chehab
2021-06-25  9:22     ` Akira Yokosawa
2021-06-25 10:24       ` Mauro Carvalho Chehab
2021-06-25 11:32         ` Akira Yokosawa
2021-06-25 17:17           ` Wu X.C.
2021-06-25 18:11           ` Mauro Carvalho Chehab
2021-06-26  2:32             ` Akira Yokosawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=386938dc-6290-239c-4b4f-c6153f3d98c5@gmail.com \
    --to=akiyks@gmail.com \
    --cc=bobwxc@email.cn \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sj38.park@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).