[gimp-web] content: some last second fixes, soon before publication.

[Jehan <jehanp src gnome org>]

commit fe6c19ab73e72a00218e8719ad82fa0eb2b98535
Author: Jehan <jehan girinstud io>
Date:   Sat Aug 27 12:02:47 2022 +0200

    content: some last second fixes, soon before publication.

 .../2022/2022-08_GIMP-2.99.12_Released/index.md    | 128 +++++++++++----------
 1 file changed, 66 insertions(+), 62 deletions(-)
---
diff --git a/content/news/2022/2022-08_GIMP-2.99.12_Released/index.md 
b/content/news/2022/2022-08_GIMP-2.99.12_Released/index.md
index 6b2c41f7..32a08f15 100644
--- a/content/news/2022/2022-08_GIMP-2.99.12_Released/index.md
+++ b/content/news/2022/2022-08_GIMP-2.99.12_Released/index.md
@@ -1,5 +1,5 @@
 Title: Development version: GIMP 2.99.12 Released
-Date: 2022-08-25
+Date: 2022-08-27
 Category: News
 Authors: Wilber
 Slug: gimp-2-99-12-released
@@ -8,8 +8,8 @@ Image: gimp-2.99.12-cmyk-space-invasion.gif
 
 GIMP 2.99.12 is a huge milestone towards GIMP 3.0. Many of the missing
 pieces are getting together, even though it is still a work in progress.
-As usual, issues are expected and possibly in particular in this release
-which got important changes in major areas, such as canvas interaction
+As usual, issues are expected and in particular in this release which
+got important updates in major areas, such as canvas interaction
 code, scripts, but also theming…
 
 <figure>
