Hi All,

I think somewhere it says to please post to the docs list if someone is working on a specific bit of documentation.

As my first attempt at trying to help with updating the documentation, I want to try to update the Colors/Desaturate/Desaturate documentation to be current with some recent patches.

If this goes well, then maybe I can help work on updating documentation for GIMP 2.9/2.10 color management and layer blend/compositing modes.

I've already cloned, compiled, and installed the documentation, and looked at the source code. I have a general idea how to procede but I'm sure I'll have questions.

Best, Elle

http://ninedegreesbelow.com
Color management and free/libre photography

On 03/23/2017 03:52 PM, Julien Hardelin wrote:

Welcome Elle,

At last, I will not be alone writing documentation :-)

I send you an How to contribute that summarizes my experience, hoping it will help you.

Julien

Hi Julien,

Is there a version of the git master documentation online somewhere? I see 2.8 online, but not 2.9/2.10.

Is there an IRC channel for documentation? Or is the docs-list the best place to ask questions?

Regarding images, in the desaturate documentation there are two images:

1. The desaturate dialog. I'd like to make a new screenshot as the current screenshot is out of date, not showing the current default which has changed to "Luminance".

2. The sunflower illustrating various ways to desaturate using the desaturate dialog. This is out of date because it's missing a couple of options. Also I'd like to add a second image to illustrate a particular point (having to do with colorfulness vs luminance) when evaluating the various desaturate options.

Are there guidelines for making images (number per page, dimensions, file size, file type, stripped of metadata?, etc)? I see that all the images on the desaturate page are pngs and are fairly small.

I didn't (yet?) receive a "How to contribute" but that sounds very useful.

Best, Elle

On 03/23/2017 05:42 PM, Kolbjrn Stuestl wrote:

I too welcomes you, Elle.

Thanks!

I know that Julien is an excellent writer and teacher so you are in the best hands. It was Julien (among a couple others) who instructed me in how to translate and in writing documentation many years ago.

Hopefully I can learn from Julien how to write more clearly using fewer words.

Hoping you will discuss problems and solutions on this site. I have lots more to learn by following your thoughts.

Well, if there's something I can help explain, please ask!

The GIMP manual is huge - I didn't know so few people actually wrote documentation - it seems to me that you all have accomplished miracles.

Best, Elle

On 03/23/2017 11:09 PM, Pat David wrote:

Hi Elle!

I can't answer the other questions, but 2.9 can be found here:

https://docs.gimp.org/2.9/en/

pat

Pat, thanks! I was sure I had seen such a link, but couldn't find it again.

Elle

On 03/21/2017 12:48 PM, Elle Stone wrote:

As my first attempt at trying to help with updating the documentation, I want to try to update the Colors/Desaturate/Desaturate documentation to be current with some recent patches.

It will be easier for me to work with XML once I know what content I want to put into the XML files. So I revised the html file for the Colors/Desaturate/Desaturate menu and posted the revision to my website. Here's the (very temporary) link:

http://ninedegreesbelow.com/files/desaturate/8-18-desaturate.html

Feedback on the revision is greatly appreciated. If I've used too many words, too long sentences, strayed into too much detail, made any blatant mistakes, etc, please let me know and I'll try again.

If I don't receive any negative feedback (or no feedback at all) in the next day or so, I'll assume my revision is "content OK" and will port the revised content over to the XML documents.

On the one hand, there have been a lot of major changes to GIMP's "color management/color mixing/layer blending" code, that needs corresponding revision in the documentation.

On the other hand, the articles and tutorials I've written for my website tend to be overly wordy and technical.

So I want to make sure I'm hitting the right balance of "too little vs too much information" before heading into the deeper waters of the color management documentation. Which is why I'm asking for feedback on the Desaturate menu revisions.

Best, Elle

http://ninedegreesbelow.com
Color management and free/libre photography

On 03/25/2017 03:12 AM, Julien Hardelin wrote:

Hello Elle,

Hi Julien,

Thanks! for taking the time to respond.

Color management is a hard subject. In the gimp-users list, questions about color management are rare, because common users don't use it, because they don't understand it.

In the other hand, this document will be interesting for users who know color management.

Maybe everything under "Choose shades of gray based on" except the actual formulas should be moved to the Notes at the bottom of the page?

