kicad-doc-devs team mailing list archive

[Marco Ciampa <ciampix@xxxxxxxxxx>]

On Sat, Aug 04, 2018 at 06:16:03PM +0800, Carsten Schoenert wrote:
> Hi again,
> 
> Am 20.05.18 um 04:17 schrieb Carsten Schoenert:
> ...
> >>>  898 \item{} キーボード（ファンクションキー \texttt{F1}, \texttt{F2}, \texttt{F3}, \texttt{F4}, \texttt{Shift}, \texttt{Delete}, \texttt{+}, \texttt{-{}}, \texttt{Page
> >>>  899   Up}, \texttt{Page Down} 及び \texttt{スペース バー\`{}）。\`{}エスケープ} キーは、一般的に進行中の操作を取り消します。
> >>>  900                                                    ^^     ^^
> >>
> >> This looks indeed not correct as the two curly brackets in line 899 are
> >> empty and shouldn't be here.
> > 
> > As this issue will unfortunately stay for a while I will drop the origin
> > of this problem from the Japanese po file temporary to get a new package
> > upload into Debian prepared. I really don't like this but without this I
> > will miss the possibility to get 5.0.0RC2 into Debian testing.
> > 
> > If there will be a KiCad 5 RC2 in the next days I will happily use this
> > tagged version, otherwise I'll take a current snapshot for getting a new
> > version into Debian unstable/testing.
> 
> thanks to Norbert Preining, the current maintainer of the texlive
> packages within Debian, we figured out why the build is currently
> failing with recent texlive versions in Debian unstable and sid.
> 
> The real problem isn't texlive in our opinion after a few hours of
> debugging, texlive is now just a bit more picky about some input strings
> and I see the broken build later. We first was thinking about xcjk or
> xecjk as the root of the issues. By using some simple tex examples we
> couldn't reproduce the issue again so we went to the toolchain that is
> working in kicad-doc.
> 
> So we came to dblatex which is running a2x, xsltproc ans asciidoc and
> checked the tools from the end to the beginning, and, well ... we
> unfortunately need to go back the the complete road to the beginning at
> asciidoc which is generating the xml file which is used later by most of
> the tools.
> 
> And it points finally out that asciidoc is the problem!
> 
> asciidoc is a Python2 script which doesn't know anything about UTF8
> string and by this the recompile is simply going wrong for Japanese in
> pcbnew.adoc.
> This might be fixed by improved the regexp, I've no idea if this
> possible as I have just a poor understanding about this.
> 
> So we made just a small change to workaround the build issue within the
> Japanese po file and Norbert mentioned this is currently the best way to
> get it working. He's living for many years in Japan and I trust his
> knowledge.
> 
> So the change is trivial, we just added space characters and the build
> is succesful.
> 
> > $ git diff
> > diff --git a/src/pcbnew/po/ja.po b/src/pcbnew/po/ja.po
> > index 60cc711f..b61d9a7b 100644
> > --- a/src/pcbnew/po/ja.po
> > +++ b/src/pcbnew/po/ja.po
> > @@ -5745,7 +5745,7 @@ msgid ""
> >  "an operation in progress."
> >  msgstr ""
> >  "キーボード（ファンクションキー `F1`, `F2`, `F3`, `F4`, `Shift`, `Delete`, `"
> > -"+`, `-`, `Page Up`, `Page Down` 及び `スペース バー`）。`エスケープ` キーは、"
> > +"+`, `-`, `Page Up`, `Page Down` 及び `スペース バー` ）。 `エスケープ` キーは、"
> >  "一般的に進行中の操作を取り消します。"
> >  
> >  #. type: Plain text
> 
> The reason is the recompile regexp within asciidoc is a bit to stupid to
> detect the backticks signs are needed in the original string and is
> breaking the original string into multiple parts which fails later due
> missing controlling escaping character.

Good catch!
Did you post the bug report to the asciidoc developers ml already?

Hopefully one of these days we will migrate from python asciidoc to the
way better ruby ascidoctor...

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.

------------------------

 GNU/Linux User #78271
 FSFE fellow #364

------------------------