Re: [Gimp-developer] gimp-help-2 status

2003-12-19 Thread Malcolm Tredinnick
On Fri, 2003-12-19 at 13:21, Daniel Egger wrote:
 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
 I have this catalog file and xsltproc tries to open it, however it still
 continues trying to load the files from net. This is a Debian unstable
 system, all DTDs are installed and since some package created this file
 I assumed that Debian would automagically make it work, but no
 Do you know where to modify the system to get it work?
 ?xml version=1.0?
 !DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.0//EN;
 catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog
 delegatePublic publicIdStartString=-//OASIS//DTD XML Catalogs V1.0//EN 

Is that (the above) everythin in your /etc/xml/catalog file? If so, then
it's not really surprising that you are running out onto the Internet
for everything -- the catalog file is essentially empty. Debian has
unfortunately had very poor support for XML catalogs until quite
recently. I don't know what the current level is like, since I do not
use that distribution.

As a start to repairing the problem, have a look at which is a shell script to
make the required entries for DocBook 4.1.2. If you have a different
version of the DocBook DTDs installed (quite possible, since 4.2 is the
latest release), you will need to tweak the script a little, but not

Note that this script creates a separate catalog file and then adjusts
/etc/xml/catalog to point to the newly created file (only) for DocBook
lookups. That is the standard way to do this stuff, rather than
populating /etc/xml/catalog with all your entries (makes packaging
easier, too). It may be that the Debian DocBook DTD package already
ships a catalog file, in which case you only need to add the appropriate
lines to /etc/xml/catalog, which you can take out of the above script.

If your catalog set up is working, then XInclude processing will also
use it (libxml2 uses the catalogs by default).


Gimp-developer mailing list

Re: [Gimp-developer] Re: Gimp 1.3.22

2003-11-25 Thread Malcolm Tredinnick
On Tue, 2003-11-25 at 17:22, Tor Lillqvist wrote:
 Tor Lillqvist writes:
   Then the build should be removed from gimp's line in
   CVSROOT/modules . Will this have some odd consequences, or can it be
   done right away?
 Anyone object? It might be that people will have to re-get gimp from
 CVS if build is removed from gimp's line in CVSROOT/modules. (At
 least, I remember that when it was added some years ago, that was
 necessary.) Is this a big deal?

You don't have to do that. In your local copy, you can just remove the
build/ subdirectory and edit the gimp/CVS/Entries file and remove the
line that says D/build///. There is no need to extract the whole tree

[These CVS survival tips brought to you by somebody on a slow dial-up
connection. :-) ]


Gimp-developer mailing list

Re: [Gimp-developer] Errors compiling gimp

2002-12-03 Thread Malcolm Tredinnick
On Wed, Dec 04, 2002 at 09:02:00AM +0530, Rahul Rekapalli wrote:
 hi, I downloaded gimp from the cvs again after Sven helped me with the
 previous compilation problem, and this time, after almost
 all the packaging was over (I used gimp.spec to build my rpms), I got
 the following errors towards the end of compilation.
 + strip /var/tmp/gimp-1.3.11-root//usr/bin/gimp
 strip: /var/tmp/gimp-1.3.11-root//usr/bin/gimp: No such file or
 error: Bad exit status from /var/tmp/rpm-tmp.45801 (%install)
 could someone tell me how I can correct this?

I don't have a recent build around to check this, but I think you will
find that the binary is now just called gimp-1.3. So go to the %files
section of the spec file and edit the appropriate line.

Of course, you should check this is really what it is called by having
a look at the contents of the v/ar/tmp/gimp-1.3.11-root/usr/bin/
directory. This is just due to bit rot over time as hardly anybody
regularly builds development versions from the included spec file, I
would guess.


A clear conscience is usually the sign of a bad memory.
Gimp-developer mailing list

Re: [Gimp-developer] Yes, you can help even if you can't code.

2002-05-04 Thread Malcolm Tredinnick

On Sat, May 04, 2002 at 06:16:51PM +0200, Sven Neumann wrote:
 Daniel Egger [EMAIL PROTECTED] writes:
  So what we need is:
  - XSLT files and CSS stylesheets to produce XHTML which looks nice in
nowadays webbrowsers
  - XSLT files which produce output which is grokkable by the (new?)