Your participation is a chance for gimp-help. I think we can keep this text as it is, but a tutorial about color management for newbies becomes necessary.

Yes - I've been working on a tutorial that could be included in GIMP help or the official online GIMP tutorials.

Only small remarks:

- Precise that these options belong to the Mode item.

My apologies, I don't understand what "Precise that these options belong to the Mode item" means. What is a Mode item?

- All elements of a dialog must be described, even if they look evident, because they might not be evident for some users: function, what are they useful for?

Are you referring to the "Advanced Color Options"?

-"linearized RGB" needs a link.

Linearizing the sRGB TRC is actually at the core of how GIMP 2.9/2.10 differs from GIMP 2.8 and from other image editors.

A short explanation to which references to "linearized" and "linear" can link would be a nice thing to add to the GIMP tutorials or help, yes?

Section 1 of this link gives the mathematics for linearizing the sRGB TRC: http://brucelindbloom.com/index.html?Eqn_RGB_to_XYZ.html

Someone who doesn't already understand "linearized RGB" probably won't find the mathematical formula for undoing the sRGB companding curve to be very helpful in understanding what "linearize" actually means.

Best, Elle

On 03/25/2017 04:10 PM, Julien Hardelin wrote:

My apologies, I don't understand what "Precise that these options belong to the Mode item" means. What is a Mode item?

Are you referring to the "Advanced Color Options"?

Options
1- Presets
2- Mode
* Luminance
* Luma
* Lightness
* Average
* Value
3- Advanced options
* Apply filter to the layer's RAW pixels: with an example 4- Preview
5- Split view: interest?

I'm still not sure what you are saying.

Are you saying that you want specific documentation for the desaturate dialog for *all* of the following?

Presets All the Modes
The Advanced options
The Preview
The Split View

Or are you saying you only want documentation for the five Modes?

Luminance Luma
Lightness
Average
Value

FWIW, I succeeded in compiling gimp-help with the modified desaturate XML file. I'll send some questions in another email.

Best, Elle

On 03/26/2017 10:58 AM, Elle Stone wrote:

FWIW, I succeeded in compiling gimp-help with the modified desaturate XML file. I'll send some questions in another email.

Regarding autogen.sh:

1. This "autogen.sh" command succeeds in generating the requisite files for compiling:

./autogen.sh --prefix=/home/elle/code/gimp-help/install/ --without-gimp

But the build ("make -j4 install") ends in an error message:

make[2]: Entering directory '/home/elle/code/gimp-help/gimp-help-2' make[2]: Nothing to be done for 'install-exec-am'. /bin/mkdir: cannot create directory /usr/share/gimp/2.0/help: Permission denied
make[2]: *** [Makefile:1616: install-data-local] Error 77 make[2]: Leaving directory '/home/elle/code/gimp-help/gimp-help-2' make[1]: *** [Makefile:977: install-am] Error 2 make[1]: Leaving directory '/home/elle/code/gimp-help/gimp-help-2' make: *** [Makefile:677: install-recursive] Error 1

When the above error is printed to screen, the actual compiled html files are already in /home/elle/code/gimp-help/gimp-help-2/html/

So I guess instead of "make -j4 install" it would be OK to just type "make -j4", yes? no?

2. This "autogen.sh" command ends in an error message:

./autogen.sh --prefix=/home/elle/code/gimp-help/install/ --without-gimp --ALL_LINGUAS="en"

Looking for latest automake version ... 1.15

I am going to run ./configure with the following arguments:

--enable-maintainer-mode --enable-build --prefix=/home/elle/code/gimp-help/install/ --without-gimp --ALL_LINGUAS=en

Unescaped left brace in regex is deprecated, passed through in regex; marked by for more information

Configure failed or did not finish!

Best, Elle

On 03/26/2017 11:34 AM, Marco Ciampa via gimp-docs-list wrote:

But the build ("make -j4 install") ends in an error message:

try without -j4:

make html-en

That works - thanks! Where did this "html-en" option come from?

Starting from "./autogen.sh", what are the recommended commands for installing and then updating gimp-help, when the goal is to check the English html file that results from modifying a single xml file?

Best, Elle

