From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Michael Tretter <m.tretter@pengutronix.de>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Stanimir Varbanov <stanimir.varbanov@linaro.org>,
Tomasz Figa <tfiga@chromium.org>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: [PATCH v2 15/40] docs: userspace-api: media: v4l: Use ASCII subset instead of UTF-8 alternate symbols
Date: Wed, 12 May 2021 14:50:19 +0200 [thread overview]
Message-ID: <9b48ff68615727c517df824af6a5b8f9edf55622.1620823573.git.mchehab+huawei@kernel.org> (raw)
In-Reply-To: <cover.1620823573.git.mchehab+huawei@kernel.org>
The conversion tools used during DocBook/LaTeX/Markdown->ReST conversion
and some automatic rules which exists on certain text editors like
LibreOffice turned ASCII characters into some UTF-8 alternatives that
are better displayed on html and PDF.
While it is OK to use UTF-8 characters in Linux, it is better to
use the ASCII subset instead of using an UTF-8 equivalent character
as it makes life easier for tools like grep, and are easier to edit
with the some commonly used text/source code editors.
Also, Sphinx already do such conversion automatically outside literal blocks:
https://docutils.sourceforge.io/docs/user/smartquotes.html
So, replace the occurences of the following UTF-8 characters:
- U+00a0 (' '): NO-BREAK SPACE
- U+00d7 ('×'): MULTIPLICATION SIGN
- U+2019 ('’'): RIGHT SINGLE QUOTATION MARK
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
Documentation/userspace-api/media/v4l/crop.rst | 16 ++++++++--------
.../userspace-api/media/v4l/dev-decoder.rst | 6 +++---
.../userspace-api/media/v4l/diff-v4l.rst | 2 +-
Documentation/userspace-api/media/v4l/open.rst | 2 +-
.../userspace-api/media/v4l/vidioc-cropcap.rst | 4 ++--
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/crop.rst b/Documentation/userspace-api/media/v4l/crop.rst
index 3fe185e25ccf..23c2b71f449e 100644
--- a/Documentation/userspace-api/media/v4l/crop.rst
+++ b/Documentation/userspace-api/media/v4l/crop.rst
@@ -130,22 +130,22 @@ the driver state and therefore only adjust the requested rectangle.
Suppose scaling on a video capture device is restricted to a factor 1:1
or 2:1 in either direction and the target image size must be a multiple
-of 16 × 16 pixels. The source cropping rectangle is set to defaults,
-which are also the upper limit in this example, of 640 × 400 pixels at
-offset 0, 0. An application requests an image size of 300 × 225 pixels,
+of 16 x 16 pixels. The source cropping rectangle is set to defaults,
+which are also the upper limit in this example, of 640 x 400 pixels at
+offset 0, 0. An application requests an image size of 300 x 225 pixels,
assuming video will be scaled down from the "full picture" accordingly.
-The driver sets the image size to the closest possible values 304 × 224,
+The driver sets the image size to the closest possible values 304 x 224,
then chooses the cropping rectangle closest to the requested size, that
-is 608 × 224 (224 × 2:1 would exceed the limit 400). The offset 0, 0 is
+is 608 x 224 (224 x 2:1 would exceed the limit 400). The offset 0, 0 is
still valid, thus unmodified. Given the default cropping rectangle
reported by :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>` the application can
easily propose another offset to center the cropping rectangle.
Now the application may insist on covering an area using a picture
aspect ratio closer to the original request, so it asks for a cropping
-rectangle of 608 × 456 pixels. The present scaling factors limit
-cropping to 640 × 384, so the driver returns the cropping size 608 × 384
-and adjusts the image size to closest possible 304 × 192.
+rectangle of 608 x 456 pixels. The present scaling factors limit
+cropping to 640 x 384, so the driver returns the cropping size 608 x 384
+and adjusts the image size to closest possible 304 x 192.
Examples
diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst
index 3d4138a4ba69..5b9b83feeceb 100644
--- a/Documentation/userspace-api/media/v4l/dev-decoder.rst
+++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst
@@ -38,7 +38,7 @@ Conventions and Notations Used in This Document
6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
[0..2]: i = 0, 1, 2.
-7. Given an ``OUTPUT`` buffer A, then A’ represents a buffer on the ``CAPTURE``
+7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE``
queue containing data that resulted from processing buffer A.
.. _decoder-glossary:
@@ -288,7 +288,7 @@ Initialization
Changing the ``OUTPUT`` format may change the currently set ``CAPTURE``
format. How the new ``CAPTURE`` format is determined is up to the decoder
- and the client must ensure it matches its needs afterwards.
+ and the client must ensure it matches its needs afterwards.
2. Allocate source (bytestream) buffers via :c:func:`VIDIOC_REQBUFS` on
``OUTPUT``.
@@ -874,7 +874,7 @@ it may be affected as per normal decoder operation.
any of the following results on the ``CAPTURE`` queue is allowed:
- {A’, B’, G’, H’}, {A’, G’, H’}, {G’, H’}.
+ {A', B', G', H'}, {A', G', H'}, {G', H'}.
To determine the CAPTURE buffer containing the first decoded frame after the
seek, the client may observe the timestamps to match the CAPTURE and OUTPUT
diff --git a/Documentation/userspace-api/media/v4l/diff-v4l.rst b/Documentation/userspace-api/media/v4l/diff-v4l.rst
index 33243ecb5033..9ce60e625974 100644
--- a/Documentation/userspace-api/media/v4l/diff-v4l.rst
+++ b/Documentation/userspace-api/media/v4l/diff-v4l.rst
@@ -447,7 +447,7 @@ name ``V4L2_FBUF_FLAG_CHROMAKEY``.
In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
-size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
+size bitmap of 1024 x 625 bits. Struct :c:type:`v4l2_window`
has a separate ``bitmap`` pointer field for this purpose and the bitmap
size is determined by ``w.width`` and ``w.height``.
diff --git a/Documentation/userspace-api/media/v4l/open.rst b/Documentation/userspace-api/media/v4l/open.rst
index 18bfb9b8137d..b015bbbdf8b5 100644
--- a/Documentation/userspace-api/media/v4l/open.rst
+++ b/Documentation/userspace-api/media/v4l/open.rst
@@ -100,7 +100,7 @@ Where ``X`` is a non-negative integer.
$ tree /dev/v4l
/dev/v4l
├── by-id
- │ └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0
+ │ └── usb-OmniVision._USB_Camera-B4.04.27.1-video-index0 -> ../../video0
└── by-path
└── pci-0000:00:14.0-usb-0:2:1.0-video-index0 -> ../../video0
diff --git a/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst b/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst
index 551ac9d3c6ef..4ea652e66401 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-cropcap.rst
@@ -69,8 +69,8 @@ overlay devices.
* - struct :ref:`v4l2_rect <v4l2-rect-crop>`
- ``defrect``
- Default cropping rectangle, it shall cover the "whole picture".
- Assuming pixel aspect 1/1 this could be for example a 640 × 480
- rectangle for NTSC, a 768 × 576 rectangle for PAL and SECAM
+ Assuming pixel aspect 1/1 this could be for example a 640 x 480
+ rectangle for NTSC, a 768 x 576 rectangle for PAL and SECAM
centered over the active picture area. The same co-ordinate system
as for ``bounds`` is used.
* - struct :c:type:`v4l2_fract`
--
2.30.2
next prev parent reply other threads:[~2021-05-12 12:53 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 12:50 [PATCH v2 00/40] Use ASCII subset instead of UTF-8 alternate symbols Mauro Carvalho Chehab
2021-05-12 12:50 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-12 12:50 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 01/40] docs: hwmon: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 02/40] docs: admin-guide: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 03/40] docs: admin-guide: media: ipu3.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 04/40] docs: admin-guide: perf: imx-ddr.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 05/40] docs: admin-guide: pm: " Mauro Carvalho Chehab
2021-05-12 13:53 ` Rafael J. Wysocki
2021-05-12 12:50 ` [PATCH v2 06/40] docs: trace: coresight: coresight-etm4x-reference.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 07/40] docs: driver-api: ioctl.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 08/40] docs: driver-api: thermal: " Mauro Carvalho Chehab
2021-06-12 19:08 ` Daniel Lezcano
2021-05-12 12:50 ` [PATCH v2 09/40] docs: driver-api: media: drivers: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 10/40] docs: driver-api: firmware: other_interfaces.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 11/40] docs: fault-injection: nvme-fault-injection.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 12/40] docs: usb: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 13/40] docs: process: code-of-conduct.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 14/40] docs: userspace-api: media: fdl-appendix.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab [this message]
2021-05-12 12:50 ` [PATCH v2 16/40] docs: userspace-api: media: dvb: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 17/40] docs: vm: zswap.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 18/40] docs: filesystems: f2fs.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 19/40] docs: filesystems: ext4: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 20/40] docs: kernel-hacking: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 21/40] docs: hid: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 22/40] docs: security: tpm: tpm_event_log.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 23/40] docs: security: keys: trusted-encrypted.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 24/40] docs: networking: scaling.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 25/40] docs: networking: devlink: devlink-dpipe.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 26/40] docs: networking: device_drivers: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 27/40] docs: x86: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 28/40] docs: scheduler: sched-deadline.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 29/40] docs: power: powercap: powercap.rst: " Mauro Carvalho Chehab
2021-05-12 13:54 ` Rafael J. Wysocki
2021-05-12 12:50 ` [PATCH v2 30/40] docs: ABI: " Mauro Carvalho Chehab
2021-05-12 13:49 ` Sudeep Holla
2021-05-12 12:50 ` [PATCH v2 31/40] docs: PCI: acpi-info.rst: " Mauro Carvalho Chehab
2021-05-12 21:29 ` Bjorn Helgaas
2021-05-12 12:50 ` [PATCH v2 32/40] docs: gpu: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 33/40] docs: sound: kernel-api: writing-an-alsa-driver.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 34/40] docs: arm64: arm-acpi.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 35/40] docs: infiniband: tag_matching.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 36/40] docs: misc-devices: ibmvmc.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 37/40] docs: firmware-guide: acpi: lpit.rst: " Mauro Carvalho Chehab
2021-05-12 13:46 ` Rafael J. Wysocki
2021-05-12 12:50 ` [PATCH v2 38/40] docs: firmware-guide: acpi: dsd: graph.rst: " Mauro Carvalho Chehab
2021-05-12 13:46 ` Rafael J. Wysocki
2021-05-12 12:50 ` [PATCH v2 39/40] docs: virt: kvm: api.rst: " Mauro Carvalho Chehab
2021-05-12 12:50 ` [PATCH v2 40/40] docs: RCU: " Mauro Carvalho Chehab
2021-05-12 14:14 ` [Intel-gfx] [PATCH v2 00/40] " Theodore Ts'o
2021-05-12 14:14 ` [Intel-wired-lan] " Theodore Ts'o
2021-05-12 14:14 ` Theodore Ts'o
2021-05-12 14:14 ` Theodore Ts'o
2021-05-12 14:14 ` Theodore Ts'o
2021-05-12 14:14 ` [f2fs-dev] " Theodore Ts'o
2021-05-12 15:17 ` Mauro Carvalho Chehab
2021-05-12 15:17 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-12 15:17 ` Mauro Carvalho Chehab
2021-05-12 15:17 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-12 15:17 ` Mauro Carvalho Chehab
2021-05-12 15:17 ` Mauro Carvalho Chehab
2021-05-12 17:12 ` [Intel-gfx] " David Woodhouse
2021-05-12 17:12 ` [Intel-wired-lan] " David Woodhouse
2021-05-12 17:12 ` David Woodhouse
2021-05-12 17:12 ` David Woodhouse
2021-05-12 17:12 ` David Woodhouse
2021-05-12 17:07 ` [Intel-gfx] " David Woodhouse
2021-05-12 17:07 ` [Intel-wired-lan] " David Woodhouse
2021-05-12 17:07 ` David Woodhouse
2021-05-12 17:07 ` David Woodhouse
2021-05-12 17:07 ` David Woodhouse
2021-05-14 8:21 ` Mauro Carvalho Chehab
2021-05-14 8:21 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-14 8:21 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-14 8:21 ` Mauro Carvalho Chehab
2021-05-14 8:21 ` Mauro Carvalho Chehab
2021-05-14 8:21 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-14 9:06 ` [Intel-gfx] " David Woodhouse
2021-05-14 9:06 ` [Intel-wired-lan] " David Woodhouse
2021-05-14 9:06 ` David Woodhouse
2021-05-14 9:06 ` David Woodhouse
2021-05-14 9:06 ` David Woodhouse
2021-05-14 11:08 ` [f2fs-dev] " Edward Cree
2021-05-14 11:08 ` [Intel-wired-lan] " Edward Cree
2021-05-14 11:08 ` [Intel-gfx] " Edward Cree
2021-05-14 11:08 ` Edward Cree
2021-05-14 11:08 ` Edward Cree
2021-05-14 11:08 ` Edward Cree
2021-05-14 14:18 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-14 14:18 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-14 14:18 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-14 14:18 ` Mauro Carvalho Chehab
2021-05-14 14:18 ` Mauro Carvalho Chehab
2021-05-14 14:18 ` Mauro Carvalho Chehab
2021-05-15 8:22 ` Mauro Carvalho Chehab
2021-05-15 8:22 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-15 8:22 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-15 8:22 ` Mauro Carvalho Chehab
2021-05-15 8:22 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-15 8:22 ` Mauro Carvalho Chehab
2021-05-15 9:24 ` [Intel-gfx] " David Woodhouse
2021-05-15 9:24 ` [Intel-wired-lan] " David Woodhouse
2021-05-15 9:24 ` David Woodhouse
2021-05-15 9:24 ` David Woodhouse
2021-05-15 9:24 ` David Woodhouse
2021-05-15 11:23 ` [f2fs-dev] " Mauro Carvalho Chehab
2021-05-15 11:23 ` [Intel-wired-lan] " Mauro Carvalho Chehab
2021-05-15 11:23 ` [Intel-gfx] " Mauro Carvalho Chehab
2021-05-15 11:23 ` Mauro Carvalho Chehab
2021-05-15 11:23 ` Mauro Carvalho Chehab
2021-05-15 11:23 ` Mauro Carvalho Chehab
2021-05-15 12:02 ` [Intel-gfx] " David Woodhouse
2021-05-15 12:02 ` [Intel-wired-lan] " David Woodhouse
2021-05-15 12:02 ` David Woodhouse
2021-05-15 12:02 ` David Woodhouse
2021-05-15 12:02 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b48ff68615727c517df824af6a5b8f9edf55622.1620823573.git.mchehab+huawei@kernel.org \
--to=mchehab+huawei@kernel.org \
--cc=corbet@lwn.net \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.tretter@pengutronix.de \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=stanimir.varbanov@linaro.org \
--cc=tfiga@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.