Re: Linguistic work on rgbPaint.
No attachments this time, since I'm already working on a sequel.
Mats Erik Andersson wrote:
> skrev Justin B Rye detta:
>> (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.
Okay; but later you say something that seems to contradict this:
>> (This seems to say that by default a 4x20 image will be scaled *up*
>> in an aspect-ratio-distorting fashion.)
> Yes it will be.
I'm hoping you mean "yes it will be scaled up" (that is, the
thumbnail will be 40 pixels across whether the original was 50x200
or 4x20), not "yes it will distort the aspect-ratio to make it
precisely 40x40 regardless of its original proportions". Or to put
it another way, if necessary the picture is first "squared off" with
transparency before being scaled up or down.
This probably doesn't need any clarifying for people who are looking
directly at the effect - I'm just making sure I understand it.
>> | 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.
Oh, I'd misunderstood it as "thin" meaning "narrow, linear"; I
should have remembered the designs on the buttons themselves, which
make it clear that it's "thin" as in "tenuous, sparse"... The GIMP
calls this sort of brush "fuzzy", although it seems odd to think of
the one-pixel brush as falling in that category.
>> | [...] 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.
If the icon is a little eight-rayed "move in any direction" design I
can understand the idea. But it's really more of a compass-rose
than a sun, and none of the others are named in this style -
otherwise they'd have names like "stock-floppy.svg". So your
reference to the necessity of "looking at the standard layout" made
sense, and we need to tone down the optimism of my revised version:
>> 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.
How about if we say "Each will provide an icon for the corresponding
function in the top panel"? That should be enough of a hint that
they're in the same order as they appear on the screen.
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package