@@ -66,21 +66,23 @@ or even selecting layers through canvas ([since GIMP
 
 The current features are:
 
-| Modifiers    | Main button     | Secondary button (usually middle click) | Third Button (right click) |
+| Modifiers    | Main button     | Secondary button (usually middle click) | Third Button (usually right 
click) |
 | ------------ | -----------     | --------------------------------------- | -------------------------- |
 | -            | *Tool-specific* | Panning                                 | Contextual menu            |
-| `Ctrl`       | *Tool-specific* | Zoom                                    | -                          |
+| `Ctrl`/`Cmd` | *Tool-specific* | Zoom                                    | -                          |
 | `Shift`      | *Tool-specific* | Canvas rotation                         | -                          |
-| `Shift-Ctrl` | *Tool-specific* | Constrained (15°) canvas rotation       | -                          |
+| `Shift-Ctrl`/`Shift-Cmd` | *Tool-specific* | Constrained (15°) canvas rotation       | -                   
       |
 | `Alt`        | *Tool-specific* | Layer picking                           | Resize brush 
([new](#on-canvas-brush-sizing)) |
 
+*Note: on macOS, `Cmd` is used in place of `Ctrl`. This is usually
+implied when `Ctrl` only is mentioned.*
 
 These are based on the following logic:
 
 * The main button is *reserved for tools*. Even though some of them
-  share similar logic (e.g. all the selection tools have similar
-  modifiers to add/subtract/intersect selections), some may have
-  specific use cases.
+  share similar logic (e.g. all the selection tools share modifiers to
+  add, subtract or intersect selections), some tools will have specific
+  use cases.
 * The secondary button is used for "navigation", in particular canvas
   navigation, but even on some kind of `z` axis with layer navigation
   (recent Layer picking ability since GIMP 2.10.10).
@@ -91,7 +93,7 @@ These are based on the following logic:
 As we added new features, it became obvious that we were eventually
 going to lack modifiers for other useful actions. Also everyone is
 unique and has their own preferred workflow, so some people would
-definitely prefer to have slightly different action behavior.
+definitely wish to have slightly different action behavior.
 As an example, even the [just implemented brush
 sizing](#on-canvas-brush-sizing) already comes in 2 variants (resize
 from center or sides).
@@ -112,7 +114,7 @@ modifiers, remove some or change them all. The settings are in
 labelled "*Click here to set a button's modifiers*" with any mouse or
 stylus button to start customize its modifiers.
 
-You can even add custom "actions", i.e. anything to which you could
+You can even add "*custom actions*", i.e. anything to which you could
 assign a shortcut. Want to swap the foreground/background color on
 `right click`? Now you can. Want to activate the Unified Transform tool
 with `Shift-middle click` and remove canvas rotation? You can too.
@@ -154,11 +156,11 @@ The new behavior is the "*By distance*" drag-to-zoom as it will zoom more
 if you do large moves, or in a more fine-grained way with very short
 moves. We left both behaviors available as a settings because after user
 testing, we decided that some people may prefer the old behavior, though
-the newly proposed also made sense.
+the newly proposed one also made sense.
 
 Finally the "*Drag-to-zoom speed*" allows you to set the speed rate at
 which the zoom will happen, in percentage of the default (i.e. that 100
-is the default speed; you can lower or higher).
+is the default speed; you can raise or lower it).
 
 These zoom settings were contributed by woob.
 
@@ -195,7 +197,7 @@ instead of creating a dedicated setting.
 
 ⚠️ This point-like cursor feature is really adapted for tablet displays
 and may seem very hard to use and frustrating for any other usage
-(nearly invisibile pointer).
+(nearly invisible pointer).
 
 <figure>
 <a href="{attach}gimp-2.99.12-point-like-cursor.gif">
@@ -223,11 +225,10 @@ algorithm:
 1. **Line Art Detection**: the settings which configure how the line art
    is detected: which source is being used? Using opacity or grayscale?
    Which threshold?
-2. **Line Art Closure**: the settings for the closure algorithm, of
+2. **Line Art Closure**: the settings for the closure algorithm of
    opened line art areas.
 3. **Fill Borders**: the settings for borders of the fill: how much
-   should we grow under the detected line art? How to get smoother
-   borders?
+   should we grow under the detected line art? How to get nicer borders?
 
 <figure>
 <a href="{attach}gimp-2.99.12-fill-line-art-3-steps.png">
@@ -268,7 +269,7 @@ with rainbow 🌈 colors, this is up to you!
 
 The new function `gimp_checks_get_colors()` has been added to the
 interface for plug-ins, replacing `gimp_checks_get_shades()`. This would
-allow any plug-in needed to render transparency checkerboard according
+allow any plug-in needing to render transparency checkerboard according
 to user choice.
 
 This was originally contributed by Ben Rogalski, then improved, in
@@ -314,8 +315,8 @@ Furthermore you can now zoom the preview images in item dockables
 
 Finally you can zoom in the *Gradients* dockable by pinch gesture too.
 
-All of these were contributed by Povilas Kanapickas, who already
-implemented pinch gesture on canvas.
+All of these were contributed by Povilas Kanapickas, who had already
+implemented zoom through pinch gesture on canvas.
 
 ## CMYK
 
@@ -335,7 +336,7 @@ format (e.g. through a profile given to you by a printshop, often a CMYK
 profile) and want to see how your image would render, in particular
 regarding gamut loss.
 
-It was already possible to set a "Soft proof profile", as well as a
+It was already possible to set a "*Soft proof profile*", as well as a
 rendering intent, and whether you wanted black point compensation or
 not. Yet this info was lost at each session restart.
 
@@ -344,12 +345,14 @@ need to re-set them each time. Indeed if you work on a print job, the
 final target can be considered part of your workflow for this specific
 print job, hence part of the image.
 
-As a consequence, these moved from the `View > Color Management` menu to
-the `Image > Color Management` menu (though `View > Color management`
-still contains some settings, such as whether to enable color management
-and whether or not to soft-proof. These are not image data but specific
-to a view: a same image can be simultaneously displayed in several
-views, one proofed and the other not, for instance).
+As a consequence, these 3 information (soft proof profile, soft proof
+rendering intent and soft proof black point compensation) moved from the
+`View > Color Management` menu to the `Image > Color Management` menu
+(though `View > Color management` still contains some settings, such as
+whether to enable color management and whether or not to soft-proof;
+these are not image data but specific to a view: a same image can be
+simultaneously displayed in several views, one proofed and the other
+not, for instance).
 
 ### Simulation toggle in the status bar
 
@@ -379,8 +382,8 @@ changing soft-proofing settings with a toggle on status bar"/>
 ### Various GUI now simulation-aware
 
 Most GUIs which were displaying CMYK data were displaying "naive CMYK"
-colors. It was some generic algorithm not taking account a specific CMYK
-color space.
+colors. It is some generic algorithm not taking into account a specific
+CMYK color space.
 
 Now if you set a simulation profile, and if this profile is a CMYK one,
 then these interface will display CMYK colors for this space, assuming
@@ -402,7 +405,7 @@ means that:
   simulation profile. I.e. that the image will now be RGB, yet the CMYK
   profile will be kept for simulation.
 * RGB images can be exported as CMYK, using the simulation profile (if a
-  CMYK one).
+  CMYK one) for conversion, then stored in the resulting CMYK file.
 
 The assumption is always that the simulation profile is your target
 color space.
@@ -435,17 +438,17 @@ with new functions, such as `gimp_image_get_simulation_profile()` or
 image data which can and should be used by plug-ins when they want to
 display or process CMYK colors in the context of the active image.
 
-Similarly several `libgimpwidgets` widgets (GimpColorNotebook,
-GimpColorSelection and GimpColorSelector) are simulation-aware with new
-dedicated functions to set the simulation space of interest.
+Similarly several `libgimpwidgets` widgets (`GimpColorNotebook`,
+`GimpColorSelection` and `GimpColorSelector`) became simulation-aware
+with new dedicated functions to set the simulation space of interest.
 
 ## Themes
 
 GTK got a new CSS-like theming system in GTK+ 3, which means our 2.10
 themes were not reusable and which is why we called for theme designers
 many times because a graphics application should really have a good set
-of neutral gray themes for an interface with the less color pollution,
-as it can affect your color perception.
+of neutral gray themes for an interface with the less color pollution
+possible, as it can affect your color perception.
 
 It is only a month ago that we got a first proposal for a mid-gray
 neutral theme, though this one is still a work-in-progress. On the other
@@ -543,9 +546,9 @@ pop-up also reminds. ☢️
 
 ### GIF
 
-A new option appeared in the GIF export dialog: "Number of repeats". It
-specifies a specific number of repeat for loop animation. Previously you
-only had the choice of single run animation versus infinite loop.
+A new option appeared in the GIF export dialog: "*Number of repeats*".
+It specifies a specific number of repeat for loop animation. Previously
+you only had the choice of single run animation versus infinite loop.
 
 <figure>
 <a href="{attach}gimp-2.99.12-gif-repeat.png">
@@ -561,13 +564,13 @@ only had the choice of single run animation versus infinite loop.
 The following changes happened in our PNG support:
 
 * The format does not have any flag for linear RGB, but it can simply
-  include a linear profile (or a 1.0 gAMA chunk). Therefore since we
-  always attach the profile when importing (or transforming the gAMA
+  include a linear profile (or a 1.0 `gAMA` chunk). Therefore since we
+  always attach the profile when importing (or transforming the `gAMA`
   chunk into a profile), we now always load PNG images as non-linear
   backend.
-* When exporting index images, a new checkbox "*Optimize for smallest
-  possible palette size*", if enabled, will export a PNG file with the
-  smallest palette possible (less than an 8-bit palette with 256
+* When exporting indexed images, a new checkbox "*Optimize for smallest
+  possible palette size*", if enabled, will export a PNG file with
+  lowest bit-depth palette possible (less than an 8-bit palette with 256
   entries, if possible).
 
 ### DDS
@@ -601,10 +604,10 @@ developer software, such as darktable or RawTherapee).
 
 A big rewriting of the Raw Data dialog (and API) organization happened.
 
-First, it is now possible to export any bit depth as Raw data (since the
-higher bit depth support, exporting 16 or 32-bit images were still
-exporting them as 8-bit raw data). This will also be available in future
-stable version GIMP 2.10.34.
+First, it is now possible to export any bit depth as raw data (despite
+the higher bit depth support, exporting 16 or 32-bit images used to
+still export them 8-bit raw data). This part will also be available in
+future stable version GIMP 2.10.34.
 
 And especially all exportable formats can be loaded back, and more. As
 it made for a huge list, the way the import dialog used to list formats,
@@ -623,7 +626,7 @@ layout for various components.
 </figcaption>
 </figure>
 
-As a consequence GIMP now support a lot more raw data formats, while
+As a consequence GIMP now supports a lot more raw data formats, while
 keeping a usable dialog, without showing a never-ending list of formats.
 
 The PDB API for this plug-in has also been improved to follow the same
@@ -677,7 +680,7 @@ responsibility to heart as Script-fu code has not seen such activity for
 years now.
 
 A lot of bugs were fixed, more documentation for Script-fu developers
-was written, but also a lot of huge changes happened.
+was written, but also huge changes happened.
 
 ### Script-fu server now its own plug-in
 
@@ -737,7 +740,7 @@ A new `gimp_image_metadata_save_filter()` also appears, as an
 alternative to `gimp_image_metadata_save_finish()` when you want to save
 metadata yourself and you need only filtering processing.
 It returns filtered metadata allowing the caller to save the finalized
-metadata via other means (via native format’s library for example) This
+metadata via other means (via native format’s library for example). This
 API can be used to support metadata saving of image formats not directly
 supported by gexiv2/exiv2. We already use it for the HEIF/AVIF plug-in.
 
@@ -750,18 +753,18 @@ Among the many other changes, one of the most important changes in this
 updated API is how we handle plug-in localization. While the translation
 of most strings were left to the plug-in's discretion, the strings at
 register time (plug-in title, documentation…) were translated by the
-core, e.g. when used in menus of in the PDB browser, using gettext
+core, e.g. when used in menus or in the PDB browser, using gettext
 catalog given at registration time. This raised various issues, such as
 what happens if several plug-ins were to register a catalog with the
 same name (which could have been fixed, with even more complicated
-internal logic). Or what happens if a plug-in doesn't register a
+internal logic)? Or what happens if a plug-in doesn't register a
 localization catalog, but the default catalog contains (wrong)
 translations for submitted strings? Moreover it ended up to be quite
 confusing as many plug-in developers were wondering what is translated
 where, i.e. if a string should be surrounded by `_()` (common gettext
 macro) or `N_()` (noop gettext macro).
 
-So the new logic is much simpler: translation is now left completely at
+So the new logic is much simpler: translation is now left *entirely* at
 the plug-in discretion, i.e. all strings received by the core are
 assumed to be in the correct target language. The core doesn't try to
 translate anything coming from plug-ins anymore.
@@ -770,9 +773,10 @@ Now to help a bit with localization, our infrastructure proposes a
 standard file organization, with all gettext catalogs under the
 `locale/` folder of the plug-in directory, and named the same way as the
 plug-in itself. If the catalog is absent, our system outputs a message
-on `stderr` to propose this standard procedure. A plug-in following this
-procedure won't have anything else to do than place the compiled gettext
-catalogs (`*.mo` files) with the right domain name in the right folder.
+on `stderr` to inform of this standard procedure. A plug-in following
+this procedure won't have anything else to do than place the compiled
+gettext catalogs (`*.mo` files) with the right domain name in the right
+folder.
 
 A `GimpPlugIn` can supplant this behavior at any time by overriding the
 `set_i18n()` method, to either disable localization altogether, pointing
@@ -862,7 +866,7 @@ This is still an evaluation phase for this build system, though now we
 are moving forward into intensive testing. **If you are a packager,
 please try to now use our meson build and report any issue to us.**
 
-Exceptionally for this version, we released 2 tarballs on our [build
+Exceptionally for this version, we released 2 tarballs on our [download
 server](https://download.gimp.org/pub/gimp/v2.99/):
 `gimp-2.99.12.tar.xz` and `gimp-2.99.12-autotools.tar.bz2`. As you can
 guess, the former is the meson-generated tarball, yet we left an
@@ -894,7 +898,7 @@ rid of this technical debt! 🥳
 
 Of course, it triggered various problems, even to release day as we
 realized when testing installers that some buttons were broken (which is
-one of the reasons why this news is out 4 days after the actual source
+one of the few reasons why this news is out days after the actual source
 release) and we had to fix the strings. Hopefully this was the last
 related issue!
 
@@ -912,7 +916,7 @@ Some other issues have been handled in our code.
 
 One of them is that early testers may have noticed a very annoying popup
 telling you that "*gimp-2.99 wants to inhibit shortcuts*" (at least on
-`Mutter`, the Wayland compositor of GNOME).
+`Mutter`, the Wayland compositor of GNOME) in former 2.99 versions.
 This got fixed by removing various keyboard grabbing code which was not
 necessary anymore with GTK+3.0.
 
@@ -932,8 +936,8 @@ return managed colors.
 
 Meanwhile, we are in discussions with Freedesktop portal developers to
 get a new color-picking portal API, which will eventually have to be
-implemented for the various desktops. Let's hope it happens sooner than
-later! 😅
+implemented for the various desktops. Let's hope it happens sooner
+rather than later! 😅
 
 ### macOS
 
@@ -995,7 +999,7 @@ As usual, this release is supplemented with the releases of
 ### babl 0.1.94/0.1.96
 
 babl 0.1.94 fixes a crash on non-aligned data for SIMD and improve vala
-compatibility of introspection info.
+compatibility of introspection information.
 
 It also brings a new command line utility for converting unique colors
 from one format and/or space to another. This is very useful to us for