On 03/26/2017 10:58 AM, Elle Stone wrote:

2- Mode
* Luminance
* Luma
* Lightness
* Average
* Value
3- Advanced options
* Apply filter to the layer's RAW pixels: with an example

If the above means that there should be documentation for the five Modes and *also* for "Advanced options/Apply filter to the layer's RAW pixels", I don't think adding documentation for "Advanced options Apply filter to the layer's RAW pixels" to the desaturate help (or any other help page for a specific editing option) is a good idea.

Just one example wouldn't do as it would be misleading. Between the gamma hack and the "color managed" option there are four possible combinations for the user to choose among, for each desaturate mode:

* The precise effect of each combination of "mode+using or not using the advanced options" does vary depending on whether the operation in question requests linearized RGB or RGB encoded using the sRGB TRC. So for example the effect when choosing Luminance is different from the effect when using Luma.

*The precise effect also varies depending on whether the image is at "linear" or "perceptual" precision.

* It seems, though I'm not 100% certain, that the effect also depends on whether there has been any previous "making of a new profile from a pre-existing non-GIMP-built-in profile", which in turn depends on whether the image had an embedded linear gamma ICC profile and whether the image has been promoted to 32f with linear precision and then possibly back to gamma precision, and on whether the user has chosen to automatically promote to 32f in Preferences.

In other words, accurately explaining the possible results from using the Advanced Color Options in the Desaturate dialog would require a flow chart in order to explain what happens when using which combination of the Advanced Color Options given X current precision, Y previous precision changes and Z original non-sRGB embedded ICC profile, combined with the choice amongst the various modes for converting to black and white that the user has made.

I'd very much prefer to not create such a flow chart, especially since the code for the relevant factors affecting the outcome of any given set of choices+previous-precision-changes is still in a state of flux.

Best, L

On 03/26/2017 10:58 AM, Elle Stone wrote:

FWIW, I succeeded in compiling gimp-help with the modified desaturate XML file. I'll send some questions in another email.

Here is a link to what the modified html file looks like after compiling gimp-help to use the modified desaturate xml file, along with some new images:

http://ninedegreesbelow.com/files/desaturate/8-18-desaturate.html

Here are three specific questions:

1. How does one validate a specific xml file? Running "make validate-en" produces this rather unhelpful output:

*** Validating XML (en) ... -:57673: element figure: validity error : Element figure content does not follow the DTD, expecting (blockinfo? , (title , titleabbrev?) , (literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | indexterm | beginpage | link | olink | ulink)+), got (title para mediaobject mediaobject para mediaobject mediaobject para mediaobject mediaobject para mediaobject mediaobject para mediaobject mediaobject para mediaobject mediaobject para itemizedlist para itemizedlist )

^
(You will find log and xml files in log/.)

I say "unhelpful" because there's no mention of what file is causing the error. Opening the files in "log/" also doesn't seem to indicate which file is causing the problems.

2. I checked with https://validator.w3.org/check, which said the errors were exactly where I thought they would be, which is that I used to cause the pairs of image files to be split by line breaks.

So what is the right way to cause a bunch of image files to break to a new line at specific places in the list of image files?

Also the w3 validator didn't like that I put an itemized list inside the Figure.

How do I fix these issues with the Figure?

3. I used this to try to make some text italicized:

Comparing the resulting shades of gray for the red globe and yellow sunflower:

but the text isn't italicized in the html file. So how does one make text be italicised?

Best,
Elle

Here's the relevant excerpts from desaturate.xml:

Comparing the five options

The images below shows the result of using the five different ways to convert to black and white, for two very different starting images:

Original image







Original image

Luminance applied







Luminance applied

. . .

Comparing the resulting shades of gray for the red globe and yellow sunflower:

For the red globe Lightness (HSL) produces a result very
similar to Luminance, and Luma produces a conversion that is much darker.

For the sunflower, Luma produces a result very similar to
Luminance, and Lightness (HSL) produces a conversion that is much darker.

Notice that the less saturated parts of each image look more or less the same, regardless of which methoc is chosen for converting
from color to black and white.

. . .

On 03/26/2017 12:52 PM, Elle Stone wrote:

Here is a link to what the modified html file looks like after compiling gimp-help to use the modified desaturate xml file, along with some new images:

