On 25.06.2005, at 11:53, Sven Neumann wrote:
You could start by making a nice proposal, perhaps including a mockup
of how the user interface for this should look like and how it should
behave.
I guess Pedro has seen the Photoshop interface which does pretty
much that (and more).
Servus,
On 03.03.2005, at 20:09, GSR - FR wrote:
With your idea, calculating the full 3000*3000 with a depth of 3 is
like calculating 9000*9000 (81 million pixels in RGB, 243*10^6 bytes
plus overhead) and in time it should be 9 times the 3000*3000 non
adaptive version plus the scale operation. To avoid
On 02.03.2005, at 00:23, GSR - FR wrote:
Yes, radial rainbow hoop gradient (linear 6 pixel to right sawtooth)
without supersampling it paints mostly red and with it shows the muddy
colour mix you would get if you render big and scale down:
On 02.03.2005, at 13:29, Sven Neumann wrote:
Sorry, but I don't see your point. It has been show that supersampling
makes sense for some corner cases. It is off by default and users can
activate it in case they run into one of the corner cases. Of course
it could be faster but where's your
On 02.03.2005, at 20:22, GSR - FR wrote:
IOW, supersampling is nice for the small set of cases in which it
really matters, otherwise it is going to be slower always. Of course,
it is going to be faster in many cases than full sampling and scaling
down. If anybody figures a better method than user
On 01.03.2005, at 16:42, GSR - FR wrote:
GSR (?) already gave such an example.
It might be worth considering only supersampling when the end of a
segment is
a different color than the start of the next one.
Supersampling is to avoid aliasing, which is not caused only by those
discontinuities but
On 28.02.2005, at 21:15, Sven Neumann wrote:
Since supersampling is in libgimpcolor, it will probably be difficult
to improve without breaking backwards compatibility. But of course
noone forces us to actually use the functionality in libgimpcolor...
But, and this is one of many upsides of
On 27.02.2005, at 02:55, Manish Singh wrote:
Only to those containing sources which refer to automatically
generated headers, about 3 or 4.
No, we should add it to all of them.
Agreed. Consistency is good.
In fact, it already *is* in some of them.
So here's what I'm currently doing. I took the 4
On 27.02.2005, at 03:09, Manish Singh wrote:
But that's still not the cure for all possible problems that
may arise by moving the header (e.g. from app to libfoo).
Anyway, that's better than nothing...
There's no getting around updating the Makefile.am for that. With your
naive solution, it
On 27.02.2005, at 01:04, Sven Neumann wrote:
I have eliminated last_visited from the gradient struct. Instead the
caller of gimp_gradient_get_color_at() may now do the same
optimization without any caching in the gradient itself. I very much
doubt that this makes any difference though. Perhaps if
On 27.02.2005, at 14:31, Sven Neumann wrote:
Dithering makes heavy use of GRand and as long as the random number
generator is shared between the threads... I wonder if it actually
makes sense to add the overhead of per-thread data initialization or
if we should rather replace the use of a random
On 27.02.2005, at 15:19, Sven Neumann wrote:
It is called once per tile. Your approach probably makes sense as long
as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new()
initializes the random number generator from /dev/urandom which is
probably too expensive to be done once per
On 27.02.2005, at 15:19, Sven Neumann wrote:
It is called once per tile. Your approach probably makes sense as long
as don't use g_rand_new() but g_rand_new_with_seed(). g_rand_new()
initializes the random number generator from /dev/urandom which is
probably too expensive to be done once per
Hija,
this is my suggested patch for getting the speeds improvements
as mentioned in the other thread by having a thread-local PRNG
initialized with a seed from the still existing blend tool local
RNG.
It looks bigger than it is because I took the liberty to remove
the nasty special casing on the
On 27.02.2005, at 16:42, Robert L Krawitz wrote:
In addition to being very slow, this will also yield noisy results.
There are a lot of dither algorithms that are both much faster and
yield better results. While you may not need full-blown
Floyd-Steinberg or EvenTone dithering for this purpose
On 27.02.2005, at 17:24, Sven Neumann wrote:
Incidentally this is exactly what I'm testing right now. ;=)
Incidentally that is what the code in CVS is doing. Looks like we were
working on the same code. We should perhaps start using mutexes on the
source code ;)
Heh, you did not only do the same
On 27.02.2005, at 17:19, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
As for your claim, dithering is completely invisible, try this image,
which
is done with gimp's blend and no dithering:
http://data.plan9.de/d0.png
That image features quite visible banding effects - you will have
On 27.02.2005, at 20:01, Robert L Krawitz wrote:
OK. The code Daniel posted shouldn't be too hard to convert. The
only thing it needs is to have the absolute row and column, to index
into the matrix.
That hasn't made it into CVS because Sven was faster...
Here's the current code:
static void
On 28.02.2005, at 00:25, Sven Neumann wrote:
The histogram code does already use the threaded pixel-processor. You
think we could simplify the code? IMO the current solution isn't all
that bad. But I haven't benchmarked it so I don't really know...
I tried to introduce the per-thread
On 26.02.2005, at 02:44, Jay Cox wrote
:
Dual 2.5ghz g5 mac, mac os x 10.3.8
CVS gimp Changelog revision 1.10539
Linear Gradient blend on a 3000x3000 pixel image (Dithering on)
1 Processor: 7.98 seconds1x
2 processors: 5.20 seconds1.5x
3 processors: 5.23 seconds1.5x
Hija,
I'm throwing the following fix for consideration. The
problem is that by standard headers are looked for in
various locations under the srcdir, however there're
also header files which are automatically generated
and (rightfully) put into objdir but are not searched
for there. This breaks
Hija,
just curious, is it expected that configuration of a GIMP
build will fail if configure cannot find a C++ compiler?
...
checking for dlfcn.h... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking
On 26.02.2005, at 20:23, Sven Neumann wrote:
Looks like the wrong fix to me. Instead we should change the Makefiles
to look for the generated files in the right spot (and .. isn't the
right spot).
Actually .. is the right spot since make is moving in and out of
the objdir. However I can see why
On 26.02.2005, at 23:44, Sven Neumann wrote:
What's wrong with $(top_builddir)?
Ho hum. That's a relative path as well, so instead of
-I.. that would be -I$(top_builddir)/app which gets
expanded to -I../../app . We could do that but I don't
really see the big advantage instead of just using my
On 26.02.2005, at 23:44, Sven Neumann wrote:
BTW, the problems you are seeing only apply to builds from CVS. The
tarball has all the generated source files, so everything is where
the Makefiles are looking for it. It appears though that we do indeed
require to build a CVS checkout in the srcdir.
On 26.02.2005, at 23:44, Sven Neumann wrote:
Anyway, libtool is using objdir for it's internal object
management which is for instance some .libs directory on Linux
machines, so we can pretty much forget about using this. Instead
we'd need a new variable into the game and the closest I can
think
On 27.02.2005, at 01:14, Sven Neumann wrote:
We would probably have to add this to all Makefile.am in the app
subdirs then?!
Only to those containing sources which refer to automatically
generated headers, about 3 or 4.
There are .cvsignore files that cover these files. Building in the
srcdir is
On 27.02.2005, at 01:19, Sven Neumann wrote:
just curious, is it expected that configuration of a GIMP
build will fail if configure cannot find a C++ compiler?
That question would better be asked on the autoconf list. While you
are on it, ask them why there are checks for a fortran compiler. I
On 27.02.2005, at 02:50, Manish Singh wrote:
We should do -I$(top_builddir)/app. This avoids needing to care about
how deep the directory is, in case the directory is moved elsewhere.
But that's still not the cure for all possible problems that
may arise by moving the header (e.g. from app to
On 21.02.2005, at 03:14, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
Forcing the NPTL implementation to degrade to legacy
BTW, is this 2.4 or 2.6?
Linux ulli 2.6.9-k8 #31 SMP Wed Nov 3 10:58:29 CET 2004 x86_64 GNU/Linux
32bit userland from Debian unstable.
Servus,
Daniel
PGP.sig
On 21.02.2005, at 19:07, Jay Cox wrote:
I'm not sure what system the benchmark is being run on, but the cache
line size on a P4 is 128Byes (most other systems have smaller cache
line
sizes). A simple test to see if this is the problem would be to change
the tile allocation code to allocate an
On 20.02.2005, at 14:09, Sven Neumann wrote:
There are very clear ideas on how to do it.
Hm, must have missed that...
Someone just needs to sit down and write the script (or dig out
script-fu-bench.scm which is what we used to use a long time ago).
You'd still do me a favor if you would try
Hija,
while building GIMP for the threading test I noticed that
builds where the source dir is not the object directory are
slightly broken; in particular the intlfoo magic in the tips
directory doesn't take the SRCDIR into account and thus failes
badly and the following (generated) files are
On 20.02.2005, at 14:09, Sven Neumann wrote:
You'd still do me a favor if you would try current CVS and told me
whether it feels faster or not.
It's slower, measurable and reproducible slower.
As a benchmark I used a gradient fill in a 3000x3000px (68.8M)
image. I get consistently times of 8s for
On 20.02.2005, at 19:29, Sven Neumann wrote:
Anyone here who can fix that with some Makefile-fu?
Why do you think those files would be looked for in $(srcdir)?
Because the compiler complained that it couldn't find the
files in $(srcdir), so what I did was copying them over
one-by-one from the
On 20.02.2005, at 21:55, Sven Neumann wrote:
As a benchmark I used a gradient fill in a 3000x3000px (68.8M)
image. I get consistently times of 8s for 1 thread and between
9.2s and 9.6s for 2 threads. With a running application, after a
restart -- doesn't matter.
What is strange though, is that it
if perhaps the kernel is
right and using two CPUs would actually cause more overhead than it's
worth?
Hm, it is using NPTL, e.g. if I set it to 8 threads I'll have:
egger31344 2.1 14.5 219412 149008 pts/0 Sl+ 23:10 0:05
/opt/gimp-mp-test/bin/gimp-2.3
egger31344 10.8 14.5 219412
On 20.02.2005, at 23:47, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
Linux will not keep two threads running on a single cpu if both are
ready
and nothing else is running, regardless of locality etc., as the kernel
lacks the tools to effectively decide wether threads should stay on a
cpu
or
On 16.02.2005, at 22:42, Sven Neumann wrote:
It would be interesting to know if this actually gives a noticeable
speedup on SMP systems. Would be nice if one of you could give this
some testing. Please try to do gradient blends (w/o adaptive
supersampling!) on large images. Changing the number of
On 13.02.2005, at 22:10, Sven Neumann wrote:
I couldn't resist and spent some time on the threaded pixel-processor
code . The first part of the TODO I posted yesterday is done, the code
has been ported to gthread. This makes the thread functionality
available on all platforms supported by
On 13.02.2005, at 22:43, Sven Neumann wrote:
Doing benchmarks is exactly what would have to be done at this
point. The main problem is probably what to use as a benchmark.
One could write a script-fu and run that using batch-mode.
I've been using the coffee stain effect fu in the past but
this is
On 06.02.2005, at 02:46, Hal V. Engel wrote:
I probably should have said that I believed that the problems I had
with GTK 2.4 were likely caused by the RPMs I was using (user local
bin) as I had not tried building it myself. So this is a SuSE 9.1
specific problem. There have been some rather
On 20.01.2005, at 22:07, Sven Neumann wrote:
Please don't commit this before we have finished this discussion (that
we should have had before you wrote the first line of code).
Typically a proof of concept implementation is more than
welcome, so your attitude is hardly understandable.
That sounds
On 09.01.2005, at 18:39, William Skaggs wrote:
1) New rectangle select tool that allows adjustment of rectangle after
creation. (Implemented in my personal tree with the exception of
keybindings. Implemented as a separate tool, so it can be tested
and improved without losing the standard
On 10.01.2005, at 21:38, Sven Neumann wrote:
[ good ideas removed ]
I'd appreciate if we could gather such good topics for
documentation in a central place. Bugzilla would be an
idea but this seems more like a great chance for the Wiki:
Let's make that an itemizedlist and put it on the Wiki
On 06.12.2004, at 19:44, Joao S. O. Bueno Calligaris wrote:
But nowadays, who seriously uses it?
I do. It's not very useful to mask an object in a low
contrast environment but it works perfectly well for
instance to mask an digitally photographed object against
a somewhat distant background to
On 13.11.2004, at 08:48, Manish Singh wrote:
shm is a special case. I'm talking about allocating highmem
segments.
So, what is the userspace API for this?
AFAIK there's no direct userspace helper to address highmem
segments; one can only map them in the Linux kernel and
provide them to userspace
On 13.11.2004, at 07:45, Laxminarayan Kamath wrote:
t's a whole bunch of contortions, and all pointless since amd64
hardware is competitively priced these days.
please dont concentrate only on those who can change pcs like shirts,
concentrate on us poor people too. ;)
Actually my focus is on
On 12.11.2004, at 15:51, Sven Neumann wrote:
That allows you to stuff more RAM into your box but you can still only
give up to 4GB to a single process simply because you cannot handle
more than 4GB in a 32bit address space.
You can, but not using the typical APIs. This is pretty important
for
On 24.10.2004, at 20:36, Sven Neumann wrote:
The help system has always been designed that way. The problem was
with the way the help pages get generated from the DocBook sources.
During that process empty pages were generated instead of no
pages. Thus, the language fallback in the help system
On 06.10.2004, at 19:45, Tor Lillqvist wrote:
Again this c't magazine asking for permission to put GIMP (for
Windows, presumably) on a CD-ROM. Could some of our German developers
try to tell them once more that they don't have to ask me (or anybody
else) for permission. (And on the other hand,
On 03.10.2004, at 17:51, Sven Neumann wrote:
We can of course add a gimprc option for the Help button but my
question is if it is a good idea to add such a button per default.
I like your idea very much.
It might make sense to get an opinion from the usability guys
though. Maybe have any
On 26.07.2004, at 17:12, Roman Joost wrote:
I was digging a bit around in the net to find out, which word is more
used for the Toolbox: Werkzeugfenster or Werkzeugkasten. The most
tutorials I found are using Werkzeugkasten, even Sven uses
Werkzeugkasten in his book. But Werkzeugfenster is often
On 22.07.2004, at 23:19, Simon Budig wrote:
We use the gettext library to determine what language the text in our
user interface should be. In fact gettext does all the hard work for
us.
Not quite but almost. :) The choice of language is expressed by
setting environment variables. Those are
On 18.07.2004, at 03:07, Christopher W. Curtis wrote:
And we want it rendered using glitz!
http://freedesktop.org/Software/glitz
... but seriously, does anyone think it's possible to offload
processing to the GPU? Is that part of the GEGL pipe goals? I didn't
see anything at the site in the
On 07.06.2004, at 20:04, William Skaggs wrote:
The main reason not to use convmatrix is that internally it always
does a 5x5 convolution, regardless of the matrix entries. This means
it should take almost three times as long as the 3x3 convolution in
blur.c; in fact, a little testing on a 5000 x
On 04.06.2004, at 13:37, Ellen Reitmayr wrote:
7. German translation
- Some words are misleading
We've had many iterations through the translation already and
in many cases (I at least) were not quite sure how to translate
some phrases.
If you could come up with some suggestions I'd certainly
On 04.06.2004, at 17:05, Ellen Reitmayr wrote:
uuu, that's a translation problem!
in english the button says: 'Create Selection from Path'
in german it says: 'Pfad aus Auswahl' (Create Path from Selection)
I think Daniel Egger is the right one to tell that, no?
Any German speaker is welcome
On 04.06.2004, at 16:20, Carol Spears wrote:
If you could come up with some suggestions I'd certainly
appreciate that.
okay, how does photoshop translate their stuff into german?
I expect they have a highly paid team of artists and
professional translators.
Or do you mean that we should copy
On Mar 17, 2004, at 5:53 pm, Aaron Voisine wrote:
Here are the links. It's hosted on a cable modem, so
be gentle.
Now this is really cool!
I'd really appreciate if we could put them somewhere
on the official servers. If not, would it be an option
for you to open a sourceforge project?
Servus,
On Mar 14, 2004, at 12:54 pm, Sven Neumann wrote:
Such an image file is kept seperate from the rest of the system. So
there's no chance that whatever library you add there could collide
with other software on the system. Assumed that I understood this
correctly, but that's what I have been told
On Mar 12, 2004, at 1:59 pm, Sven Neumann wrote:
What I dislike about this is that the base for the references in the
XML files is not the directory the XML file is located in. So
there's some special knowledge needed to interpret the references.
I suggest this structure intead:
On Mar 11, 2004, at 12:09 pm, Sven Neumann wrote:
Because our experience in the pre-releases has shown that it is
extremely difficult to provide a working spec file. And even if we
managed to provide on, it would be specific for a particular
distribution. So we should either provide spec files
On Mar 11, 2004, at 4:52 pm, Dave Neary wrote:
So who does that leave? I'm not sure what Suse's release schedule is,
but based on the above, the first mainstream distro with GNOME 2.6 in
a release will be either Fedora Core 2 in May, or Mandrake in August
or September. That is, unless Debian
On Mar 9, 2004, at 10:46 pm, Roman Joost wrote:
If the gimp-help-2 team has nothing against this, it'll be okey for me
to be published on the site.
Certainly fine with me.
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
On Mar 10, 2004, at 8:41 pm, Sven Neumann wrote:
Nice explanation of the help browser works cut
Okay, I have some idea how this all might work.
Regarding the topic not found-fallback: I think we should
simply add some hidden texts in every language which can be
mapped as fallback. Those are
On Feb 25, 2004, at 11:27 pm, Daniel Rogers wrote:
sysctl -w kern.sysv.shmmax=41943040
sysctl -w kern.sysv.shmmin=1
sysctl -w kern.sysv.shmmni=320
sysctl -w kern.sysv.shmseg=80
sysctl -w kern.sysv.shmall=10240
DUH! How could I possibly forget about sysctl. That doesn't
seem to work though:
lucy:~
On Feb 25, 2004, at 10:35 am, Mark Shuttleworth wrote:
Image manipulation is one of the key application areas that needs to
be addressed for open source tools to become the mainstream desktop
environment. I'm currently funding a number of different open source
projects, and am considering
On Feb 26, 2004, at 5:38 pm, Daniel Rogers wrote:
Who knows? Who cares? but you do need to edit /etc/rc to see any
effect.
Thanks for the explanation. I did just what you told me and
retested, but it doesn't have any positive impact on the
slowness.
Servus,
Daniel
PGP.sig
Description:
On Feb 24, 2004, at 11:13 am, Sven Neumann wrote:
Ugh! I can't find airfare there any cheaper than about US$1500. Has
anyone from the US found a much better deal?
Did you also check flights going to Oslo?
I'd rather check the flights with a slighty longer stay instead.
6 nights and the flights
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 11, 2004, at 4:06 pm, Sven Neumann wrote:
Daniel recently posted a list of X extensions supported by the Apple
X11 server. The MIT-SHM extension was part of this list but today I
found that at least in darwinports gtk2 is compiled with the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 7, 2004, at 1:14 am, Tim Mooney wrote:
As I recall, the SIOD that's part of gimp is not a stock version of
SIOD, as there were various bugs detected and fixed in SIOD in the
0.99.x
and 1.2.x gimp releases. There *may* be fixes in the gimp's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 10:35 pm, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann )
wrote:
It helps to a) avoid antialiasing (small effect) b) use x fonts (big
effect).
Thanks for this tip. I'll try installing some high quality X fonts
(which is sort of an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 9:26 pm, Sven Neumann wrote:
You will need Darwinports (http://darwinports.opendarwin.org/) but IMO
darwinports is an improvement over fink. Of course your mileage may
vary.
Too complicated to install, at least I did and since I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2004, at 4:32 pm, Sven Neumann wrote:
Checking out a cvs repository and typing configure; make; make
install doesn't sound too complicated to me.
It is, especially when it doesn't work out-of-the-box.
Also this is equivalently complicated to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2004, at 5:12 pm, Tim Mooney wrote:
I haven't played with OS X enough to know, but does its X server
support
the Render extension? If not, that's probably why GTK+ 2 is slower.
number of extensions:28
Apple-DRI
Apple-WM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2004, at 7:25 pm, Kevin Cozens wrote:
While researching Guile as a replacement for Script-Fu,
Guile is a nasty beast. Gnucash is one of the hardest to
compile and keep working applications just because of their
use of guile. I'm not really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 5:20 pm, Sven Neumann wrote:
Are there any numbers you can base this statement on? I don't think
this assumption is correct. Not that it would matter much but I doubt
there are more Win32 GIMP users than Linux GIMP users. I'd also
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 31, 2004, at 12:15 pm, Olaf Marzocchi wrote:
I'd like to retranslate GIMP in italian, the current translation
almost sucks.
I searched the main site but I haven't found anything, couls omeone
tell me
how to do it?
Talk to Daniele Medri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote:
Well, actually we'd like to add interpolation to the GIMP canvas as
well. At least optionally. Modern computer hardware seems fast enough
to do this,
Am Mit, den 21.01.2004 schrieb Adam D. Moss um 20:28:
In OSX many applications tend to provide a quick redraw for pannings
but start a timer which will refine the display once it was static
for a while.
Hee hee... it's interesting how things can come full-circle.
GIMP 0.5[34] did
On Jan 11, 2004, at 3:23 pm, Sven Neumann wrote:
The DTDs are absolutely necessary in order to process the files.
No, they are not. They are needed for some advanced DOM validation
but one can very well process whole books without it.
http://sven.gimp.org/build-xml-catalog-for-debian.sh
Thanks,
On Jan 10, 2004, at 1:45 pm, David Neary wrote:
I hope these kinds of comments aren't out of place. I have
noticed that commits to gimp-help-2 are fairly infrequent, and
tend to affect lots of files. It is better all round if there are
more frequent commits, each one making a distinct change.
On Jan 10, 2004, at 4:38 pm, David Neary wrote:
It kind of does - it's not changeset oriented in the way that BK
or Arch are, but checking in several files at once is possible,
and cvs2svn manages to make changesets out of commits that happen
with the same comment, at the same time, by the same
On Jan 5, 2004, at 12:49 am, Roman Joost wrote:
3. I made the corresponding changes to the toolbox XML files and the
stylesheets and added three new options:
a) The processor includes the titles up to section3.
b) The processor chunks the documents up to section3 (Before, all the
tools are
Am Fre, den 26.12.2003 schrieb Sven Neumann um 21:49:
there's another thing I forgot to mention that might be worth to look
into when it comes to GIMP on Mac OS X. The new compositing code that
Helvetix added already provides the framework for making use of
Altivec instructions. If someone
Am Don, den 18.12.2003 schrieb Roman Joost um 16:10:
Huh? Probably it's just me being dense...
Heh - no. I shouldn't write mails during a lecture ... The existing XML
files are renamed to the name of the help ids in
$GIMP/app/widgets/gimphelp-ids.h, eg: airbrush.xml is now:
Am Don, den 18.12.2003 schrieb Roman Joost um 15:53:
Hm.. i didn't had any memory problems with XInclude. If the encoding was
wrong, the xsltproc throw an error and nothing more ...
I still do, but only under Mac OSX. More annoying with XInclude is that
xsltproc cannot be taught to really load
Am Fre, den 19.12.2003 schrieb Sven Neumann um 19:55:
I am pretty sure it loads the DTD from disk if you provide it an XML
catalog file that shows it where the DTD is found. This file is
usually called /etc/xml/catalog. See http://xmlsoft.org/catalog.html
I have this catalog file and xsltproc
Am Mit, den 17.12.2003 schrieb Roman Joost um 21:30:
1. Renaming of the current XML files, that the corresponding help ids:
app/widgets/gimphelp-ids.h. This is mostly done by me. I'll check the
changes in as soon as possible.
Huh? Probably it's just me being dense...
2. Adding XML
Am Mit, den 10.12.2003 schrieb Roman Joost um 22:55:
With Raymonds help i'm now be able to build the help with UTF-8 encoded
XML files, which are xincluded in the gimp.xml file.
Cool. Incidently I've also been working on this and my Mac really has
troubles when trying to compile such files
On Nov 24, 2003, at 12:02 am, Roman Joost wrote:
I tried it with some docs and it rocks. Unfortunately, i'm running into
trouble with the german umlauts. Do you've a solution for keeping the
umlauts ?
We'll switch to UTF-8 which should solve this problem, unless I'm
misunderstanding the issue, of
On Nov 22, 2003, at 3:11 pm, Roman Joost wrote:
I moved the stylesheets directory into the source root. I will change
it in the next days, after Daniel will give me the ok. No one has
declined the new structure purposal, so i think, that everyone on
gimp-help-2 gave this implicit OK to change it?
Am Son, den 16.11.2003 schrieb Roman Joost um 00:46:
This is the actual structure. I made a find ./ -type d in the gimp-help-2
and removed the CVS directorys:
Agreed. Howver since a few persons are not too happy with the
all-languages-concurrently approach I'd like to hear their opinion
first.
Am Mit, 2003-09-17 um 13.29 schrieb Sven Neumann:
Is this the official new list for the GTP? If so README.i18n should be
changed.
I might have missed something but what exactly do you think needs to
be changed in README.i18n?
I read in the thread that the GTP contact address is dead, if
Am Die, 2003-09-16 um 19.10 schrieb David Neary:
[EMAIL PROTECTED]
Is this the official new list for the GTP? If so README.i18n should be
changed.
--
Servus,
Daniel
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Am Sam, 2003-09-13 um 23.30 schrieb Marco Wessel:
It is true that the Apple keyboards that used to come with the iMacs, B/W
G3s and G4s don't have a del key. However, this keyboard has long since
been replaced with the full-sized keyboard, which does have the key.
Just curious, where is it on
Am Sam, 2003-09-13 um 22.38 schrieb Alan Horkan:
Delete is such a particularly good and obvious keybinding for Deleting
things
Actually I believe that having both a backspace and a delete key is
confusing in the original wordprocessing meaning; why would one want to
delete a character
Am Mon, 2003-09-08 um 11.52 schrieb David Neary:
Problem: Writing docs takes ages, and there are not enough people
to do it all, and docs often need little retouching at the end
that has to be communicated to the original author, and takes
time to integrate, and so on.
Indeed.
Solution:
Am Mit, 2003-08-27 um 11.33 schrieb Sven Neumann:
Any help page could then refer to the freetype plug-in by using
link xmlns:ft=http://freetype.gimp.org/help; ft:href=top /
As you can see, the namespace prefix is irrelevant, we can choose
ft: here to keep the notation short. Of course if
1 - 100 of 190 matches
Mail list logo
