Re: [Gimp-developer] gimp-help-2 status
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 http://xmlsoft.org/catalog.html 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 http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog delegatePublic publicIdStartString=-//OASIS//DTD XML Catalogs V1.0//EN catalog=/etc/xml/xml-core.xml/ delegateSystem systemIdStartString=http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog=/etc/xml/xml-core.xml/ /catalog 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 http://www.xmlsoft.org/buildDocBookCatalog 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 much. 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). Cheers, Malcolm ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
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 again. [These CVS survival tips brought to you by somebody on a slow dial-up connection. :-) ] Cheers, Malcolm ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Errors compiling gimp
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 directory 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. Cheers, Malcolm -- A clear conscience is usually the sign of a bad memory. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code.
On Sat, May 04, 2002 at 06:16:51PM +0200, Sven Neumann wrote: Hi, 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 http://gtkhtml2.codefactory.se/). 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. Cheers, Malcolm -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Yes, you can help even if you can't code
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 sect1. 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). Regards, Malcolm -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Current work
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 rules). 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 think. 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. Cheers, Malcolm -- A clear conscience is usually the sign of a bad memory. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Hmm .. this is a pretty cool writeup. :) On Tue, Nov 27, 2001 at 03:10:15PM +0100, Marc A. Lehmann wrote: [...] CONCLUSIONS - THE 60% WAY TO CMYK 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 Photoshop. 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. Malcolm -- Tolkien is hobbit-forming. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
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 opinion. 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. Malcolm -- How many of you believe in telekinesis? Raise my hand... ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
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 stipulation. 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 far). 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. Cheers, Malcolm -- Quantum mechanics: the dreams stuff is made of. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