http://ninedegreesbelow.com/files/desaturate/8-18-desaturate.html

Oh, sorry, forgot to upload the newfiles! But now the new files are up there.

And italicized lines are actually italicized, yeah!

Best, Elle

On 03/26/2017 12:52 PM, Elle Stone wrote:

Here are three specific questions:

1. How does one validate a specific xml file? Running "make validate-en" produces this rather unhelpful output:

I say "unhelpful" because there's no mention of what file is causing the error. Opening the files in "log/" also doesn't seem to indicate which file is causing the problems.

2. So what is the right way to cause a bunch of image files to break to a new line at specific places in the list of image files?

Also the w3 validator didn't like that I put an itemized list inside the Figure.

How do I fix these issues with the Figure?

Apparently the right way to put in line breaks is this:

Apparently the right way to deal with an itemized list inside a Figure is to put it outside the Figure, so I moved it to "More Information" at the end of the file.

Now the xml file validates:

elle@localhost ~/code/gimp-help/gimp-help-2 $ make validate-en *** Validating XML (en) ...
en: no errors.

Unless there are objections (and/or advice), I'm going to try to make and upload a patch. I do already have commit rights, fwiw.

Best, Elle

On 03/26/2017 04:21 PM, Julien Hardelin wrote:

In a tutorial, we use only some features of a dialog.

Gimp-help menus are not tutorials. They are references, and so, each feature of a dialog must be described. Some are common to several commands; they can be grouped in a common-features file.

You can't leave the Advanced option unexplained; you must explain, as you did here, why you can't develop explanations nor give an example. Or what will users think?

The Advanced options, along with Split View, Presets, and Preview, are common to *all* Color and Filter operations.

I don't think it's appropriate to add an explanation about the Advanced options to each and every Color and Filter page in gimp help.

To speak as plainly and clearly as possible, I will not add documentation regarding the Advanced options to the patch I'm working on for the desaturate menu.

In your file, we don't see that Luminance, Luma... belong to Mode.

I don't understand what you mean. Do you want a screenshot of the expanded desaturate drop down menu? Will this suffice to show that "Luminance, Luma . . . belong to Mode"? Or do you mean something else altogether?

No, it is not necessary to do more about these Mode options: "Five options are available " is enough

I don't understand what you mean. Do you want me to remove something that appears in the following file, and perhaps move it to a tutorial?

http://ninedegreesbelow.com/files/desaturate/8-18-desaturate.html

If you do want me to remove something from what appears in the above link, please be very, very specific, as I'm having a difficult time grasping what you are trying to say. My apologies, my communications skills seem to be at an all-time low.

Best regards, Elle

Julien

Le 26/03/2017 18:22, Elle Stone a crit :

On 03/26/2017 10:58 AM, Elle Stone wrote:

2- Mode
* Luminance
* Luma
* Lightness
* Average
* Value
3- Advanced options
* Apply filter to the layer's RAW pixels: with an example

If the above means that there should be documentation for the five Modes and *also* for "Advanced options/Apply filter to the layer's RAW pixels", I don't think adding documentation for "Advanced options Apply filter to the layer's RAW pixels" to the desaturate help (or any other help page for a specific editing option) is a good idea.

Just one example wouldn't do as it would be misleading. Between the gamma hack and the "color managed" option there are four possible combinations for the user to choose among, for each desaturate mode:

* The precise effect of each combination of "mode+using or not using the advanced options" does vary depending on whether the operation in question requests linearized RGB or RGB encoded using the sRGB TRC. So for example the effect when choosing Luminance is different from the effect when using Luma.

*The precise effect also varies depending on whether the image is at "linear" or "perceptual" precision.

* It seems, though I'm not 100% certain, that the effect also depends on whether there has been any previous "making of a new profile from a pre-existing non-GIMP-built-in profile", which in turn depends on whether the image had an embedded linear gamma ICC profile and whether the image has been promoted to 32f with linear precision and then possibly back to gamma precision, and on whether the user has chosen to automatically promote to 32f in Preferences.

In other words, accurately explaining the possible results from using the Advanced Color Options in the Desaturate dialog would require a flow chart in order to explain what happens when using which combination of the Advanced Color Options given X current precision, Y previous precision changes and Z original non-sRGB embedded ICC profile, combined with the choice amongst the various modes for converting to black and white that the user has made.

