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

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

[Akira Yokosawa]

[-- 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 --]

[RFC PATCH 1/3] docs: pdfdocs: Refactor config for CJK document

[Akira Yokosawa]

To make generated LaTeX code portable across systems with different sets
of available fonts, convert font-availability check in python code to
LaTeX code by using a conditional command provided by the "fontspec"
package.

This will help those who want to run Sphinx on one machine/container
and run latexmk on other machines/containers with different font
configurations.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 Documentation/conf.py | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 7d92ec3e5b6e..22f083bafaae 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -358,26 +358,23 @@ latex_elements = {
 # At least one book (translations) may have Asian characters
 # with are only displayed if xeCJK is used
 
-cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore')
-if cjk_cmd.find("Noto Sans CJK SC") >= 0:
-    latex_elements['preamble']  += '''
+latex_elements['preamble']  += '''
+    \\IfFontExistsTF{Noto Sans CJK SC}{
 	% This is needed for translations
-        \\usepackage{xeCJK}
-        \\setCJKmainfont{Noto Sans CJK SC}
+	\\usepackage{xeCJK}
+	\\setCJKmainfont{Noto Sans CJK SC}
 	% Define custom macros to on/off CJK
 	\\newcommand{\\kerneldocCJKon}{\\makexeCJKactive}
 	\\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive}
-	% To customize \sphinxtableofcontents
+	% Inactivate CJK after tableofcontents (using etoolbox)
 	\\usepackage{etoolbox}
-	% Inactivate CJK after tableofcontents
 	\\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{}
-     '''
-else:
-    latex_elements['preamble']  += '''
+    }{ % No CJK font
 	% Custom macros to on/off CJK (Dummy)
 	\\newcommand{\\kerneldocCJKon}{}
 	\\newcommand{\\kerneldocCJKoff}{}
-     '''
+    }
+'''
 
 # Fix reference escape troubles with Sphinx 1.4.x
 if major == 1:
-- 
2.17.1

[RFC PATCH 2/3] docs: pdfdocs: Add font settings for CJK ascii-art

[Akira Yokosawa]

This is irrelevant to those who don't care translations docs.

Current font choice of "DejaVu Sans Mono" and "Noto Sans CJK SC" for
monospace fonts generates misaligned ascii-art figures in translations.

Using "Noto Sans Mono CJK SC" for both the monofont and CJKmonofont
choices is a better option.

As for Korean translation, there remain character width mismatches.

Hangul characters in "Noto Sans Mono CJK SC" are slightly narrower than
Chinese and Japanese characters, despite the "Mono" in the font name.

This results in mis-aligned ascii-art figures in Korean translation
of memory-barriers.txt.

Proper width Hangul characters are available in "Unifont", although with
degraded look of CJK characters due to Unifont's bitmap-font nature.

So "Unifont" is used only when it is found on the system.

Note 1: Unifont can be installed by:
    (Ubuntu) apt-get install ttf-unifont
    (Fedora) dnf install unifont-fonts

Note 2: Let us know if there is a better monospace font choice for Hangul.

Note 3: Sphinx itself is confused by tabs behind CJK characters. Korean
translation of memory-barriers.txt needs a couple of fixes to this
effect, of which a follow up change takes care.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 Documentation/conf.py | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 22f083bafaae..a95bd2123da1 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -363,12 +363,19 @@ latex_elements['preamble']  += '''
 	% This is needed for translations
 	\\usepackage{xeCJK}
 	\\setCJKmainfont{Noto Sans CJK SC}
+	\\setCJKsansfont{Noto Sans CJK SC}
+	\\setCJKmonofont{Noto Sans Mono CJK SC}
+	\\setmonofont{Noto Sans Mono CJK SC}
 	% Define custom macros to on/off CJK
 	\\newcommand{\\kerneldocCJKon}{\\makexeCJKactive}
 	\\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive}
 	% Inactivate CJK after tableofcontents (using etoolbox)
 	\\usepackage{etoolbox}
 	\\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{}
+	\\IfFontExistsTF{Unifont}{
+	    % For alinged Korean ascii-art
+	    \\setCJKmonofont{Unifont}
+	}{}
     }{ % No CJK font
 	% Custom macros to on/off CJK (Dummy)
 	\\newcommand{\\kerneldocCJKon}{}
-- 
2.17.1

[RFC PATCH 3/3] docs: ko_KR: Use white spaces behind CJK characters in ascii-art

[Akira Yokosawa]

In verbatim ascii-art of Korean translation of memory-barriers.txt,
Sphinx is confused by tabs behind CJK chars and generates wrong number
of white spaces in LaTeX code.

As a workaround, use white spaces in such cases.

"html" output is also slightly improved by this change, but still need
some proper font choice, which is out of the scope of this change.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 .../translations/ko_KR/memory-barriers.txt         | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 64d932f5dc77..ff36b857ef72 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -1364,7 +1364,7 @@ Multicopy 원자성은 실제의 컴퓨터 시스템에서 항상 제공되지
 	=======================	=======================	=======================
 		{ X = 0, Y = 0 }
 	STORE X=1		r1=LOAD X (reads 1)	LOAD Y (reads 1)
-				<범용 배리어>		<읽기 배리어>
+				<범용 배리어>           <읽기 배리어>
 				STORE Y=r1		LOAD X
 
 CPU 2 의 Y 로의 스토어에 사용되는 X 로드의 결과가 1 이었고 CPU 3 의 Y 로드가
@@ -1394,7 +1394,7 @@ CPU 3 의 X 로드가 CPU 2 의 로드보다 뒤에 이루어졌으므로, CPU 3
 	=======================	=======================	=======================
 		{ X = 0, Y = 0 }
 	STORE X=1		r1=LOAD X (reads 1)	LOAD Y (reads 1)
-				<데이터 의존성>		<읽기 배리어>
+				<데이터 의존성>         <읽기 배리어>
 				STORE Y=r1		LOAD X (reads 0)
 
 이 변화는 non-multicopy 원자성이 만연하게 합니다: 이 예에서, CPU 2 의 X
@@ -1789,10 +1789,10 @@ CPU 메모리 배리어
 
 	TYPE		MANDATORY		SMP CONDITIONAL
 	===============	=======================	===========================
-	범용		mb()			smp_mb()
-	쓰기		wmb()			smp_wmb()
-	읽기		rmb()			smp_rmb()
-	데이터 의존성				READ_ONCE()
+	범용            mb()                    smp_mb()
+	쓰기            wmb()                   smp_wmb()
+	읽기            rmb()                   smp_rmb()
+	데이터 의존성                           READ_ONCE()
 
 
 데이터 의존성 배리어를 제외한 모든 메모리 배리어는 컴파일러 배리어를
@@ -2151,7 +2151,7 @@ wake_up() 이 무언가를 깨우게 되면, 이 함수는 범용 메모리 배
 	set_current_state();		STORE event_indicated
 	  smp_store_mb();		wake_up();
 	    STORE current->state	  ...
-	    <범용 배리어>		  <범용 배리어>
+	    <범용 배리어>                 <범용 배리어>
 	LOAD event_indicated		  if ((LOAD task->state) & TASK_NORMAL)
 					    STORE task->state
 
-- 
2.17.1

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

[Mauro Carvalho Chehab]

Em Thu, 24 Jun 2021 21:06:59 +0900
Akira Yokosawa <akiyks@gmail.com> escreveu:

> 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.

Argh! Yeah, it sounds that those translations will always be
problematic.

Your patch series makes sense to me (although I didn't try to
test). Perhaps one way would be to split the translations into
one separate book per language, although I suspect that such
change would offer their own problems, as cross-references
will be broken[1].

[1] There is a sphinx extension that solves it:
	https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html

But not sure how easy/hard would be to setup this one.

> 
> 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(-)
> 



Thanks,
Mauro

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

[Wu X.C.]

On Thu, Jun 24, 2021 at 09:06:59PM +0900, Akira Yokosawa wrote:
> Subject: [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art
> 
> Hi all,

Hi Akira,

> 
> 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.

OK, it works.

But I still want to say that the display effect of Unifont is really
not good. Unifont's lattice is too small, and only one size.
http://fars.ee/QA1k.jpg	    http://fars.ee/GAAv.jpg
Looks like computers 20 years ago, LOL :)

It there any chance to use other fonts, like *Sarasa Mono* ?
                                              等距更紗黑體
Looks more beautifull http://fars.ee/DTT6.jpg
But I guess not many people installed it.

> 
> 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.

Yes, xeCJK ignores spaces between CJK characters by default.

> 
> 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
> 

Thanks,
	Wu X.C.

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

[Mauro Carvalho Chehab]

Em Fri, 25 Jun 2021 14:55:24 +0800
"Wu X.C." <bobwxc@email.cn> escreveu:

> On Thu, Jun 24, 2021 at 09:06:59PM +0900, Akira Yokosawa wrote:
> > Subject: [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art
> > 
> > Hi all,  
> 
> Hi Akira,
> 
> > 
> > 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.  
> 
> OK, it works.
> 
> But I still want to say that the display effect of Unifont is really
> not good. Unifont's lattice is too small, and only one size.
> http://fars.ee/QA1k.jpg	    http://fars.ee/GAAv.jpg
> Looks like computers 20 years ago, LOL :)
> 
> It there any chance to use other fonts, like *Sarasa Mono* ?
>                                               等距更紗黑體
> Looks more beautifull http://fars.ee/DTT6.jpg
> But I guess not many people installed it.

Does Sarasa mono looks nice for Japanese, Chinese and Korean
(plus latin)?

If so, I guess it shouldn't be a problem to use it, as the
./scripts/sphinx-pre-install can be patched to recommend
its install.

Thanks,
Mauro

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

[Akira Yokosawa]

On Fri, 25 Jun 2021 09:50:59 +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Jun 2021 14:55:24 +0800
> "Wu X.C." <bobwxc@email.cn> escreveu:
> 
>> On Thu, Jun 24, 2021 at 09:06:59PM +0900, Akira Yokosawa wrote:
>>> Subject: [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art
>>>
>>> Hi all,  
>>
>> Hi Akira,
>>
>>>
>>> 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.  
>>
>> OK, it works.
>>
>> But I still want to say that the display effect of Unifont is really
>> not good. Unifont's lattice is too small, and only one size.
>> http://fars.ee/QA1k.jpg	    http://fars.ee/GAAv.jpg
>> Looks like computers 20 years ago, LOL :)
>>
>> It there any chance to use other fonts, like *Sarasa Mono* ?
>>                                               等距更紗黑體
>> Looks more beautifull http://fars.ee/DTT6.jpg
>> But I guess not many people installed it.

Thank you for the nice suggestion.
Yes, Hangul characters in "Sarasa Mono" have the same widths.

> 
> Does Sarasa mono looks nice for Japanese, Chinese and Korean
> (plus latin)?

Yes, I tested "Sarasa Mono SC" and it covers all CJK fonts.
The SC variant has Simple Chinese glyph where other languages
have their own preferred glyph, but that is same in "Noto Sans
Mono SC".

Currently, there is no verbatim/literal blocks in the Japanese
translation, so I tested with only a short Japanese sentence.

I'll post a v2 which uses "Sarasa Mono SC" instead of Unifont.

> 
> If so, I guess it shouldn't be a problem to use it, as the
> ./scripts/sphinx-pre-install can be patched to recommend
> its install.

One minor problem might be that the Sarasa font needs manual
download (and install).

        Thanks, Akira

> 
> Thanks,
> Mauro
> 

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

[Mauro Carvalho Chehab]

Em Fri, 25 Jun 2021 18:22:26 +0900
Akira Yokosawa <akiyks@gmail.com> escreveu:

> On Fri, 25 Jun 2021 09:50:59 +0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Jun 2021 14:55:24 +0800
> > "Wu X.C." <bobwxc@email.cn> escreveu:
> >   
> >> On Thu, Jun 24, 2021 at 09:06:59PM +0900, Akira Yokosawa wrote:  
> >>> Subject: [RFC PATCH 0/3] docs: pdfdocs: Improve alignment of CJK ascii-art
> >>>
> >>> Hi all,    
> >>
> >> Hi Akira,
> >>  
> >>>
> >>> 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.    
> >>
> >> OK, it works.
> >>
> >> But I still want to say that the display effect of Unifont is really
> >> not good. Unifont's lattice is too small, and only one size.
> >> http://fars.ee/QA1k.jpg	    http://fars.ee/GAAv.jpg
> >> Looks like computers 20 years ago, LOL :)
> >>
> >> It there any chance to use other fonts, like *Sarasa Mono* ?
> >>                                               等距更紗黑體
> >> Looks more beautifull http://fars.ee/DTT6.jpg
> >> But I guess not many people installed it.  
> 
> Thank you for the nice suggestion.
> Yes, Hangul characters in "Sarasa Mono" have the same widths.
> 
> > 
> > Does Sarasa mono looks nice for Japanese, Chinese and Korean
> > (plus latin)?  
> 
> Yes, I tested "Sarasa Mono SC" and it covers all CJK fonts.
> The SC variant has Simple Chinese glyph where other languages
> have their own preferred glyph, but that is same in "Noto Sans
> Mono SC".
> 
> Currently, there is no verbatim/literal blocks in the Japanese
> translation, so I tested with only a short Japanese sentence.
> 
> I'll post a v2 which uses "Sarasa Mono SC" instead of Unifont.
> 
> > 
> > If so, I guess it shouldn't be a problem to use it, as the
> > ./scripts/sphinx-pre-install can be patched to recommend
> > its install.  
> 
> One minor problem might be that the Sarasa font needs manual
> download (and install).
> 
>         Thanks, Akira

If this is not yet packaged as part of texlive packages
on distros, this won't be a minor issue, as we'll need
to find procedures and test it for all distros supported
by the script.

Thanks,
Mauro

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

[Akira Yokosawa]

On Fri, 25 Jun 2021 12:24:23 +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Jun 2021 18:22:26 +0900
> Akira Yokosawa <akiyks@gmail.com> escreveu:
> 
>> On Fri, 25 Jun 2021 09:50:59 +0200, Mauro Carvalho Chehab wrote:
[...]
>>
>> One minor problem might be that the Sarasa font needs manual
>> download (and install).
>>
>>         Thanks, Akira
> 
> If this is not yet packaged as part of texlive packages
> on distros, this won't be a minor issue, as we'll need
> to find procedures and test it for all distros supported
> by the script.

Existence of "Sarasa Mono SC" can be checked by the command:

    fc-list | grep "Sarasa Mono SC," | grep "style=Regular" | wc -l

If the result is *not* "0", you have the font somewhere in your
fontconfig path.

I think this is portable across distros.
Wouldn't this suffice for sphinx-pre-install?

        Thanks, Akira
> 
> Thanks,
> Mauro
> 

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

[Wu X.C.]

On Fri, Jun 25, 2021 at 08:32:47PM +0900, Akira Yokosawa wrote:
> On Fri, 25 Jun 2021 12:24:23 +0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Jun 2021 18:22:26 +0900
> > Akira Yokosawa <akiyks@gmail.com> escreveu:
> > 
> >> On Fri, 25 Jun 2021 09:50:59 +0200, Mauro Carvalho Chehab wrote:
> [...]
> >>
> >> One minor problem might be that the Sarasa font needs manual
> >> download (and install).

It is officially releasing on Github:
<https://github.com/be5invis/Sarasa-Gothic>
Under OFL-1.1 License and provide both ttf and ttc format.
Then install 'sarasa-mono-sc-regular.ttf/c' in the compressed pack.

Above could be a part of tip message.

Thanks,
	Wu
> >>
> >>         Thanks, Akira
> > 
> > If this is not yet packaged as part of texlive packages
> > on distros, this won't be a minor issue, as we'll need
> > to find procedures and test it for all distros supported
> > by the script.
> 
> Existence of "Sarasa Mono SC" can be checked by the command:
> 
>     fc-list | grep "Sarasa Mono SC," | grep "style=Regular" | wc -l
> 
> If the result is *not* "0", you have the font somewhere in your
> fontconfig path.
> 
> I think this is portable across distros.
> Wouldn't this suffice for sphinx-pre-install?
> 
>         Thanks, Akira
> > 
> > Thanks,
> > Mauro
> > 

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

[Mauro Carvalho Chehab]

Em Fri, 25 Jun 2021 20:32:47 +0900
Akira Yokosawa <akiyks@gmail.com> escreveu:

> On Fri, 25 Jun 2021 12:24:23 +0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 25 Jun 2021 18:22:26 +0900
> > Akira Yokosawa <akiyks@gmail.com> escreveu:
> >   
> >> On Fri, 25 Jun 2021 09:50:59 +0200, Mauro Carvalho Chehab wrote:  
> [...]
> >>
> >> One minor problem might be that the Sarasa font needs manual
> >> download (and install).
> >>
> >>         Thanks, Akira  
> > 
> > If this is not yet packaged as part of texlive packages
> > on distros, this won't be a minor issue, as we'll need
> > to find procedures and test it for all distros supported
> > by the script.  
> 
> Existence of "Sarasa Mono SC" can be checked by the command:
> 
>     fc-list | grep "Sarasa Mono SC," | grep "style=Regular" | wc -l
> 
> If the result is *not* "0", you have the font somewhere in your
> fontconfig path.
> 
> I think this is portable across distros.
> Wouldn't this suffice for sphinx-pre-install?

No. The sphinx-pre-install tool generate a list of commands
needed to install the pre-reqs on a given distro.

For instance, if you run on opensuse without texlive, it would
print:


	# ./scripts/sphinx-pre-install 
	Detected OS: openSUSE Tumbleweed 20210515.
	Sphinx version: 3.5.4

	Warning: better to also install "latexmk".
...
	Warning: better to also install "xelatex".
	You should run:

	sudo zypper install --no-recommends texlive-latexmk-bin texlive-amscls texlive-amsfonts texlive-amsmath texlive-anyfontsize texlive-babel-english texlive-capt-of texlive-caption texlive-cmap texlive-colortbl texlive-courier texlive-dvips texlive-ec texlive-eqparbox texlive-euenc texlive-fancybox texlive-fancyvrb texlive-float texlive-fncychap texlive-framed texlive-helvetic texlive-luatex85 texlive-makeindex texlive-mdwtools texlive-metafont texlive-metapost texlive-multirow texlive-needspace texlive-oberdiek texlive-palatino texlive-parskip texlive-polyglossia texlive-preview texlive-psnfss texlive-tabulary texlive-threeparttable texlive-times texlive-titlesec texlive-tools texlive-ucs texlive-upquote texlive-wrapfig texlive-zapfchan texlive-zapfding texlive-xetex-bin

The same command, when executed on a different distro will
print a different set of packages and commands.

Thanks,
Mauro

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

[Akira Yokosawa]

On Fri, 25 Jun 2021 20:11:13 +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 25 Jun 2021 20:32:47 +0900
> Akira Yokosawa <akiyks@gmail.com> escreveu:
> 
>> On Fri, 25 Jun 2021 12:24:23 +0200, Mauro Carvalho Chehab wrote:
>>> Em Fri, 25 Jun 2021 18:22:26 +0900
>>> Akira Yokosawa <akiyks@gmail.com> escreveu:
>>>   
>>>> On Fri, 25 Jun 2021 09:50:59 +0200, Mauro Carvalho Chehab wrote:  
>> [...]
>>>>
>>>> One minor problem might be that the Sarasa font needs manual
>>>> download (and install).
>>>>
>>>>         Thanks, Akira  
>>>
>>> If this is not yet packaged as part of texlive packages
>>> on distros, this won't be a minor issue, as we'll need
>>> to find procedures and test it for all distros supported
>>> by the script.  
>>
>> Existence of "Sarasa Mono SC" can be checked by the command:
>>
>>     fc-list | grep "Sarasa Mono SC," | grep "style=Regular" | wc -l
>>
>> If the result is *not* "0", you have the font somewhere in your
>> fontconfig path.
>>
>> I think this is portable across distros.
>> Wouldn't this suffice for sphinx-pre-install?
> 
> No. The sphinx-pre-install tool generate a list of commands
> needed to install the pre-reqs on a given distro.
> 
> For instance, if you run on opensuse without texlive, it would
> print:
> 
> 
> 	# ./scripts/sphinx-pre-install 
> 	Detected OS: openSUSE Tumbleweed 20210515.
> 	Sphinx version: 3.5.4
> 
> 	Warning: better to also install "latexmk".
> ...
> 	Warning: better to also install "xelatex".
> 	You should run:
> 
> 	sudo zypper install --no-recommends texlive-latexmk-bin texlive-amscls texlive-amsfonts texlive-amsmath texlive-anyfontsize texlive-babel-english texlive-capt-of texlive-caption texlive-cmap texlive-colortbl texlive-courier texlive-dvips texlive-ec texlive-eqparbox texlive-euenc texlive-fancybox texlive-fancyvrb texlive-float texlive-fncychap texlive-framed texlive-helvetic texlive-luatex85 texlive-makeindex texlive-mdwtools texlive-metafont texlive-metapost texlive-multirow texlive-needspace texlive-oberdiek texlive-palatino texlive-parskip texlive-polyglossia texlive-preview texlive-psnfss texlive-tabulary texlive-threeparttable texlive-times texlive-titlesec texlive-tools texlive-ucs texlive-upquote texlive-wrapfig texlive-zapfchan texlive-zapfding texlive-xetex-bin
> 
> The same command, when executed on a different distro will
> print a different set of packages and commands.

I see...

So let's forget Unifont and "Sarasa Mono" for the time being.

By adding some custom configuration of fontconfig, "Noto Sans Mono
CJK SC" can be made an alias of "Sarasa Mono", "Unifont", or whatever
alternative font one wants to try.

An alternative *true* monospace font is just a nice-to-have for
those who concern PDF of Korean translation, and as I have said
earlier, it has another major issue of white spaces being ignored
by xeCJK.

I'll do a v2 along this line.

        Thanks, Akira

> 
> Thanks,
> Mauro
>