helpbrowser plugin; That means we either need simple HTML files for
something like the current plugin or some other (new?) simple
fileformat which allows for additional features which also need to be
defined. This has to be discussed with the person(s) who will code
that (and that certainly won't be me).
 I'd say we port the help_browser plug-in to GtkHtml2. It's able to
 render quite sophisticated stuff (see
 Porting the plug-in should be pretty straightforward. The API is not
 compatible but similar.

Note that gtkhtml2 is suffering from a lack of maintenance at the
moment. The only major project that is currently using it is Mikael
Hallendal's Yelp (help browser for GNOME 2). However, Mikael has just
recently posted some mail to gnome-doc-list and desktop-devel saying
that he is thinking of not using it.

GtkHtml(1) is currently being ported to GNOME 2. The main differences
are that GtkHtml has editing, but is not accessible and does not support
CSS or DOMs, while GtkHtml2 is not editable but is accessible with CSS
and DOM support.

It's unclear whether anybody will come out of the woodwork and say they
will maintain GtkHtml2, so you might want to wait a week or so before
making a decision in this regard.


Gimp-developer mailing list

Re: [Gimp-developer] Yes, you can help even if you can't code

2002-05-04 Thread Malcolm Tredinnick

On Sat, May 04, 2002 at 10:20:25PM +0200, Daniel Egger wrote:
 Am Sam, 2002-05-04 um 20.42 schrieb Ayose:
  It should be DockBook/XML :)
 Well, is IS XML, just the DTD is an SGML one. All strict XML like
 correct closing and shortened tags as well as case sensitivity are
 obeyed, I just haven't checked if anything special changed between
 DocBook/SGML and DocBook/XML but it should be trivial to fix that. 

Assuming you are using the version 4.1.2 DTD, there is no difference. If
you are using the older version 3.x DTD, then to move to 4.1.2 XML the
only significant change is that whatever the tag was called that gave
the article info (title, authors, etc) is now called articleinfo (but
was called something else in 3.x -- sorry, can't remember the old name).

  Yes, I have seen it, but I think that it is better XSLT instead of
  python, because XSLT is more easy and it was designed for this kind of
  jobs :-).
 Well, DSSSL wasn't sufficient layout-wise and python is some magnitudes
 faster than Jade.
  However, XSLT could be insufficient if the LaTeX generated is
  very complex. The loops and conditionals in XSLT are very basics, and
  variables and parameters are limited.
 I wouldn't care too much about the Python output now, HTML is important
 and XSLT is THE choice here.
  I love sablotron. It is fast and very easy to use. Also, it has almost
  every feature of the XSLT standar.
 I see, how long would it take to transform into HTML compared to Jade?

The xsltproc that comes with libxslt works out of the box, too and is
being used a lot in the GNOME project already.

  When you XSLT files you must say XSLT file. Unlike DocBook, with
  XSLT we only will be able to produce one file, instead of one by
  Anyway, it will be easy :)
 So we cannot slice the HTML output into several files? That's sort of a
 problem, really. It took quite some time to figure out how to get Jade
 to do that and still releases are a pain in the neck because there's a
 lot which has do be done manually still.

This is simpoly not the case. Norm Walsh has produced an XSLT package
that allows chunking, as it is called. libxslt supports it and, as I
understand, a some other XSLT processors do as well (it requires an
extension to the engine, but the mechanism for supplying this is
documented in the spec, etc). Saxon, for one, can handle the chunking
also, since that is what a lot of the DocBook developers use.

Basically, you can specify which level of sectioning gets put on a new
page (by default, each sect1 is a new page). You can also configure
whether the files are named by using id() calls, or by using the id tag
of the leading element (the latter is preferable, providing each section
tag is written as sect1 id=layers-dialog, etc).


Gimp-developer mailing list

Re: [Gimp-developer] Current work

2001-12-05 Thread Malcolm Tredinnick

On Wed, Dec 05, 2001 at 05:51:12PM +0100, Rebecca J. Walter wrote:
 GNOME has been working on a new help browser that works with XML and
 scrollkeeper directly. It is worth checking.  Also worth a look is the
 project David Merril is working on that will make it possible to use the
 XML files and Scrollkeeper stuff with any browser. It is called
 Scrollserver I think.

I can probably give a little bit more info about these, since I'm
helping to complete the gnome help browser and I've done a small bit of
hacking on ScrollServer.

Firstly, the help browser (yelp) that's intended for GNOME 2 is probably
not appropriate as the lowest denominator. It depends (at least) on
the libxml2, libxslt and the gnome-vfs module, which means libbonobo as
well (bonobo isn't used in yelp, but it's a requirement for gnome-vfs).
So while it will serve any document that is available in scrollkeeper or
info or man pages, gimp still needs something simpler for its own use.
Yelp will also work with a file passed as a parameter to use for the
help file (resolved into an absolute URI by some fairly well-defined

Secondly, activity on ScrollServer has slackened a bit lately, since
both David Merrill and I have been doing other things. It just presents
a front-end to scrollkeeper so that requests can be made of it as if to
a webserver and pages are returned in HTML format. All the conversion of
XML - HTML is done on the fly (well, cached) by scrollserver. The
dependencies there would be python 2.0 or greater, libxml2 and libxslt.
ScrollServer seems like a nice idea to me, but nothing uses it, so I
have no idea whether it's actually useful or not.

My gut feeling is that serving help pages for a single application from
something like ScrollServer is overkill and tricky to manage.

Now it's possible that yelp could be slightly adjusted to build and
perform at some level of functionality without gnome-vfs. After all, it
only uses the gnome-vfs-help library to resolve the uri to look up and
to convert it to html (which is really just a call to an external
process). The name resolving is much simpler in the gimp and the
conversion stuff could either use the same external program or just make
direct C calls to libxslt. Right now, this modification isn't going to
happen, since we're under the hammer to get something ready asap for
GNOME 2. But the design would allow an add-on like this pretty easily, I

But really, I don't know what the answers are. I just thought I'd
through out some opinions and maybe if people want to think this way it
will be useful.


A clear conscience is usually the sign of a bad memory.
Gimp-developer mailing list

Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.

2001-11-27 Thread Malcolm Tredinnick

Hmm .. this is a pretty cool writeup. :)