I'd very much prefer to not create such a flow chart, especially since the code for the relevant factors affecting the outcome of any given set of choices+previous-precision-changes is still in a state of flux.

Best, L
_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

http://ninedegreesbelow.com
Color management and free/libre photography

On 03/26/2017 03:35 PM, Elle Stone wrote:

Unless there are objections (and/or advice), I'm going to try to make and upload a patch.

Assuming that eventually I'll succeed in putting the modified desaturate.xml file into a shape that is acceptable for gimp-help, at that point I'll need to make a patch.

Here is a summary of the affected files, along with three questions:

Here are the files that I explicitly modified:

images/C/menus/colors/desaturate/desaturate.png src/menus/colors/desaturate/desaturate.xml

I added new image files to images/C/menus/colors/desaturate, as follows:

colors-desaturate-average-red-globe.png colors-desaturate-average-sunflower.png colors-desaturate-lightness-red-globe.png colors-desaturate-lightness-sunflower.png colors-desaturate-luma-red-globe.png colors-desaturate-luma-sunflower.png colors-desaturate-luminance-red-globe.png colors-desaturate-luminance-sunflower.png colors-desaturate-original-red-globe.png colors-desaturate-original-sunflower.png colors-desaturate-value-red-globe.png colors-desaturate-value-sunflower.png

Question 1: There is a long list of "po/..." files that are modified by building gimp-help after modifying/adding the above xml/png files.

Should these modified "po/..." files be added to the git commit?

Question 2: These image files are no longer used in the desaturate help, so perhaps these files should be rm'ed from git before I make a patch?

images/C/toolbox/colors-desaturate-brightness.png images/C/toolbox/colors-desaturate-luminosity.png images/C/toolbox/colors-desaturate-average.png images/C/toolbox/colors-desaturate-orig.png

Question 3: Is there anything different about the process of making a patch for gimp-help, compared to making a patch for gimp code? Anything to watch out for, or special commands, or anything along these lines?

Best, Elle

On 03/27/2017 01:58 AM, Julien Hardelin wrote:

The Advanced options, along with Split View, Presets, and Preview, are common to *all* Color and Filter operations.

I don't think it's appropriate to add an explanation about the Advanced options to each and every Color and Filter page in gimp help.

To speak as plainly and clearly as possible, I will not add documentation regarding the Advanced options to the patch I'm working on for the desaturate menu.

You don't need to write information here: only a link: Advanced options: Please see ..(link to a common-color-features.xml file to be created).

There are not, as far as I can tell, such links in the current documentation to features that are in common to all the dialogs. I've been using the current documentation as a model.

IMHO, there is no point in putting in a link to a file (help on Advanced options) that doesn't yet exist.

There is no point in writing documentation for the Advanced options because this code is still in a state of flux.

It's not even clear if this dialog will remain in the individual dialogs without specific user choice made in Preferences: https://bugzilla.gnome.org/show_bug.cgi?id=779620#c1

If someone else wants to write documentation for the Advanced options, of course I can't stop them. But I will not write documentation for the Advanced options, at least not until the code settles, and maybe not even then.

In your file, we don't see that Luminance, Luma... belong to Mode.

I don't understand what you mean. Do you want a screenshot of the expanded desaturate drop down menu? Will this suffice to show that "Luminance, Luma . . . belong to Mode"? Or do you mean something else altogether?

Mode: Five options are available:

OK, thanks! I don't think the original code (which I used as a pattern to follow) used , but if I overlooked this, my apologies.

So you want me to change this:

Five options are available:

to this

Mode: Five options are available

I don't understand what you mean. Do you want me to remove something that appears in the following file, and perhaps move it to a tutorial?

http://ninedegreesbelow.com/files/desaturate/8-18-desaturate.html

If you do want me to remove something from what appears in the above link, please be very, very specific, as I'm having a difficult time grasping what you are trying to say. My apologies, my communications skills seem to be at an all-time low.

I told you that, IMHO, your text can be accepted as it is. I am discussing about formatting the text. Time grasping is he same for me with all this discussion. If you don't understand again, please send me your xml file: I will return it with my propositions on formatting.

