kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Ping!

Anyone here to take care of this patch so it will make it's way into the
tree? Nothing did happen since Eugene has posted his patch ...

I'm really sad about the bit rotting of provided patches, it's
frustrating and demotivating!

Am 22.03.19 um 19:52 schrieb Eugene Kilachkoff:
> On 3/22/19 12:57 AM, Carsten Schoenert wrote:
>>> Why you keep saying this is an asciidoc problem? To me it is cmake
>>> generating wrong build scripts....
>>
>> I'm just convinced if it turn out it is really a CMake issue.
> 
> Well.. it is. I attached the patch that should fix this. Anyone here
> cares to commit?
> 
> 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.
> 
> 
>> 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.
> 
> 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?

-- 
Regards
Carsten Schoenert