docs: removes non ascii characters (#4175)

docs/others/file_explorer.rst

@@ -5,7 +5,7 @@ File Explorer
 ``lv_file_explorer`` provides an API to browse the contents of the file
 system. ``lv_file_explorer`` only provides the file browsing function,
 but does not provide the actual file operation function. In other words,
-you can’t click a picture file to open and view the picture like a PC.
+you can't click a picture file to open and view the picture like a PC.
 ``lv_file_explorer`` will tell you the full path and name of the
 currently clicked file. The file operation function needs to be
 implemented by the user.

docs/others/fragment.rst

@@ -5,12 +5,12 @@ Fragment
 Fragment is a concept copied from
 `Android <https://developer.android.com/guide/fragments>`__.
 
-It represents a reusable portion of your app’s UI. A fragment defines
+It represents a reusable portion of your app's UI. A fragment defines
 and manages its own layout, has its own lifecycle, and can handle its
-own events. Like Android’s Fragment that must be hosted by an activity
+own events. Like Android's Fragment that must be hosted by an activity
 or another fragment, Fragment in LVGL needs to be hosted by an object,
-or another fragment. The fragment’s view hierarchy becomes part of, or
-attaches to, the host’s view hierarchy.
+or another fragment. The fragment's view hierarchy becomes part of, or
+attaches to, the host's view hierarchy.
 
 Such concept also has some similarities to `UiViewController on
 iOS <https://developer.apple.com/documentation/uikit/uiviewcontroller>`__.

docs/others/gridnav.rst

@@ -9,7 +9,7 @@ If the children are arranged into a grid-like layout then the up, down,
 left and right arrows move focus to the nearest sibling in the
 respective direction.
 
-It doesn’t matter how the children are positioned, as only the current x
+It doesn't matter how the children are positioned, as only the current x
 and y coordinates are considered. This means that gridnav works with
 manually positioned children, as well as `Flex </layouts/flex>`__ and
 `Grid </layouts/grid>`__ layouts.

docs/others/ime_pinyin.rst

@@ -53,7 +53,7 @@ input method plug-in, then use
 :c:expr:`lv_ime_pinyin_set_keyboard(pinyin_ime, kb)` to add the ``keyboard``
 you created to the Pinyin input method plug-in. You can use
 :c:expr:`lv_ime_pinyin_set_dict(pinyin_ime, your_dict)` to use a custom
-dictionary (if you don’t want to use the built-in dictionary at first,
+dictionary (if you don't want to use the built-in dictionary at first,
 you can disable :c:macro:`LV_IME_PINYIN_USE_DEFAULT_DICT` in ``lv_conf.h``,
 which can save a lot of memory space).
 
@@ -110,7 +110,7 @@ the keyboard and dictionary at any time.
 Custom dictionary
 -----------------
 
-If you don’t want to use the built-in Pinyin dictionary, you can use the
+If you don't want to use the built-in Pinyin dictionary, you can use the
 custom dictionary. Or if you think that the built-in phonetic dictionary
 consumes a lot of memory, you can also use a custom dictionary.
 
@@ -260,7 +260,7 @@ The lv_ime_pinyin have the following modes:
 -  :c:enumerator:`LV_IME_PINYIN_MODE_K9`: Pinyin 9 key input mode
 -  :c:enumerator:`LV_IME_PINYIN_MODE_K9_NUMBER`: Numeric keypad mode
 
-The ``TEXT`` modes’ layout contains buttons to change mode.
+The ``TEXT`` modes' layout contains buttons to change mode.
 
 To set the mode manually, use
 :c:expr:`lv_ime_pinyin_set_mode(pinyin_ime, mode)` . The default mode is

docs/others/msg.rst

@@ -26,7 +26,7 @@ no payload but :c:enumerator:`MSG_USER_NAME_CHANGED` can have a :c:expr:`const c
 payload containing the user name, and :c:enumerator:`MSG_USER_AVATAR_CHANGED` a
 :c:expr:`const void *` image source with the new avatar image.
 
-To be more precise the message ID’s type is declared like this:
+To be more precise the message ID's type is declared like this:
 
 .. code:: c
 
@@ -43,7 +43,7 @@ Subscribe to a message
 :c:expr:`lv_msg_subscribe(msg_id, callback, user_data)` can be used to
 subscribe to message.
 
-Don’t forget that ``msg_id`` can be a constant or a variable address
+Don't forget that ``msg_id`` can be a constant or a variable address
 too:
 
 .. code:: c
@@ -74,7 +74,7 @@ From :c:struct:`lv_msg_t` the followings can be used to get some data:
 Subscribe with an lv_obj
 ------------------------
 
-It’s quite typical that an LVGL widget is interested in some messages.
+It's quite typical that an LVGL widget is interested in some messages.
 To make it simpler :c:expr:`lv_msg_subsribe_obj(msg_id, obj, user_data)` can
 be used. If a new message is published with ``msg_id`` an
 :c:enumerator:`LV_EVENT_MSG_RECEIVED` event will be sent to the object.
@@ -95,7 +95,7 @@ For example:
        lv_label_set_text(label, lv_msg_get_payload(m));
    }
 
-Here ``msg_id`` also can be a variable’s address:
+Here ``msg_id`` also can be a variable's address:
 
 .. code:: c
 
@@ -128,19 +128,19 @@ Messages can be sent with :c:expr:`lv_msg_send(msg_id, payload)`. E.g.
 
 If have subscribed to a variable with
 :c:expr:`lv_msg_subscribe((lv_msg_id_t)&v, callback, NULL)` and changed the
-variable’s value the subscribers can be notified like this:
+variable's value the subscribers can be notified like this:
 
 .. code:: c
 
    v = 10;
    lv_msg_update_value(&v); //Notify all the subscribers of `(lv_msg_id_t)&v`
 
-It’s handy way of creating API for the UI too. If the UI provides some
+It's handy way of creating API for the UI too. If the UI provides some
 global variables (e.g. ``int current_tempereature``) and anyone can
 read and write this variable. After writing they can notify all the
 elements who are interested in that value. E.g. an ``lv_label`` can
 subscribe to :c:expr:`(lv_msg_id_t)&current_tempereature` and update its text
-when it’s notified about the new temperature.
+when it's notified about the new temperature.
 
 Example
 -------

docs/others/snapshot.rst

@@ -45,13 +45,13 @@ Use Existing Buffer
 
 If the snapshot needs update now and then, or simply caller provides memory, use API
 ``lv_res_t lv_snapshot_take_to_buf(lv_obj_t * obj, lv_img_cf_t cf, lv_img_dsc_t * dsc, void * buf, uint32_t buff_size)``
-for this case. It’s caller’s responsibility to alloc/free the memory.
+for this case. It's caller's responsibility to alloc/free the memory.
 
 If snapshot is generated successfully, the image descriptor is updated
 and image data will be stored to provided ``buf``.
 
 Note that snapshot may fail if provided buffer is not enough, which may
-happen when object size changes. It’s recommended to use API
+happen when object size changes. It's recommended to use API
 :c:func:`lv_snapshot_buf_size_needed` to check the needed buffer size in byte
 firstly and resize the buffer accordingly.