Re: Linguistic work on rgbPaint.
Dear Justin,
I will comment here, but I will submit my patch in an answer to your
follow-up letter. That seems better at this moment.
fredag den 3 december 2010 klockan 21:15 skrev Justin B Rye detta:
> Mats Erik Andersson wrote:
> | -thumb size
> |
> | Set largest width (equal to height) of any stamp thumbnail.
> | Permitted values for size are in the range 32 to 256 pixels.
> | Default is 40.
>
> Set size in pixels that stamp thumbnails should be reduced to
> (if larger). The default is 40 pixels on a side; permitted
> values are in the range 32???256 pixels.
>
> (If the file is 50x200, does it rescale to 10x40 or just to 40x40?)
The image is scaled as a whole to fit a thumbnail of size n x n.
Thus showing as 10x40 if that be the case.
> | In this panel an action is selected. The available actions are best
> | named in subgroups, according to character:
>
> Here and later you don't need to talk about the process of
> describing them when you could be getting on with describing them!
On the spot!
> | The second group determines a main mode upon which the program acts.
> | When in Paint mode, a pencil will act as pointer symbol, while Fill
> | mode displays as a bucket being emptied. Selection mode uses more
> | than one icon and is compound, so it will be better explained in the
> | section called ???Making and using selections???.
>
> The second group picks the main mode rgbPaint should enter. When it
> is in Paint mode, the cursor will become a pencil symbol, while Fill
> mode displays as a bucket being emptied. Selection mode is more
> complicated, using more than one icon - see the section ???Making
> and using selections???.
I am not yet in full control of the way Docbook augments titles
of sections to which references are being made. Some additional
text is often inserted. That is the reason I decided to use
"xreflabel" for the panels. The passage above and a few more will
need further fine tuning at the final stage. It is the resolving
of "xref" that plays its tricks.
> | Marking
> |
> | shows one out of four corner icons. They all indicate how the
> | next corner will be used to lay down a rectangle together with
> | the previously set corner. To get a feeling for this, it is best
> | to experiment a little by moving the pointer around.
>
> I don't follow the "how the next corner will be used" bit. I
> suppose "how the next point selected will be used"? I'm guessing
> that the mechanic is you click to select the first point, then if
> (say) your cursor is below and to the left of that point it displays
> an "L" icon.
Correct. The only single character ASCII art seems here to be "L".
> | Here the user chooses brush and colour for painting, or colour only
> | for flood filling. There are ten different brushes, six solid and
> | four thin ones. A solid brush can give a square or a round outline,
> | each in one out of three differing thicknesses. The buttons for
> | brushes are collected at the upper part of the panel.
>
> There may be better words for the "solid/thin" opposition, but I'm
> not thinking of them. Broad versus thin? Solid versus linear?
Thick/thin, filled/thin? A broad pencil could be sparse. Right?
The distinction I am aiming at is whether the pencil stroke is
solid or speckled.
> | This extra panel, at the bottom of the program window, comes to life
> | only if rgbpaint was summoned using the command line switch -stamps,
> | and with existing image files to follow. The displayed size of any
> | thumbnail image is determined by the switch -thumb, or is set to 40
> | pixels, in width as well as in height.
>
> This extra panel, at the bottom of the program window, comes to life
> only if rgbPaint was launched using the command line switch -stamps,
> followed by the names of existing image files. The displayed size
> of any thumbnail image is determined by the switch -thumb, or
> defaults to 40 pixels in both width and height.
>
> (This seems to say that by default a 4x20 image will be scaled *up*
> in an aspect-ratio-distorting fashion.)
Yes it will be.
>
> Oh, why is it <command>&prog;</command> here rather than &software;?
The software is written in camel case by its authors, while the program
name is written in lower case. I hope to have written &prog; when I intended
the behaviour of the program itself. I will have to double-check this.
> | 1 .. 9
> |
> | Change scaling to fixed levels.
>
> Hang on, not 0?
The key '0' causes no action that I know of. No normalisation; nothing.
> | Home
> |
> | Go to the top of the canvas.
>
> I can imagine the asymmetry of Home and End catching people out...
Luckily we stay innocent in this matter.
> | Tailored task icons
> |
> | There is a built-in possibility to tailor the optics of the task
> | icons, as they appear in the Task panel. This is mostly an issue for
> | the administrator of a kiosk system or similar, not a task for the
> | casual user. It does make sense to use this in the command string
> | registered with the Debian menu system for rgbpaint. At least for
> | systems where users are expected to access the program only that way.
>
> This has suddenly got a bit hard to follow. Um...
>
> Customised task icons
>
> (Or can I safely change that when it seems to be tied to a filename?)
>
> There is a built-in facility for customising the appearance of the
> task icons as they appear in the Tasks panel. This is mostly an issue
> for the administrators of kiosk systems or similar, not for the casual
> user. It can also make sense to use this in the rgbPaint command
> string registered with the Debian menu system, at least for systems
> where this is the only way users are expected to access the program.
You are sound and safe.
>
> | The command line switch -svg allows the specification of a directory,
> | where particular vector image files are searched for. Their names are
> | all of the form "stock-XXX.svg", and as the name imply, they must be
> | of SVG format. The string XXX takes exactly one of the following
> | values: new, open, save, saveas, cut, copy, paste, undo, redo, text,
> | paint, fill, select, sun, or zoom. All these are needed for the
> | expected functionality. It is straightforward to deduce the meaning
> | of each name, simply by looking at the standard layout.
>
> What's "sun"? Should it be "pan"?
In fact not. The fifteen file names are hard coded into the executable.
One of them is "stock-sun.svg". The default icon is a small radiating sun.
Thus the name. I intended to tie the default appearance of these icons
to their hard coded names when I wrote "straightforward to deduce",
but you make me doubt whether it needs pointing out.
>
> The command line switch -svg allows a directory to be specified
> where rgbPaint should look for particular vector image files in
> SVG format. Their names must all be of the form "stock-XXX.svg",
> where the XXX is one of the following words: new, open, save,
> saveas, cut, copy, paste, undo, redo, text, paint, fill, select,
> pan, or zoom. Each will provide an icon for the obvious
> corresponding function, and all must be present.
>
> (Does it mean that if one is missing rgbPaint will crash, or ignore
> the directory, or what?)
This is an odd point. When a corresponding vector image is missing,
some icons will be replaced by a pencil, while others are keeping
their default instances. The program itself starts without regrets,
but the user might need to remember the order of the icons within
the Tasks panel.
These latter icons are only four in number: paint, fill, select, sun.
Now that you have located this malfunction, I will consider patching
it for the Debian package.
> | Manual Authors
> |
> | The original manual page stub was taken as starting point for a
> | complete rewrite as Docbook source, and was substantially extended by
> | Mats Erik Andersson and Justin B Rye.
>
> You've done all the heavy lifting, I'm just buffing the paintwork.
I find your name well justified. If not for other reason, it expresses
my gratitude. At least the readers on this list will be able to identify
that connotation!
Best regards,
Mats E A
Reply to: