linux-kernel - Re: [PATCH RFC 0/4] Fix PDF build errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1F43ABDB-381F-4AC8-8A72-AD0FCBE96DE0@darmarit.de>
Date:   Wed, 2 Nov 2016 18:07:44 +0100
From:   Markus Heiser <markus.heiser@...marit.de>
To:     Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Jonathan Corbet <corbet@....net>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Jim Davis <jim.epost@...il.com>,
        linux-kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC 0/4] Fix PDF build errors


Am 02.11.2016 um 17:47 schrieb Mauro Carvalho Chehab <mchehab@...radead.org>:

> Em Wed, 2 Nov 2016 17:08:08 +0100
> Markus Heiser <markus.heiser@...marit.de> escreveu:
> 
>> Am 02.11.2016 um 12:14 schrieb Jani Nikula <jani.nikula@...ux.intel.com>:
>> 
>>> On Wed, 02 Nov 2016, Mauro Carvalho Chehab <mchehab@....samsung.com> wrote:  
>>>> This series address a series of errors during PDF generation from
>>>> media documentation.
>>>> 
>>>> Please notice that patch 2 carries on a PDF conversion from a PNG
>>>> image, because Sphinx is not smart enough to do the convertion.
>>>> 
>>>> This is a temporary solution (That's why I'm marking this series
>>>> as RFC).  
>>> 
>>> This seems to work on top of docs-next.
>>> 
>>> ...but it'll break again if we include the missing admin-guide in the
>>> build. :(
>>> Sadly, this breaks the pdf build with:
>>> 
>>> ! TeX capacity exceeded, sorry [main memory size=5000000].
>>> \FV@...ce ...ionary {\copy \sphinxvisiblespacebox
>>> }{\sphinxafterbreak } {\ke...
>>> l.3711 ...\PYG{n}{be} \PYG{n}{used} \PYG{n+nb}{to}
>>> or 2  
>> 
>> 
>> This is the verbatim block of the kernel parameters with more
>> than 4300 lines in.
>> 
>> IMO, Verbatim exceeded, because in sphinx.sty is a redefinition
>> of the LaTeX Verbatim command which might be sloppy / see 
>> sphinx.sty::
>> 
>> \renewcommand{\Verbatim}[1][1]{%
>>   ....
> 
> Argh! I really hate those ugly hacks that Sphinx do for LaTeX output...
> 
> Btw, I remember I had to touch on a TeXLive style in order to workaround
> the memory size when testing LaTeX output for some book, but it ended by
> causing some other issues.
> 
>> 
>> The renew-Verbatim has been removed later:
>> 
>> https://github.com/sphinx-doc/sphinx/commit/f9880bfcc8b19a7d197badeb6ab412abfca19891
>> 
>> I my POC I use such a modified sphinx.sty
>> 
>> https://github.com/return42/sphkerneldoc/blob/master/_tex/sphinx.sty
>> 
>> with it, the PDF is build:
>> 
>> https://h2626237.stratoserver.net/kernel/books/admin-guide/pdf/linux-user.pdf
>> 
>> Using modified sphinx.sty has the drawback, that it is not
>> up- or downward compatible to the installed Sphinx version.
>> 
>> So in short, I think it is the best to come back to the reasons
>> and just split kernel parameters in several blocks and using the 
>> 'none' option to prevent rendering as C .. E.g:
>> 
>> .. code-block:: none
> 
> I'm staring to think that we should just redefine the default for ::
> to be "none", and use the "C" handling **only** when explicitly
> requested.
> 
> I remember that Jon did such suggestion sometime ago.

*shrug* ... I think about kernel-doc comments in the sources,
mostly you will have small examples and won't those verbose 
".. code-block::" markup / using "::" keeps the comment compact.

> 
> If we change it to "none", it will still spend lots of memory for
> verbatim?

Yes .. we need to split kernel parameter's into smaller verbatime
blocks.