| Message ID | 20240106214955.1558448-1-marth64@proxyid.net |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] Revert "doc/faq: replace non-breaking spaces (0xA0) with normal space" | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote: > This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264. > > A valid point was made, that the non-breaking space will cause this text > to render better by ensuring the unit never seperates from the number. I'm not convinced the non-breaking space was a good idea in the first place, the fact that there is a single instance in the whole documentation confirms this. In fact even if the unit and value are not on the same line we don't miss much in terms of readability. On the other hand it is very hard to edit such non-printable characters, and you can bet what as much as you can that most contributors will not get it right or consistent. > Signed-off-by: Marth64 <marth64@proxyid.net> > --- > doc/faq.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/faq.texi b/doc/faq.texi > index 5998e0d000..39f28eef08 100644 > --- a/doc/faq.texi > +++ b/doc/faq.texi > @@ -450,7 +450,7 @@ work with streams that were detected during the initial scan; streams that > are detected later are ignored. > > The size of the initial scan is controlled by two options: @code{probesize} > -(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For > +(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For > the subtitle stream to be detected, both values must be large enough. > > @section Why was the @command{ffmpeg} @option{-sameq} option removed? What to use instead? > -- > 2.34.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Am 07.01.24 um 13:12 schrieb Stefano Sabatini: > On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote: >> This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264. >> >> A valid point was made, that the non-breaking space will cause this text >> to render better by ensuring the unit never seperates from the number. > > I'm not convinced the non-breaking space was a good idea in the first > place, the fact that there is a single instance in the whole > documentation confirms this. > > In fact even if the unit and value are not on the same line we don't > miss much in terms of readability. > > On the other hand it is very hard to edit such non-printable > characters, and you can bet what as much as you can that most > contributors will not get it right or consistent. I think we could use @tie{} instead of an invisible 0xA0 wherever we want non-breaking spaces. Even if we seem not to care much about these in the docs. -Thilo
On date Sunday 2024-01-07 14:16:23 +0100, ffmpeg-devel Mailing List wrote: > Am 07.01.24 um 13:12 schrieb Stefano Sabatini: > > On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote: > > > This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264. > > > > > > A valid point was made, that the non-breaking space will cause this text > > > to render better by ensuring the unit never seperates from the number. > > > > I'm not convinced the non-breaking space was a good idea in the first > > place, the fact that there is a single instance in the whole > > documentation confirms this. > > > > In fact even if the unit and value are not on the same line we don't > > miss much in terms of readability. > > > > On the other hand it is very hard to edit such non-printable > > characters, and you can bet as much as you can that most > > contributors will not get it right or consistent. > > I think we could use @tie{} instead of an invisible 0xA0 wherever we want non-breaking spaces. +1, this would be better than 0xA0. > Even if we seem not to care much about these in the docs.
On Sun, 7 Jan 2024, Stefano Sabatini wrote: > On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote: >> This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264. >> >> A valid point was made, that the non-breaking space will cause this text >> to render better by ensuring the unit never seperates from the number. > > I'm not convinced the non-breaking space was a good idea in the first > place, the fact that there is a single instance in the whole > documentation confirms this. > > In fact even if the unit and value are not on the same line we don't > miss much in terms of readability. > > On the other hand it is very hard to edit such non-printable > characters, and you can bet what as much as you can that most > contributors will not get it right or consistent. Hard to edit how? It is not like we are in the 80s using ASCII charset and editors with 80x25 text console to edit the files... The whole topic is kind of bikesheddy, so I don't really mind either way, I just don't see the benefit of using @tie{} or whatever instead of proper utf8 chars any half decent editor would support. Regards, Marton
On 1/7/2024 3:46 PM, Marton Balint wrote: > > > On Sun, 7 Jan 2024, Stefano Sabatini wrote: > >> On date Saturday 2024-01-06 15:49:56 -0600, Marth64 wrote: >>> This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264. >>> >>> A valid point was made, that the non-breaking space will cause this text >>> to render better by ensuring the unit never seperates from the number. >> >> I'm not convinced the non-breaking space was a good idea in the first >> place, the fact that there is a single instance in the whole >> documentation confirms this. >> >> In fact even if the unit and value are not on the same line we don't >> miss much in terms of readability. >> >> On the other hand it is very hard to edit such non-printable >> characters, and you can bet what as much as you can that most >> contributors will not get it right or consistent. > > Hard to edit how? It is not like we are in the 80s using ASCII charset > and editors with 80x25 text console to edit the files... > > The whole topic is kind of bikesheddy, so I don't really mind either > way, I just don't see the benefit of using @tie{} or whatever instead of > proper utf8 chars any half decent editor would support. 0xA0 is invisible in .texi files if you use a text editor that supports it, whereas @tie{} obviously isn't. The latter clearly conveys the intention (no splitting) for the reader with a quick glance, and it probably is the preferred method for the interpreter to handle this, so IMO it's better.
diff --git a/doc/faq.texi b/doc/faq.texi index 5998e0d000..39f28eef08 100644 --- a/doc/faq.texi +++ b/doc/faq.texi @@ -450,7 +450,7 @@ work with streams that were detected during the initial scan; streams that are detected later are ignored. The size of the initial scan is controlled by two options: @code{probesize} -(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For +(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For the subtitle stream to be detected, both values must be large enough. @section Why was the @command{ffmpeg} @option{-sameq} option removed? What to use instead?
This reverts commit 6442d1ddd62160e96c686c30648b6111e3e0c264. A valid point was made, that the non-breaking space will cause this text to render better by ensuring the unit never seperates from the number. Signed-off-by: Marth64 <marth64@proxyid.net> --- doc/faq.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)