[gimp-web] Some more updates in 2.99.4 news.

[Jehan <jehanp src gnome org>]

commit 22e79e31b4bb410535f6c7eda1686f787b3d66b9
Author: Jehan <jehan girinstud io>
Date:   Sun Dec 20 04:25:42 2020 +0100

    Some more updates in 2.99.4 news.

 .../2020/2020-12_GIMP-2.99.4_Released/index.md     | 62 ++++++++++++----------
 1 file changed, 33 insertions(+), 29 deletions(-)
---
diff --git a/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md 
b/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md
index 697ccc69..dac97296 100644
--- a/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md
+++ b/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md
@@ -138,20 +138,20 @@ dialog. This is a work we started earlier and continued for GIMP 2.99.4.
 **Call for inputs**:
 
 There are a few puzzling settings in this dialog and we would welcome
-input from anyone who had actual needs for it. How were you using this
-feature? Which OS? What was the goal?
+input from anyone who had actual needs for it. How were you using any of
+these features? Which OS? What was the goal?
 
 * There used to be a "Keys" list for every device in the dialog. We
   actually removed this list back in 2.99.2. Based on tests, code
-  research and discussion with Carlos Garnacho, we came to the
-  conclusion that the "Keys" concept was tied to "keyboard" devices
-  (a type of devices specifically which has always been filtered out of
-  this listing, at least since 2.8 and probably before) and is
-  meaningless on "pointer" devices (mice, touchpads, graphics tablets…).
-  Yet here was the option! Maybe it actually had a hidden usage to
-  someone, someday? If this is your case, please explain us so that we
-  can think of a way to restablish the feature with an understandabble
-  interface.
+  research and discussion with Carlos Garnacho, our local GTK and input
+  device expert, we came to the conclusion that the "Keys" concept was
+  tied to "keyboard" devices (a type of devices specifically which has
+  always been filtered out of this listing, at least since 2.8 and
+  probably before) and is meaningless on "pointer" devices (mice,
+  touchpads, graphics tablets…). Yet here was the option! Maybe it
+  actually had a hidden usage to someone, someday? If this is your case,
+  please explain us so that we can think of a way to restablish the
+  feature with an understandabble interface.
 * The "Axes" list has the ability to set the "axis use" for a given
   axis (the little numbers next to each axis). Yet we never managed to
   do anything with it. This looks mostly either broken or meaningless.
@@ -162,7 +162,7 @@ feature? Which OS? What was the goal?
   mode on the other hand is a concept only meaningful for "floating"
   devices (a concept maybe not even valid on all platforms?) and even
   then it looks broken, as far as our tests went. Is there anyone in the
-  world who actually use the "Window" mode and sees a difference with
+  world who actually uses the "Window" mode and sees a difference with
   "Screen"?
 
 If anyone gets a usage of these features, we would definitely welcome
@@ -172,7 +172,9 @@ the settings. Because it is only a waste of time and efforts to show
 non-working configuration, and it is confusing for everyone. On the
 other hand, we don't want to remove actual features if it turns out
 these can actually be used somehow. This is your time to shine and tell
-us how these are used!
+us how these are used (to contact us, you may for instance open a
+[report](https://gitlab.gnome.org/GNOME/gimp/-/issues) to explain your
+usage as a response to this news)!
 
 Note that if we finally understand how a feature is useful, we might
 actually even be able to improve the settings interface to make it more
@@ -217,21 +219,22 @@ quickly detect fonts useful for your language of choice in a long list.
 </figcaption>
 </figure>
 
-For Korean "한" (han) was chosen (apart from being the first syllable of
-Hangeul, the Korean writing system) because of the circle shape in 'ㅎ'
-(hieut) but also its small *hat* which has many stylistic variants and
-is therefore often quite a good hint of stylistic choices made by a font
-designer.
+For Korean "한" (han) was chosen (apart from being the first syllable in
+"Hangeul", the name of the Korean writing system) firstly because it is a
+syllable with two consonnants, which gives good indications on stylistic
+choices, and secondly because of the circle shape in 'ㅎ' (hieut) but
+also its small *hat* which has many stylistic variants and is therefore
+also quite a good hint of stylistic choices made by a font designer.
 
 As for "あ", it is the first *kana* in the hiragana syllabary, which is
 one of the main component of the Japanese writing system.
 
 The code logics is based on approximation of probable target lang
 depending on supported characters found in the fonts. It may not show
-always the ideal sample characters, especially for fonts which include a
-lot of characters from various scripts but remains globally very useful.
-This is based on existing code, which already had detection on other
-writing systems, yet not for Korean and Japanese yet.
+always the ideal sample characters, especially for fonts which try to
+support many different scripts but remains globally very useful.
+This is based on existing code, which already had detection for other
+writing systems, yet not for Korean and Japanese until now.
 
 # New experimental Paint Select tool
 
@@ -239,7 +242,7 @@ Our long-term contributor Thomas Manni is working on a new smart
 selection tool. This new development comes from recognition of the
 limitations of the current "Foreground Select" tool, which unfortunately
 does not work so well for actually segmenting global shapes, often takes
-a lot of time on big images and have memory issues.
+a lot of time on big images and have memory and stability issues.
 
 Quote from Thomas:
 
@@ -250,12 +253,13 @@ Quote from Thomas:
 
 The new tool instead will be a targeted segmentation" tool: its goal is
 to quickly isolate a specific region in the image ; it provides a binary
-result (full white for the area of interest, full black for all other
-pixels). Right now, if you test it in 2.99.4, you will still find it
-quite slow, but this is only because it is very early development and no
-work has been done on optimization so far, only functionality. Yet we
+result (fully selected for the area of interest, fully unselected for
+all other pixels). Right now, if you test it in 2.99.4, you will still
+find it quite slow, but this is because it is very early development and
+no work has been done on optimization so far, only functionality. Yet we
 expect it to be quite efficient and fast in the end, unlike the
-"Foreground Select" tool which suffers from an inadapted algorithm.
+"Foreground Select" tool which suffers from an algorithm inadapted to
+its expected purpose.
 
 <figure>
 <img src="{attach}gimp-2.99.4-Paintselect-canvas-interactions.png" alt="GIMP 2.99.4: Paint Select tool"/>
@@ -264,7 +268,7 @@ expect it to be quite efficient and fast in the end, unlike the
 </figcaption>
 </figure>
 
-Of course, this is still an early experiment, therefore it is expected
+Of course, this is still an early experiment, therefore it is advised
 not to keep all the hopes too high, just in case. If everything goes as
 planned, it is not sure yet what would happen to the "Foreground Select"
 tool, but it is likely we try to re-target it to focus on details, hair,