Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Feb 2021 15:16:20 +0100
From:      Daniel Ebdrup Jensen <debdrup@FreeBSD.org>
To:        freebsd-doc@freebsd.org
Subject:   Re: Regarding AsciiDoctor and long lines
Message-ID:  <20210216141620.k4rwqtvwfnhk7xty@nerd-thinkpad.local>
In-Reply-To: <CAOa83AcBASoD=tOxx6xtAwtf5Wz7XeTm3qacBpM9dxYvX7C0LQ@mail.gmail.com>
References:  <c7d36625-0688-9ebb-de03-0e9b5eb55a82@freebsd.org> <20210210160348.xfy3un6bx5u7cqvj@nerd-thinkpad.local> <YCZ4TedB5G1sI8L1@emphyrio.blackend.org> <CAFwocyOYepw%2BntThzGp8ZNKQrPHm9bzgK60_fpfu1BZ5v39y9Q@mail.gmail.com> <20210212170859.lzzj5qrriovjd2ux@nerd-thinkpad.local> <CAFwocyOdSqnVUcRgUhiecXvG2qGasnL2VU0JugwEVc-WuvJxOg@mail.gmail.com> <CAFwocyOBLW0Siwtk0A%2BQox_MQt4KqCnMvHa_1s23RmjqqmLUkw@mail.gmail.com> <YCq31UMUj8DH2En3@emphyrio.blackend.org> <20210216074810.qwaotlonqdaulvk2@nerd-thinkpad.local> <CAOa83AcBASoD=tOxx6xtAwtf5Wz7XeTm3qacBpM9dxYvX7C0LQ@mail.gmail.com>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Tue, Feb 16, 2021 at 01:01:45PM +0000, Ceri Davies wrote:
>On Tue, 16 Feb 2021 at 07:48, Daniel Ebdrup Jensen <debdrup@freebsd.org>
>wrote:
>
>> On Mon, Feb 15, 2021 at 07:05:09PM +0100, Marc Fonvieille wrote:
>> >Le 12.02.2021 18:24, Sergio Carlavilla a écrit :
>> >>
>> >> I think the doceng team should pronounce about this.
>> >>
>> >> IMHO, use the 72 characters per line would be a problem in the future.
>> >>
>> >
>> >Why it would be a problem?
>> >
>> >--
>> >Marc
>>
>> Hi folks,
>>
>> Can we make a compromise where real paragraphs, ie. the only things
>> which don't seem to need much in the way of AsciiDoctor markup, are kept
>> at 72 columns, and headings, lists, images, include macros, variables
>> and custom macros are allowed to go beyond the 72 columns?
>> If they have to, there's always word-smithing options for trying to be
>> as concise as possible (without, of course, making things too obtuse -
>> it's a tough balance, admittedly?
>>
>> That seemed to work for DocBook, so is there a reason it won't work
>> here?
>>
>
>  For HTML output it doesn't look like it's an issue; although whitespace
>is preserved in the output, it's luckily irrelevant to HTML output.
>
>For other output formats such as PDF or mdoc then I can see that it is
>problematic to hard wrap text but that suggests that there's a tooling
>issue; Marc's need to be able to actually see what has changed is really
>important.
>
>Butting out for another 9 years now :D
>
>Ceri

I don't see how mdoc would be impacted, since that lives in the src 
repo.

As for pdf files, I couldn't tell you the last time I used the handbook 
in a pdf format, so I had to generate it by grabbing asciidoctor-pdf 
and running it on doc/documentation/content/en/books/handbook/book.adoc - 
and it produced [1].

Aside from things which I think can be addressed separately, the change 
I made in order to test the theories that pdf should work with extra 
linebreaks inserted at 72 columns, is on page 21, on the paragraph 
"The hardware requirements to install FreeBSD vary by.."

To me, this looks exactly like how I would expect it to look.
So I think we'll be fine with this change, at least for newlines as it 
relates to paragraphs.

Yours,
Daniel Ebdrup Jensen

[1]: https://people.freebsd.org/~debdrup/book.pdf

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----

iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmAr07RfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF
ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN
87oLfAf8CIjU2yDRT9Cck/ShiTpobO2RvDPri9ZzTjq7JfoFUQLCEdf/9q8JxtLI
8gT6zY9EpSOCWlfFhO5I1zDE0Y8dDcnwrq/+qTbK+ah2Pw3AI+E7TZ5Tv8RAKgpg
HEzIg8PSn7pAGpw4l3AoLSW3Hzs7YY7uOsf14vSDHX9D+qHbkC5cW4k53shcWwsd
FkBdEgUqTAQtIWF9ftN8f8H8qFiOYOAa4BOgr4yUzGLhNoVgyw7Jo5lZHIxnt0f6
NE1jpiwLj3EsxXKyoMCqAcNz0ptZUBrJp0g35FE19Jxtr3AlBZ1SioSFGU01sPbr
NkRze/R9MfMdS13AXO2PGLsxAi7gXA==
=21Kj
-----END PGP SIGNATURE-----
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210216141620.k4rwqtvwfnhk7xty>