kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Am 22.03.19 um 19:52 schrieb Eugene Kilachkoff:
>> I'm just convinced if it turn out it is really a CMake issue.
> 
> Well.. it is.

Urgs, o.k.
But congratulation you have found it!

> I attached the patch that should fix this. Anyone here cares to
> commit?
Unfortunately the workflow for accepting patches is only targeted for
using the GitHub way (at least this is my impression). Technically it's
no real work to apply your patch locally, commit this with you as author
and push it then ...

If nobody will pick it up I will at least use it in the Debian packaging
tree.

> As I assumed, the DBLATEX_OPTIONS is in the same scope for different
> macro invocations, so it is not reset and keeps the old value. There
> were simply no way current implementation could have worked properly.

Logic isn't always easy, especially if there are multiple iterations do
happen with different variables. :)
CMake isn't here better than the autotools and you will need to work a
lot with debug output.

>> On the other hand asciidoc is Python2 and has some nasty downsides, as
>> seen with the Japanese characters that are not correctly parsed.
> 
> At the level of maturity asciidoc has, it is quite hard to believe there
> will still be errors in national charset handling. Moreover, our current
> problems are further down the pipeline. Specifically, in dblatex which
> we feed incorrect settings through incorrect style applied.

But some of the UTF8 characters are not correctly parsed by asciidoc,
not by dblatex. The problem is simply the constrains that the Pyrhon2 re
classes have here! If there is going something wrong there is no chance
this can be fixed later.

> Even more than that, problem does not reproduce if you build ONLY the
> Polish document. However, it does appear when we MIX Japanese styles
> with Polish document, and WHY these artifacts are getting mixed is the
> question that should've been asked.
> 
> In any case, the fix is here, and the rest is of historical interest only.
> 
> 
>> The days of Python2 are mostly gone. You will need to move over to
>> Python3 or some other language. $(someone) just needs to start this.
> 
> Do you really believe that switching into "better" language will
> magically get rid of bugs?

Again, these are two various problem we have discussed and figured out
now. One is the restriction that asciidoc isn't able to parse strings
correctly which containing some UTF-8 chracters and the other problems
was the wrong logic within the CMakeList file. The latter is now
hopefully fixed.

The former might likely work smarter with some other implementation
which needs to be evaluated. As for every Python2 script, the time is
working against.

-- 
Regards
Carsten Schoenert