On Tue, Nov 27, 2001 at 03:10:15PM +0100,  Marc A. Lehmann  wrote:
If one were so bold as to draw some conclusions, they would
probably be very similar to these:

3. Educate users about channels and what they can be used for - on this
   Systems I was frequently confronted with users who were unhappy with
   the gimp because it didn't allow them to do things as easily as under
   photoshop. Often(!) I was able to get exactly the same results, with
   a much easier and faster sequence than the one that user used with

Can you remember any specific examples of this? It would help show
us where the gimp's channels and layers setup does things better in
some sense.


Tolkien is hobbit-forming.
Gimp-developer mailing list

Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Malcolm Tredinnick

On Fri, Jul 27, 2001 at 02:12:05AM +0100, Nick Lamb wrote:
 On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote:
  For CVS gimp, it is definitely not a problem to require the current
  bleeding edge GTK.
 Malcolm did you ask me first? If you didn't, how did you come to the
 conclusion that it wouldn't be a problem for me (a developer, even if
 not one who's able to dedicate many hours to Gimp right now) to
 install and tend a GTK+ HEAD tree just to keep my Gimp builds green?

Get a grip! I'm not the one making the decision; what I posted was an

That said, if you want to do development and gimp chooses to track
gtk+'s main branch, then there is a once off effort to get the gtk setup
working and port your stuff. Then it's minor updating and rebuilding.
For many months now I, personally, have not had problems keeping a gtk+
CVS installation running for my development work. They are in API freeze
(more or less) now, so things are only going to get better.

 How will this make things better for me?

Apparently you've decided it won't. Deal with it.

NB I am not blind and I don't write code in Hebrew

So pango is not included specifically for you. You are lucky. However,
the i18n team will make use of pango to get decent display and widget
layout. I admit that a visually impaired version of the Gimp would be,
well, interesting, but a version allowing alternate input methods would
be useful (e.g. somebody who cannot use their hands). Incorporating
these toolkits means that _other_ people can come along and make your
plugins work well for everybody.


How many of you believe in telekinesis? Raise my hand...
Gimp-developer mailing list

Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-26 Thread Malcolm Tredinnick

On Wed, Jul 25, 2001 at 05:57:50PM +0100, Adam D. Moss wrote:
 Michael Natterer wrote:
  after some hours of torturing it with perl and some manual hacking,
  i got gimp running on current CVS glib/gtk+.
  (applying it means that if you want to hack or simply use gimp 1.3,
  you will need glib, pango, atk and gtk+ HEAD from CVS too).
 I few questions:
 * What are pango and atk, and why do we suddenly require them (if
 indeed we do)?

Pango is the text layout foundation for gtk (to abuse terminology
slightly). It provides a uniform way to do things like multi-lingual
layouts (coupling left-to-right and right-to-left text using different
character sets on the same line). This may not seem like such a huge win
for gimp, but it is a necessary requirement for Gtk 2.0 now.

The atk package is the accessibility toolkit and provides ways for
non-visual and non-keyboard/mouse interaction with gtk-based
application. This is one of the concrete results of Sun's input into the
Gnome community. They both advocated the need for such an elephant and
produced the code.

 * Are there compelling advantages to using CVS-GTK which outweigh
 the cons of forcing developers and users to upgrade?  Is GTK 1.3
 not backwardly compatible with the GTK 1.2 API?  My concern is
 that with such a casual-user oriented application as GIMP we
 can easily lose users by the wayside with each additional

Gtk 1.3 is the development branch, so it can't be relied upon for
release verisons of other software. It will eventually metamorph into
Gtk 2.0, which will be the stable branch. It has never been a secret
that this will not be backwards compatible with Gtk 1.2. If you look in
the gtk source code, there is a file called Porting-2.0.txt (or
something like that) that explains the changes needed to go from 1.2 -
1.3/2.0 to make an application simply run. This does not cover the new
gee-whiz features that have been added to the 1.3 branch -- it is simply
a porting guide. The required changes are reasonably mechanical and not
overly difficult (based on my experience of porting about four apps so

For CVS gimp, it is definitely not a problem to require the current
bleeding edge GTK. Casual users should not be using this if they are not
interested in tracking dependencies. When Gtk-2.0 is released, it will
be rapidly shipped with all the distributions and requiring/requesting
users to upgrade should not be an issue.

Until that time, it would be crazy for 1.2 versions of the Gimp to
depend on this version of gtk, since it is still only in slightly-frozen
API stages and many bug fixes, etc are still occurring.

 * For those of us with pieces of the tree's core which diverge
 somewhat from the trunk, how much of a no-brainer is converting
 our code to GTK 1.3-isms?

Read the porting document i mention above. It's not that difficult --
truly just search and replace in most cases.


Quantum mechanics: the dreams stuff is made of.
Gimp-developer mailing list