From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B399C433ED for ; Sun, 16 May 2021 11:14:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2055E61168 for ; Sun, 16 May 2021 11:14:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230062AbhEPLPP (ORCPT ); Sun, 16 May 2021 07:15:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:56138 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230001AbhEPLPP (ORCPT ); Sun, 16 May 2021 07:15:15 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id E649161164; Sun, 16 May 2021 11:13:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621163640; bh=bxIW72OBGlUVbKXIO28RbGD+VrGPRvwYLITR6ZFMjjU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kvkSsjUwYa1V714tMzdnqN6zgVoaNNC3jZaMjlQG4uoFAbITDWPw75pi5xgdRVG5p EKGaPZN4o3OFFkM4VeLebdU562quM996k1R5RbJldOVSmVLDORld5n18OrZh5G+xeo yquBoE7haM25TjstGcjy4b8Lj5JYW6jv6TAMENd4C3Vs/k2Do4V1xFhB+PrLVpwd+z sqpTahBXZs2VAOK/x9j6YKkGaMk8TrwOPZ2sucI3BsFmSaA2OXU7x/0f6FMy3triBY cwv8At9hogUYBCk/UuJAzkat5N6P3UXWGBNJeruA5WhLWZ3Wq+hXLK3FDFfbLJEpxT FvNvTNbVrW1Lw== Date: Sun, 16 May 2021 13:13:55 +0200 From: Mauro Carvalho Chehab To: Thorsten Leemhuis Cc: Linux Doc Mailing List , Jonathan Corbet , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 02/16] docs: admin-guide: reporting-issues.rst: replace some characters Message-ID: <20210516131355.30c73b7d@coco.lan> In-Reply-To: References: <5625907ed95964321c39a8688b70c54bac6d8e95.1621159997.git.mchehab+huawei@kernel.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Em Sun, 16 May 2021 12:28:06 +0200 Thorsten Leemhuis escreveu: > Lo! On one hand I think it would be good to fix the tools to make them > understand non-breakable spaces in places where the author chose to use > them, Fixing it is not trivial ;-) See, while DocBook, LaTeX and other similar tools allow the author to specify exactly how the output will be produced, Markup languages=20 are not meant to give full control to the author, but, instead, to make their work easier by letting the toolset to take decisions about line breaks, font type and size, etc. In the specific case of Sphinx, the main tool parses the ReST files, and an output module is responsible to generate the actual output. So, there's one module for LaTeX, another one for HTML and a third party one for PDF (we currently don't use the last one). It is the output module that will actually decide to do line breaks and to honor the document margins and to add non-breakable spaces when needed. When the output is a web page, it shouldn't be a problem to use unbreakable spaces, provided that the output module is smart enough to detect it, adding an horizontal scroll bar if needed to avoid long lines to be simply truncated if the window is smaller than the lines. For e-pub, LaTeX and PDF, though, unbreakable spaces should be replaced by normal ones if the string is too long, or the lines will simply be truncated, with text loses. So, while it could be possible to use such characters, extra care should be taken, as all output formats need to be tested. Also, as Kernel patches and toolset improvements could change, for instance, the used font, or a change somewhere could lead into a different column width, such the tests need to be repeated from time to time and with different Sphinx versions. So, this ends by being a maintenance nightmare. Better to live without those ;-) > but whatever, their use in that sentence is definitely not > important, so feel free to add: >=20 > Acked-by: Thorsten Leemhuis >=20 > Thanks for working on this. Ciao, Thorsten Thanks! Mauro >=20 > On 16.05.21 12:18, Mauro Carvalho Chehab wrote: > > The conversion tools used during DocBook/LaTeX/html/Markdown->ReST > > conversion and some cut-and-pasted text contain some characters that > > aren't easily reachable on standard keyboards and/or could cause > > troubles when parsed by the documentation build system. > >=20 > > Replace the occurences of the following characters: > >=20 > > - U+00a0 ('=C2=A0'): NO-BREAK SPACE > > as it can cause lines being truncated on PDF output > >=20 > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/admin-guide/reporting-issues.rst | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > >=20 > > diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documenta= tion/admin-guide/reporting-issues.rst > > index 18d8e25ba9df..d7ac13f789cc 100644 > > --- a/Documentation/admin-guide/reporting-issues.rst > > +++ b/Documentation/admin-guide/reporting-issues.rst > > @@ -1248,7 +1248,7 @@ paragraph makes the severeness obvious. > > =20 > > In case you performed a successful bisection, use the title of the cha= nge that > > introduced the regression as the second part of your subject. Make the= report > > -also mention the commit=C2=A0id of the culprit. In case of an unsucces= sful bisection, > > +also mention the commit id of the culprit. In case of an unsuccessful = bisection, > > make your report mention the latest tested version that's working fine= (say 5.7) > > and the oldest where the issue occurs (say 5.8-rc1). > > =20 > > =20 Thanks, Mauro