If my text can be accepted as it is, then I don't know what your feedback about "tutorials" vs "documentation" was about. So my apologies.

I think I'll just make a commit and deal with any remaining issues later.

Best, Elle

The current GIMP documentation is a pretty amazing work. It needs updating for 2.10.

I was asked to try to contribute to updating the GIMP color management documentation. I don't know docbook. I don't know XML.

I don't know the GIMP-manual way of writing patches, submitting commits, etc. I only know how these things are done wrt to patches, commits, and bug reports for GIMP code.

I do know the GIMP code base regarding color management pretty well. So I decided to try updating one small file (desaturate.xml) for the GIMP manual and see how it goes.

I strongly suggest that if there is any thought about getting more people on board with this GIMP-manual documentation, that something be done about making it a little easier for newcomers. I have spent what amounts to 3 full working days on this one file already, essentially all of which has been spent dealing with "non-content" stuff like XML, docbook, compiling GIMP-help, validating, and etc.

In my emails I've been trying to provide feedback on "how this experience has been for a potential new contributor". Hopefully this feedback might be helpful in figuring out how to smooth the process for the next person who tries to contribute to GIMP-manual.

Speaking for myself, I'd rather go to the dentist than work with docbook/XML, and I knew this *before* trying to update the desaturate help. Nonetheless I decided to work on the desaturate help because "someone" needs to update the GIMP color management documentation. The "desaturate" page was supposed to be my "learn how to do this" trial run at updating the documentation.

In future I'll just push patches that I write. I promise you I won't keep flooding this mailing list with questions.

On 03/27/2017 02:35 AM, Julien Hardelin wrote:

Unless there are objections (and/or advice), I'm going to try to make and upload a patch.

Assuming that eventually I'll succeed in putting the modified desaturate.xml file into a shape that is acceptable for gimp-help, at that point I'll need to make a patch.

I don't understand clearly. Will you push your changes directly to the git repository, or will you create a patch file that you will send to someone who will push it?

There is an open bug report on the desaturate page of GIMP-manual: https://bugzilla.gnome.org/show_bug.cgi?id=767763

When submitting patches that fix bugzilla bug reports for GIMP, the procedure is to attach the patch to the bug report. AFAIK, no one ever actually pushes such patches to git until given the go-ahead by Mitch, the GIMP maintainer.

My (possibly completely wrong) assumption is that there is a GIMP-manual maintainer who maintains similar control over what bug report patches are actually pushed to GIMP-manual. But if the usual procedure is to just push the changes, then that is something that needs to be made explicit, it seems to me.

When pushing patches for GIMP that fix particular bug reports, the patch references the bug report, as per this example: https://bugzilla.gnome.org/show_bug.cgi?id=780065#c7

So reasoning by analogy I assumed the correct procedure for the GIMP-manual desaturate bug 767763 was to upload the patch, wait for approval, and push the patch with a comment that references bug 767763.

But having never interacted with GIMP-manual before, perhaps my "reasoning by analogy" is completely wrong.

I've very new at this "pushing of commits" stuff as I've only had commit rights for a short time.

This whole conversation would be a lot easier to handle on IRC instead of relying on email.

Question 1:
There is a long list of "po/..." files that are modified by building gimp-help after modifying/adding the above xml/png files.

Should these modified "po/..." files be added to the git commit?

Normally, working on xml file don't modify the po files. git status shows only your new files in the untracked section and modified files (xml and images) in the index section. What have you done? perhaps a make status?

No, I have never done a "make status". I've never even heard of a "make status".

I made changes to the xml file and then recompiled the manual to see the resulting html file. Compiling the manual results in a lot of changed "po" files.

For some reason typing "git clean -xdf" doesn't get rid of the changed "po" files. Instead they need to be checked out at the command line. Which is tedious.

My apologies for saying this, but the procedures and command lines I've been given for compiling and modifying GIMP-help have been less than clear and doled out over time.

First I was given this command, which doesn't work (as I've already noted in a previous email):

./autogen.sh --without-gimp --ALL_LINGUAS="en xx", where xx refers to a language code, and so presumably ./autogen.sh --without-gimp --ALL_LINGUAS="en" should also work, but to be on the safe side I also tried ./autogen.sh --without-gimp --ALL_LINGUAS="en es".

