Re: Linguistic work on rgbPaint.
tisdag den 7 december 2010 klockan 21:56 skrev Justin B Rye detta:
> 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.
Let us suppose we have an image, being 800x400 in size. The thumbnail
will be linearly scaled down to 40x20 in the default setting, since
the transformation is angle preserving (all distances are changed by an
identical proportion). Any unused part of the targeted 40x40 icon stamp,
viz. not covered by the scaled image, will be left as lightly greyish.
When left-clicked, the image represented by the thumbnail [sic] will be
deposited in full size above the canvas. In a proper sense, there is no
expansion of the thumbnail back to the original image. Rather, only a
mathematical transformation is applied to the original image, in order
to produce an icon small enough to fit the space allotted in each stamp
The container in question consists of a square scratch area, whose size
is determined by the option "-thumb", as well as inert margins around
the inset thumbnail. The top and bottom margins are considerably broader
than the right and left margins (and right margin being tighter than
the left margin!), thus lending the stamp a noticeably oblong shape.
Not without resemblance to postal stamps of kings and queens, when stamps
usually were slightly taller than they were wide, but in rgbPaint the
container is more oblong than Queen Elisabeth ever was.
As you said, this all is what the layman will be intuitively be expecting.
The above details only account for the representation behind the curtain.
I used three images to check this. Their transformations were (-thumb 80):
800x400 --> 80x40
400x800 --> 40x80
400x400 --> 80x80
> >> | 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.
I do not like "fuzzy" at all. Of course GIMP is omnipresent, but I
for one would avoid "fuzzy" here. I come to think of a smeared
contour or a diffuse outline, rather than a diluted colouring.
> >> | [...] 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
I was taken aback by "stock-sun.svg" once I did discover the naming.
But on the other hand, the diagonal strokes are in fact longer,
so the compass-rose falls back at closer inspection. The icon is
very close to being square in shape. Still, the colour gradient
prevents my association to close in on a solar depiction, without
the hint that is..
> 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.
Or amended akin to "ordered there as they are listed here"?
Mats E A