Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756081AbcKBQrk (ORCPT ); Wed, 2 Nov 2016 12:47:40 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:51601 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbcKBQri (ORCPT ); Wed, 2 Nov 2016 12:47:38 -0400 Date: Wed, 2 Nov 2016 10:47:34 -0600 From: Mauro Carvalho Chehab To: Markus Heiser Cc: Jani Nikula , Jonathan Corbet , Mauro Carvalho Chehab , Linux Doc Mailing List , Jim Davis , linux-kernel List Subject: Re: [PATCH RFC 0/4] Fix PDF build errors Message-ID: <20161102104734.5c3b977e@vela.lan> In-Reply-To: References: <87lgx2jfq0.fsf@intel.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2533 Lines: 78 Em Wed, 2 Nov 2016 17:08:08 +0100 Markus Heiser escreveu: > Am 02.11.2016 um 12:14 schrieb Jani Nikula : > > > On Wed, 02 Nov 2016, Mauro Carvalho Chehab 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@Space ...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. If we change it to "none", it will still spend lots of memory for verbatim? Cheers, Mauro