Unfortunately at least on my computer ./autogen.sh --without-gimp --All_LINGUAS="en" won't compile, ends in an error message. As I've already explained this to you all, but no one responded.

Also unfortunately at least on my computer, the ./autogen.sh command won't take a prefix unless that prefix in fact has GIMP already installed in the prefix.

Otherwise no matter what prefix I give to autogen.sh, it tries to install in /usr/share/gimp/2.0/help, and as I try to avoid install development software as root, this fails (not to mention I don't want GIMP-manual writing to /usr). I already tried to tell this to you all in a previous email, but no one responded.

It was suggested to use kate for validating my xml code, but this apparently requires a version of kate that I can't install on my version of Gentoo unless I put an old version of kate (which version?) in a prefix.

I asked previously on this list (a couple of years ago) about what editor to use for XML, and didn't receive any helpful advice. So far I haven't really turned up any good information from the internet.

I use geany for writing c code and bluefish for writing html/php code.

Geany doesn't do autocomplete for XML (I don't use autocomplete when writing c code). bluefish does autocomplete for XML, but in the wrong place at the wrong time.

Geany doesn't even indicate the matching open/close tags, at least bluefish does do this.

Is there a good GTK XML editor? Putting in line breaks at the "80" column by hand is tedious.

I asked on this list about putting line breaks between images, but no one responded. Do you have any idea how much time and searching through the internet it took me to find an answer that would validate?

I asked a couple of other XML/docbook questions, and didn't get any answers. I did find answers by searching the internet, but it was very slow going.

I asked about how to validate the XML, and pointed out that the terminal output from "make validate-en" wasn't exactly easy to interpret, but no one responded to my inquiries. So I'm using the W3 validator instead.

A very kind soul finally offered these very much appreciated terminal commands:

make html-en
make validate-NN
make status-NN
make html-NN

where NN is the language code like en, it, de, etc.

Prior to these terminal commands, it was taking an incredibly long time to recompile gimp-manual every time I made a change to the xml file, to the point where I was just about ready to say "forget about it, this takes far too long".

You have to "checkout" all this po files

Question 2:
These image files are no longer used in the desaturate help, so perhaps these files should be rm'ed from git before I make a patch?

images/C/toolbox/colors-desaturate-brightness.png images/C/toolbox/colors-desaturate-luminosity.png images/C/toolbox/colors-desaturate-average.png images/C/toolbox/colors-desaturate-orig.png

You delete these images. They will appear as "deleted" in the index section of git status

Thank you.

Question 3:
Is there anything different about the process of making a patch for gimp-help, compared to making a patch for gimp code? Anything to watch out for, or special commands, or anything along these lines?

To answer to this question, I need to know what you mean with "patch".

See above. I mean a patch to attach to https://bugzilla.gnome.org/show_bug.cgi?id=767763

Best, Elle

On 03/27/2017 11:28 AM, Elle Stone wrote:

I will send you the "git status" terminal output and the xml file in a private email.

Hi Julien,

I did send you an email with the git status terminal output and the xml file. But there is a good chance you'll never get the email (there are problems with my email server).

So I also uploaded a patch to https://bugzilla.gnome.org/show_bug.cgi?id=767763. I can upload desaturate.xml if you like.

The "git status" terminal output can be downloaded from here: http://ninedegreesbelow.com/files/desaturate/git-status.txt

Best, Elle

On 03/27/2017 12:16 PM, Elle Stone wrote:

The "git status" terminal output can be downloaded from here: http://ninedegreesbelow.com/files/desaturate/git-status.txt

Never mind the git-status.txt. Starting with a fresh clone, the problem with the po files doesn't happen.

Elle

The patch I uploaded to
https://bugzilla.gnome.org/show_bug.cgi?id=767763 applies cleanly to a fresh clone of gimp-help.

gitg is happy.

The xml file validates.

The resulting html page (shown here: http://ninedegreesbelow.com/files/desaturate/8-18-desaturate.html) looks good.

Is there any reason why I shouldn't (try to) push this patch?

I've been working on this patch for four days now and I'd like to finish the project.

Best,
Elle