docs: removes non ascii characters (#4175)

docs/porting/disp.rst

@@ -11,7 +11,7 @@ a multiple displays and a different driver for each (see below),
 Basic setup
 ***********
 
-Draw buffer(s) are simple array(s) that LVGL uses to render the screen’s
+Draw buffer(s) are simple array(s) that LVGL uses to render the screen's
 content. Once rendering is ready the content of the draw buffer is sent
 to the display using the ``flush_cb`` function.
 
@@ -75,7 +75,7 @@ The draw buffers can be set with
    -  :cpp:enumerator:`LV_DISP_RENDER_MODE_FULL` The buffer can smaller or screen
       sized but LVGL will always redraw the whole screen even is only 1
       pixel has been changed. If two screen sized draw buffers are
-      provided, LVGL’s display handling works like “traditional” double
+      provided, LVGL's display handling works like "traditional" double
       buffering. This means the ``flush_cb`` callback only has to update
       the address of the framebuffer (``color_p`` parameter).
 
@@ -112,7 +112,7 @@ Resolution
 To set the resolution of the display after creation use
 :cpp:expr:`lv_disp_set_res(disp, hor_res, ver_res)`
 
-It’s not mandatory to use the whole display for LVGL, however in some
+It's not mandatory to use the whole display for LVGL, however in some
 cases the physical resolution is important. For example the touchpad
 still sees the whole resolution and the values needs to be converted to
 the active LVGL display area. So the physical resoltution and the offset
@@ -124,13 +124,13 @@ Rotation
 --------
 
 LVGL supports rotation of the display in 90 degree increments. You can
-select whether you’d like software rotation or hardware rotation.
+select whether you'd like software rotation or hardware rotation.
 
 The orientation of the display can be changed with
 ``lv_disp_set_rotation(disp, LV_DISP_ROTATION_0/90/180/270, true/false)``.
 LVGL will swap the horizontal and vertical resolutions internally
 according to the set degree. IF the last paramter is ``true`` LVGL will
-rotate the rendered image. If it’s ``false`` the display driver should
+rotate the rendered image. If it's ``false`` the display driver should
 rotate the rendered image.
 
 Color format
@@ -173,7 +173,7 @@ native color format to the desired, therfore rendering in non-native
 formats has a negative effect on peroformance. Learn more about
 ``draw_ctx`` `here </porting/gpu>`__.
 
-It’s very important that draw buffer(s) should be large enough for both
+It's very important that draw buffer(s) should be large enough for both
 the native format and the target color format. For example if
 ``LV_COLOR_DEPTH == 16`` and :cpp:enumerator:`LV_COLOR_FORMAT_XRGB8888` is selected
 LVGL will choosoe the larger to figure out how many pixel can be

docs/porting/draw.rst

@@ -24,7 +24,7 @@ Fields
 - ``void (*draw_rect)()`` Draw a rectangle with shadow, gradient, border, etc.
 - ``void (*draw_arc)()`` Draw an arc
 - ``void (*draw_img_decoded)()`` Draw an (A)RGB image that is already decoded by LVGL.
-- ``lv_res_t (*draw_img)()`` Draw an image before decoding it (it bypasses LVGL’s internal image decoders)
+- ``lv_res_t (*draw_img)()`` Draw an image before decoding it (it bypasses LVGL's internal image decoders)
 - ``void (*draw_letter)()`` Draw a letter
 - ``void (*draw_line)()`` Draw a line - ``void (*draw_polygon)()`` Draw a polygon
 - ``void (*draw_bg)()`` Replace the buffer with a rect without decoration like radius or borders.
@@ -35,9 +35,9 @@ Fields
 
 All ``draw_*`` callbacks receive a pointer to the current ``draw_ctx``
 as their first parameter. Among the other parameters there is a
-descriptor that tells what to draw, e.g. for ``draw_rect`` it’s called
+descriptor that tells what to draw, e.g. for ``draw_rect`` it's called
 :cpp:struct:`lv_draw_rect_dsc_t`,
-for :cpp:func:`lv_draw_line` it’s called :cpp:struct:`lv_draw_line_dsc_t`,
+for :cpp:func:`lv_draw_line` it's called :cpp:struct:`lv_draw_line_dsc_t`,
 etc.
 
 To correctly render according to a ``draw_dsc`` you need to be familiar
@@ -67,7 +67,7 @@ calling :cpp:func:`lv_disp_drv_register`. It makes it possible to use your own
 Software renderer
 *****************
 
-LVGL’s built in software renderer extends the basic :cpp:type:`lv_draw_ctx_t`
+LVGL's built in software renderer extends the basic :cpp:type:`lv_draw_ctx_t`
 structure and sets the draw callbacks. It looks like this:
 
 .. code:: c
@@ -92,7 +92,7 @@ Blend callback
 --------------
 
 As you saw above the software renderer adds the ``blend`` callback
-field. It’s a special callback related to how the software renderer
+field. It's a special callback related to how the software renderer
 works. All draw operations end up in the ``blend`` callback which can
 either fill an area or copy an image to an area by considering an optional mask.
 
@@ -100,7 +100,7 @@ The :cpp:struct:`lv_draw_sw_blend_dsc_t` parameter describes what and how to
 blend. It has the following fields:
 
 - ``const lv_area_t * blend_area`` The area with absolute coordinates to draw
-  on ``draw_ctx->buf``. If ``src_buf`` is set, it’s the coordinates of the image to blend.
+  on ``draw_ctx->buf``. If ``src_buf`` is set, it's the coordinates of the image to blend.
 - ``const lv_color_t * src_buf`` Pointer to an image to blend. If set,
   ``color`` is ignored. If not set fill ``blend_area`` with ``color``
 - ``lv_color_t color`` Fill color. Used only if ``src_buf == NULL``
@@ -116,7 +116,7 @@ Extend the software renderer
 New blend callback
 ------------------
 
-Let’s take a practical example: you would like to use your MCUs GPU for
+Let's take a practical example: you would like to use your MCUs GPU for
 color fill operations only.
 
 As all draw callbacks call ``blend`` callback to fill an area in the end
@@ -244,7 +244,7 @@ Fully custom draw engine
 ************************
 
 For example if your MCU/MPU supports a powerful vector graphics engine
-you might use only that instead of LVGL’s SW renderer. In this case, you
+you might use only that instead of LVGL's SW renderer. In this case, you
 need to base the renderer on the basic :cpp:type:`lv_draw_ctx_t` (instead of
 :cpp:struct:`lv_draw_sw_ctx_t`) and extend/initialize it as you wish.
 

docs/porting/indev.rst

@@ -154,7 +154,7 @@ specified in ``indev_drv.long_press_repeat_time``.
 Button
 ------
 
-*Buttons* mean external “hardware” buttons next to the screen which are
+*Buttons* mean external "hardware" buttons next to the screen which are
 assigned to specific coordinates of the screen. If a button is pressed
 it will simulate the pressing on the assigned coordinate. (Similarly to a touchpad)
 

docs/porting/log.rst

@@ -15,7 +15,7 @@ To enable logging, set :c:macro:`LV_USE_LOG` in ``lv_conf.h`` and set
 
 - :c:macro:`LV_LOG_LEVEL_TRACE`: A lot of logs to give detailed information
 - :c:macro:`LV_LOG_LEVEL_INFO`: Log important events
-- :c:macro:`LV_LOG_LEVEL_WARN`: Log if something unwanted happened but didn’t cause a problem
+- :c:macro:`LV_LOG_LEVEL_WARN`: Log if something unwanted happened but didn't cause a problem
 - :c:macro:`LV_LOG_LEVEL_ERROR`: Only critical issues, where the system may fail
 - :c:macro:`LV_LOG_LEVEL_USER`: Only user messages
 - :c:macro:`LV_LOG_LEVEL_NONE`: Do not log anything
@@ -36,8 +36,8 @@ If your system supports ``printf``, you just need to enable
 Custom log function
 -------------------
 
-If you can’t use ``printf`` or want to use a custom function to log, you
-can register a “logger” callback with :cpp:func:`lv_log_register_print_cb`.
+If you can't use ``printf`` or want to use a custom function to log, you
+can register a "logger" callback with :cpp:func:`lv_log_register_print_cb`.
 
 For example:
 

docs/porting/os.rst

@@ -6,7 +6,7 @@ Operating system and interrupts
 
 LVGL is **not thread-safe** by default.
 
-However, in the following conditions it’s valid to call LVGL related
+However, in the following conditions it's valid to call LVGL related
 functions: - In *events*. Learn more in :ref:`events`. -
 In *lv_timer*. Learn more in `Timers </overview/timer>`__.
 
@@ -60,6 +60,6 @@ Try to avoid calling LVGL functions from interrupt handlers (except
 this you have to disable the interrupt which uses LVGL functions while
 :cpp:func:`lv_timer_handler` is running.
 
-It’s a better approach to simply set a flag or some value in the
+It's a better approach to simply set a flag or some value in the
 interrupt, and periodically check it in an LVGL timer (which is run by
 :cpp:func:`lv_timer_handler`).

docs/porting/project.rst

@@ -61,7 +61,7 @@ Configuration file
 ------------------
 
 There is a configuration header file for LVGL called **lv_conf.h**. You
-modify this header to set the library’s basic behavior, disable unused
+modify this header to set the library's basic behavior, disable unused
 modules and features, adjust the size of memory buffers in compile-time,
 etc.
 
@@ -77,7 +77,7 @@ content. So the layout of the files should look like this:
    |-other files and folders
 
 Comments in the config file explain the meaning of the options. Be sure
-to set at least :c:macro:`LV_COLOR_DEPTH` according to your display’s color
+to set at least :c:macro:`LV_COLOR_DEPTH` according to your display's color
 depth. Note that, the examples and demos explicitly need to be enabled
 in ``lv_conf.h``.