mirror of
https://gitlab.gnome.org/GNOME/gimp.git
synced 2025-07-03 17:33:25 +00:00
Misc typo fixes in plug-ins/
This commit is contained in:
parent
1577174739
commit
c1585d609b
16 changed files with 25 additions and 25 deletions
|
@ -29,7 +29,7 @@
|
|||
* Value Time Space
|
||||
* Coupled-Map Lattice cont. discrete discrete
|
||||
* Celluar Automata discrete discrete discrete
|
||||
* Diffrential Eq. cont. cont. cont.
|
||||
* Differential Eq. cont. cont. cont.
|
||||
*
|
||||
* (But this program uses a parameter: hold-rate to avoid very fast changes.
|
||||
* Thus time is rather continuous than discrete.
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. The name of the author may not be used to endorse or promote products
|
||||
* derived from this software withough specific prior written permission
|
||||
* derived from this software without specific prior written permission
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
||||
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
||||
|
|
|
@ -52,9 +52,9 @@ approximation, but a quite good one.
|
|||
The loop after that determines where the 4 actually representable colors lie
|
||||
along the line. After that, you simply need to determine which of those 4
|
||||
values your current pixel's dot product is closest to. Instead of doing a
|
||||
bunch of comparisions per pixel, the code computes the points along the line
|
||||
bunch of comparisons per pixel, the code computes the points along the line
|
||||
at which the decision would change (that's c0pt, halfpt and c3pt). This would
|
||||
still require 3 comparisions; by testing the middle point - which is halfpt -
|
||||
still require 3 comparisons; by testing the middle point - which is halfpt -
|
||||
first, one point is always excluded from consideration, which reduces the
|
||||
number of compares to two in all cases. No big deal, but hey, why not :)
|
||||
|
||||
|
@ -168,7 +168,7 @@ is selected per texture. That's why my original code doesn't support the
|
|||
3-color mode of DXT1 at all: I don't think it's useful in practice.
|
||||
|
||||
Not sure if all of this is useful to you or not, but I guess it might make
|
||||
sense to at least put this in a seperate text file or whatever, because
|
||||
sense to at least put this in a separate text file or whatever, because
|
||||
otherwise it's really quite hard to see what's going on in some places.
|
||||
|
||||
Cheers,
|
||||
|
|
|
@ -46,7 +46,7 @@ RGB_to_YCoCg (unsigned char *dst, int r, int g, int b)
|
|||
static inline int
|
||||
rgb_to_luminance (int r, int g, int b)
|
||||
{
|
||||
/* ITU-R BT.709 luma coefficents, scaled by 256 */
|
||||
/* ITU-R BT.709 luma coefficients, scaled by 256 */
|
||||
return ((r * 54 + g * 182 + b * 20) + 128) >> 8;
|
||||
}
|
||||
|
||||
|
|
|
@ -219,7 +219,7 @@ dxtblock_init (dxtblock_t *dxtb,
|
|||
dxtb->alphamask = 0;
|
||||
|
||||
if(flags & DXT_PERCEPTUAL)
|
||||
/* ITU-R BT.709 luma coefficents */
|
||||
/* ITU-R BT.709 luma coefficients */
|
||||
dxtb->metric = vec4_set(0.2126f, 0.7152f, 0.0722f, 0.0f);
|
||||
else
|
||||
dxtb->metric = vec4_set(1.0f, 1.0f, 1.0f, 0.0f);
|
||||
|
|
|
@ -111,9 +111,9 @@
|
|||
PSD_LLL_LINKED_LAYER_3 "lnk3" - * Linked layer 3rd key *
|
||||
|
||||
* Merged Transparency *
|
||||
PSD_LMT_MERGE_TRANS "Mtrn" - * Merged transperency save flag (?) *
|
||||
PSD_LMT_MERGE_TRANS_16 "Mt16" - * Merged transperency save flag 2 *
|
||||
PSD_LMT_MERGE_TRANS_32 "Mt32" - * Merged transperency save flag 3 *
|
||||
PSD_LMT_MERGE_TRANS "Mtrn" - * Merged transparency save flag (?) *
|
||||
PSD_LMT_MERGE_TRANS_16 "Mt16" - * Merged transparency save flag 2 *
|
||||
PSD_LMT_MERGE_TRANS_32 "Mt32" - * Merged transparency save flag 3 *
|
||||
|
||||
* Filter Effects *
|
||||
PSD_LFFX_FILTER_FX "FXid" - * Filter effects (?) *
|
||||
|
|
|
@ -143,9 +143,9 @@
|
|||
#define PSD_LLL_LINKED_LAYER_3 "lnk3" /* Linked layer 3rd key */
|
||||
|
||||
/* Merged Transparency */
|
||||
#define PSD_LMT_MERGE_TRANS "Mtrn" /* Merged transperency save flag (?) */
|
||||
#define PSD_LMT_MERGE_TRANS_16 "Mt16" /* Merged transperency save flag 2 */
|
||||
#define PSD_LMT_MERGE_TRANS_32 "Mt32" /* Merged transperency save flag 3 */
|
||||
#define PSD_LMT_MERGE_TRANS "Mtrn" /* Merged transparency save flag (?) */
|
||||
#define PSD_LMT_MERGE_TRANS_16 "Mt16" /* Merged transparency save flag 2 */
|
||||
#define PSD_LMT_MERGE_TRANS_32 "Mt32" /* Merged transparency save flag 3 */
|
||||
|
||||
/* Filter Effects */
|
||||
#define PSD_LFFX_FILTER_FX "FXid" /* Filter effects (?) */
|
||||
|
|
|
@ -965,7 +965,7 @@ save_image (GFile *file,
|
|||
gimp_progress_init_printf (_("Exporting '%s'"),
|
||||
gimp_file_get_utf8_name (file));
|
||||
|
||||
/* Open file and write some gloabl data */
|
||||
/* Open file and write some global data */
|
||||
tif = tiff_open (file, "w", error);
|
||||
|
||||
if (! tif)
|
||||
|
@ -1067,7 +1067,7 @@ save_image (GFile *file,
|
|||
if (tsvals->save_thumbnail)
|
||||
save_thumbnail (tsvals, image, tif);
|
||||
|
||||
/* close file so we can savely let exiv2 work on it to write metadata.
|
||||
/* close file so we can safely let exiv2 work on it to write metadata.
|
||||
* this can be simplified once multi page TIFF is supported by exiv2
|
||||
*/
|
||||
TIFFFlushData (tif);
|
||||
|
|
|
@ -100,7 +100,7 @@ static int
|
|||
get_hue (guchar *rgb)
|
||||
{
|
||||
double h, v, temp, diff;
|
||||
/* TODO : There seems to be some typoes in the comments here.
|
||||
/* TODO : There seems to be some typos in the comments here.
|
||||
* Ask vidar what he meant.
|
||||
* */
|
||||
if ((rgb[0] == rgb[1]) && (rgb[0] == rgb[2])) /* Gray */
|
||||
|
|
|
@ -2148,7 +2148,7 @@ main()
|
|||
<Literal>RUN-NONINTERACTIVE</Literal>) discriminates between
|
||||
user-driven or scripted calls. In the case of gimpfu-based plug-ins,
|
||||
it is automatically taken care of internally -- interactive calls
|
||||
will dismiss all the remaning arguments, and an interface will be
|
||||
will dismiss all the remaining arguments, and an interface will be
|
||||
presented (when possible) to the user. The plug-in core Python
|
||||
function (<Literal>echo()</Literal> in this case), never has to deal
|
||||
with it.</Para>
|
||||
|
|
|
@ -510,7 +510,7 @@ class AirBrushTool():
|
|||
class AbstractStrokeTool():
|
||||
|
||||
def draw(self, layer, strokes, color=None):
|
||||
# We need to mutiply every point by 3, because we are creating a path,
|
||||
# We need to multiply every point by 3, because we are creating a path,
|
||||
# where each point has two additional control points.
|
||||
control_points = []
|
||||
for i, k in zip(strokes[0::2], strokes[1::2]):
|
||||
|
@ -1370,7 +1370,7 @@ class SpyroWindow(gtk.Window):
|
|||
|
||||
add_horizontal_separator(vbox)
|
||||
|
||||
self.progress_bar = gtk.ProgressBar() # gimpui.ProgressBar() - causes gimppdbprogress errror message.
|
||||
self.progress_bar = gtk.ProgressBar() # gimpui.ProgressBar() - causes gimppdbprogress error message.
|
||||
self.progress_bar.set_size_request(-1, 30)
|
||||
vbox.add(self.progress_bar)
|
||||
self.progress_bar.show()
|
||||
|
|
|
@ -27,7 +27,7 @@
|
|||
; Copyright (C) 1997-1999 Sven Neumann <sven@gimp.org>
|
||||
;
|
||||
;
|
||||
; Blends two or more layers over a backgound, so that an animation can
|
||||
; Blends two or more layers over a background, so that an animation can
|
||||
; be saved. A minimum of three layers is required.
|
||||
|
||||
(define (script-fu-blend-anim img
|
||||
|
|
|
@ -141,7 +141,7 @@
|
|||
; Only useful in interactive mode. It will create a widget in the control
|
||||
; dialog. The widget is a combo-box showing all enum values for the given
|
||||
; enum type. This has to be the name of a registered enum, without the
|
||||
; "Gimp" prefix. The second parameter speficies the default value, using
|
||||
; "Gimp" prefix. The second parameter specifies the default value, using
|
||||
; the enum value's nick.
|
||||
;
|
||||
; Usage:
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
but it was probably ten times bigger that the program it was supposed to
|
||||
be embedded in. There would also be thorny licencing issues.
|
||||
|
||||
So, the obvious thing to do was find a trully small interpreter. Forth
|
||||
So, the obvious thing to do was find a truly small interpreter. Forth
|
||||
was a language I had once quasi-implemented, but the difficulty of
|
||||
handling dynamic data and the weirdness of the language put me off. I then
|
||||
looked around for a LISP interpreter, the next thing I knew was easy to
|
||||
|
|
|
@ -54,7 +54,7 @@ X T_LAST_SYSTEM_TYPE=14
|
|||
| } _string;
|
||||
|
||||
We can use _svalue to hold the actual pointer and _keynum to hold its
|
||||
length. If we couln't reuse existing fields, we could always add other
|
||||
length. If we couldn't reuse existing fields, we could always add other
|
||||
alternatives in union _object.
|
||||
|
||||
We then proceed to write the function that actually makes a new block.
|
||||
|
|
|
@ -82,7 +82,7 @@ static gint sel_x1, sel_y1, sel_x2, sel_y2;
|
|||
static gint has_sel, sel_width, sel_height;
|
||||
static SELVALS selVals;
|
||||
static GeglSampler *sel_sampler;
|
||||
static gboolean retVal = TRUE; /* Toggle if cancle button clicked */
|
||||
static gboolean retVal = TRUE; /* Toggle if cancel button clicked */
|
||||
|
||||
MAIN ()
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue