Re: [Gimp-developer] Preparing the 1.2.4 release
On Fri, May 03, 2002 at 10:37:37PM +0200, Sven Neumann wrote:
- Look through the list of open bugs for the 1.2.4 milestone (a quick
way to get there is http://bugs.gimp.org/stable-milestone/). Some
of these bugs need comments. Of course patches to fix them are
highly appreciated.
I'd like to comment on bug #79754. Some time ago I built a GIMP 1.2.2
RPM for SUSE. There was a gimp-fontset.patch included:
--- app/text_tool.c.origSat Jan 27 16:29:16 2001
+++ app/text_tool.c Sat Jan 27 16:31:50 2001
@@ -607,7 +607,7 @@
gdk_error_warnings = 0;
gdk_error_code = 0;
#ifndef GDK_WINDOWING_WIN32
- font = gdk_font_load (fontname);
+ font = gdk_fontset_load (fontname);
if (!font)
{
g_message (_(Font '%s' not found.), fontname);
@@ -838,7 +838,7 @@
gdk_error_warnings = 0;
gdk_error_code = 0;
#ifndef GDK_WINDOWING_WIN32
- font = gdk_font_load (fontname);
+ font = gdk_fontset_load (fontname);
if (!font)
return FALSE;
The problem was: It did not work. If I entered umlauts into the
(dynamic) text tool, the text got truncated there (although they showed
up fine in the preview). (I used the C locale, not de_DE or
something).
I talked a bit with Daniel Egger but we didn't come to a clear solution.
If I find the time, I'll check out CVS today and give check whether the
problem persists.
I tracked down the problem to gdk_measure_text which called
XmbTextExtens which in turn returned the wrong width (truncated at first
umlaut).
I'm just telling that story to point out that fontset support might be a
hairy issue and hard to get right.
Bye, Tino.
--
* LINUX - Where do you want to be tomorrow? *
http://www.tu-chemnitz.de/linux/tag/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
Hi,
[EMAIL PROTECTED] (Tino Schwarze) writes:
I'd like to comment on bug #79754. Some time ago I built a GIMP 1.2.2
RPM for SUSE. There was a gimp-fontset.patch included:
--- app/text_tool.c.origSat Jan 27 16:29:16 2001
+++ app/text_tool.c Sat Jan 27 16:31:50 2001
@@ -607,7 +607,7 @@
gdk_error_warnings = 0;
gdk_error_code = 0;
#ifndef GDK_WINDOWING_WIN32
- font = gdk_font_load (fontname);
+ font = gdk_fontset_load (fontname);
if (!font)
{
g_message (_(Font '%s' not found.), fontname);
@@ -838,7 +838,7 @@
gdk_error_warnings = 0;
gdk_error_code = 0;
#ifndef GDK_WINDOWING_WIN32
- font = gdk_font_load (fontname);
+ font = gdk_fontset_load (fontname);
if (!font)
return FALSE;
The problem was: It did not work. If I entered umlauts into the
(dynamic) text tool, the text got truncated there (although they showed
up fine in the preview). (I used the C locale, not de_DE or
something).
I talked a bit with Daniel Egger but we didn't come to a clear solution.
If I find the time, I'll check out CVS today and give check whether the
problem persists.
I tracked down the problem to gdk_measure_text which called
XmbTextExtens which in turn returned the wrong width (truncated at first
umlaut).
I'm just telling that story to point out that fontset support might be a
hairy issue and hard to get right.
Thanks. Such comments are exactly what I had in mind when I sent the
mail. Could you please also attach this comment to the bug-report so
it doesn't get lost.
Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preparing the 1.2.4 release
From: Sven Neumann [EMAIL PROTECTED] Date: 04 May 2002 13:54:06 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: Do you want to do anything about the print software for 1.2.4? We've just released our 4.2.1 release, which is much better than the 4.0.5 that you're using. actually we wanted to integrate gimp-print-4.2 into gimp-1.3 first. Then, with some experience, do the same change for 1.2. Until now we haven't come around to do so. Perhaps we should indeed consider to update gimp-print in the stable branch. How do you suggest should we proceed? Should we depend on libgimpprint or would it be a good idea to ship gimp-1.2.4 with the whole thing? I'd much rather you link to libgimpprint, and I thought that that's what we had decided. The 4.2.1 version of the plugin, which is presumably what you'd use, had no changes whatsoever over 4.2.0; that code base is rock stable. 4.2.2 will offer a useful quality upgrade (a new dither algorithm) for people printing photos, but that will be a library-only upgrade. 4.2.3 may require a plugin upgrade to get some new functionality that we're discussing, but the 4.2.0 plugin will work with 4.2.3, it just won't have that new functionality. One option might be to distribute Gimp-print as an extra (mirror the distribution of the latest 4.2 release). -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ 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 01:31:27PM +0200, Sven Neumann wrote: Hi, just in case that anyone out there feels bored and useless, here's a list of things you can do to help us with GIMP-1.3 even if you can't (or don't want to) code. The items appear in no particular order. (2) There are some files that list contributors and plug-in maintainers (namely the files PLUGIN_MAINTAINERS and tools/contributors). I'd like to keep this information in one XML file that is then used for several purposes: To extract info to display in the about dialog and to handle maintainance of plug-ins and bug-reports. The XML approach would have several advantages. It allows to specify an encoding, so we could use UTF-8 to be able to show contributor names in the way they are written natively. We can add all sort of meta information like email address, bugzilla account, CVS account and what parts of the code the specific person has contributed to or maintains. I'd welcome if someone could sit down and come up with a proposal how such an XML file could be organized. You don't need to write a DTD, an example would do. The PLUGIN_MAINTAINERS has this --- NAME : AlienMap AUTHOR : Daniel Cotting ([EMAIL PROTECTED], http://www.mygale.org/~cotting) MAINTAINER : SIZE : 74.0 kB in 1 file (only C files counted) COMMENT: --- That could be plugin nameAlienMap/name author nameDaniel Cotting/name email[EMAIL PROTECTED]/email homepagehttp://www.mygale.org/~cotting/homepage /author maintainer !-- There is no a maintainer, but the structure will be the same that author -- /maintainer files amount=1 size scale=kB74.0/size commentonly C files counted/comment /files comment!-- blank --/comment /plugin If you need help with a XSLT I will help you pleased :-) -- Ayose Cazorla León Debian GNU/Linux - setepo ___ 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.
Am Sam, 2002-05-04 um 15.41 schrieb Ayose: If you need help with a XSLT I will help you pleased :-) Actually if you have experience in that area it would be nice if you could help out with the gimp-help project. -- Servus, Daniel ___ 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.
Am Sam, 2002-05-04 um 13.31 schrieb Sven Neumann: (4) I suspect the gimp-help crew could also need some help in converting the existing help files to DocBook-XML (IIRC, that was the plan) and in updating the help for GIMP-1.3. Please contact Mel Boyce [EMAIL PROTECTED] if you want to help out here. To make gimp-help DocBook/XML all we need to do is flip the switch. Problem are the tools not the format; what would be needed is a working toolchain to convert the XML into HTML or whatever and actually the plan was to wait until you and/or Mitch have decided how to continue with the help-browser plugin. If you want to help out here, with new DocBook source, simple texts, ideas, scripts or just want to say hi simply mail [EMAIL PROTECTED] and don't forget to CC Mel Boyce [EMAIL PROTECTED] and Daniel Egger [EMAIL PROTECTED]. You'll get all the support you need including CVS write access and a bugzilla account, so if that's what you've ever wanted feel free to contact us. :) -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Usage of mnemonics in GIMP 1.3
GTK 2.0 now has this nice feature of using mnemonics which I think can greatly improve the navigation inside dialogs. I have 3 questions about this: * should we have some kind of guideline for using these, such that each plugin will use more or less the same mnemonics? * what will be the impact on the translations when we start using these? * can I submit a change request in Bugzilla to request for all plugins to use mnemonics for GIMP 1.4? I'm willing to help out here. Maurits ___ 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 03:48:20PM +0200, Sven Neumann wrote: Hi, Ayose [EMAIL PROTECTED] writes: plugin nameAlienMap/name author nameDaniel Cotting/name email[EMAIL PROTECTED]/email homepagehttp://www.mygale.org/~cotting/homepage /author maintainer !-- There is no a maintainer, but the structure will be the same that author -- /maintainer files amount=1 size scale=kB74.0/size commentonly C files counted/comment /files comment!-- blank --/comment /plugin would it make sense to organize the file by persons instead of plug-ins? I have no strong feelings either way but I think it should be considered at least. By persons? No... With that format the plugins are described inside plugin, and every plugin is led by name, so the file is organized by plug-ins. Where are you seeing that the organize is by persons? My english is not very good, so if I didn't explain it correctly, please, notice me :) If you need help with a XSLT I will help you pleased :-) we will most likely need at least one XLST that extracts a much simpler format to be used in the About dialog. How simpler? Something like name, author (email), comments -- Ayose Cazorla León Debian GNU/Linux - setepo ___ 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 03:51:05PM +0200, Daniel Egger wrote: Am Sam, 2002-05-04 um 15.41 schrieb Ayose: If you need help with a XSLT I will help you pleased :-) Actually if you have experience in that area it would be nice if you could help out with the gimp-help project. I know well the XSLT specification, and I have written a lot of lines of XSLT ;) Where is info about gimp-help? In http://www.gimp.org/mailing_list.html there is no list for it :/, but I have downloaded the gimp-help module for CVS. What can I do?, look at bugs.gimp.org? ;) -- Ayose Cazorla León Debian GNU/Linux - setepo ___ 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.
Am Sam, 2002-05-04 um 18.11 schrieb Ayose: I know well the XSLT specification, and I have written a lot of lines of XSLT ;) That's good. Where is info about gimp-help? In http://www.gimp.org/mailing_list.html there is no list for it :/, Yes, mostly because there are almost no people behind it. :/ but I have downloaded the gimp-help module for CVS. What can I do?, look at bugs.gimp.org? ;) gimp-help is written in DocBook/SGML which is converted to HTML to be suitable for online-browsing and the help-browser plugin for GIMP. There are HTML and PS/PDF DSSSL stylesheets which can be used to produce either the HTML or some (buttugly) PS/PDF file; also we have an experimental DocBook-LaTeX converter written in python by me which tends to produce much better PDF output. The DocBook source is written such that the conversion to XML is merely changing the DTD to an XML one; in short: it is already supposed to be valid XML. It just hadn't been done so far because the tools were not mature and fast enough last time I looked but if they were now So what we need is: - A featurerich (and possibly FAST!) XSLT processor - 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). This need a lot of planning and someone with your experience can possibly bring in some thoughts which would be really appreciated. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Usage of mnemonics in GIMP 1.3
Hi, Maurits Rijk [EMAIL PROTECTED] writes: GTK 2.0 now has this nice feature of using mnemonics which I think can greatly improve the navigation inside dialogs. I have 3 questions about this: * should we have some kind of guideline for using these, such that each plugin will use more or less the same mnemonics? the GNOME style guide could suite our needs. I haven't looked at it in detail. * what will be the impact on the translations when we start using these? translations will break and need to be updated. However I don't see any particular problem here. Of course translators need to put some thoughts into the mnemonics they use in the translations and should try not to deviate too much from the original (english) mnemonics. * can I submit a change request in Bugzilla to request for all plugins to use mnemonics for GIMP 1.4? I'm willing to help out here. sure. I guess the core UI also needs some work in this area. Salut, Sven ___ 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.
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. Salut, Sven ___ 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:02:44PM +0200, Daniel Egger wrote: gimp-help is written in DocBook/SGML It should be DockBook/XML :) which is converted to HTML to be suitable for online-browsing and the help-browser plugin for GIMP. There are HTML and PS/PDF DSSSL stylesheets which can be used to produce either the HTML or some (buttugly) PS/PDF file; also we have an experimental DocBook-LaTeX converter written in python by me which tends to produce much better PDF output. 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 :-). 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. The DocBook source is written such that the conversion to XML is merely changing the DTD to an XML one; in short: it is already supposed to be valid XML. It just hadn't been done so far because the tools were not mature and fast enough last time I looked but if they were now So what we need is: - A featurerich (and possibly FAST!) XSLT processor I love sablotron. It is fast and very easy to use. Also, it has almost every feature of the XSLT standar. - XSLT files and CSS stylesheets to produce XHTML which looks nice in nowadays webbrowsers 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 :) Well. If you want, look my work in http://gimp.es.gnome.org (spanish). The tutorials (http://gimp.es.gnome.org/manuales.php) are written in a new XML vocabulary. For instance, the XML file http://www.es.gnome.org/cgi-bin/cvsweb/web-xml/gimp.es.gnome.org/manuales/ilustracion/index.xml?rev=1.3content-type=text/x-cvsweb-markupcvsroot=GNOME will generate http://gimp.es.gnome.org/manuales/ilustracion/ using the XSLT http://www.es.gnome.org/cgi-bin/cvsweb/web-xml/gimp.es.gnome.org/gimp.xsl?rev=1.36content-type=text/x-cvsweb-markupcvsroot=GNOME - 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). So we need two XSLT files This need a lot of planning and someone with your experience can possibly bring in some thoughts which would be really appreciated. Of course :). If I'm useful for GIMP I will work here. What do you need? -- Ayose Cazorla León Debian GNU/Linux - setepo ___ 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:55:56PM +0200, Sven Neumann wrote: Hi, Ayose [EMAIL PROTECTED] writes: we will most likely need at least one XLST that extracts a much simpler format to be used in the About dialog. How simpler? Something like name, author (email), comments all we need are simple list of names. Or do we want email addresses in the about dialog and the AUTHORS file? I think not. The transformation wouldn't be a real XSLT since what we need as output format is not actually XML. I'd like to generate the plain-text file AUTHORS as well as the header file app/gui/authors.h from the XML file. Wait a moment, please. Who says that XSLT only works with XML? With XSLT you can transform a XML file in everything: a plain-text, HTML, a new XML or even in C source. You only need put xsl:output method=text/ in the top-level. http://www.w3.org/TR/xslt.html#section-Text-Output-Method Commenting on your proposal, I'd say that it probably makes sense to organize the XML file by persons because we need more than only plug-ins. So I was wrong We also want to list core developers, tool authors, help writers, web masters, screen designers, just everyone who contributed to The GIMP. Well, imaging you want to know only his/her name and email, and put a comment about he/she The XML: people person namethe name/name work!-- here: core develp, tool authors, help writer...--/work emailemail/email commentA little comment/comment /person /people For every person will be a person entry. And, for instance, if you want to get a list like name1, work1 name2, work2 name3, work3 [...] The XSLT will be ?xml version=1.0 encoding=iso-8859-1 ? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:output method=text / xsl:template match=people xsl:for-each select=person xsl:apply-templates select=name/xsl:text,/xsl:text xsl:apply-templates select=work/xsl:text /xsl:text /xsl:for-each /xsl:template /xsl:stylesheet There are a lot of chars, but the code is simple. :) Of course, with the same XML you can get a more detailed list about people. -- Ayose Cazorla León Debian GNU/Linux - setepo ___ 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.
Am Sam, 2002-05-04 um 18.16 schrieb Sven Neumann: 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. Fine with me. Still it might make sense to have a different XSLT file for the HTML files for the helpbrowser because online help makes mostly sense when one can read about and try to apply the just learned instead of having to switch between a big window and the application which is what the documentation for the normal browser would probably be optimised for. Also it might make sense to allow the helpbrowser to fire events for GIMP for demonstration or help purposes which would require use to have special information in the help. -- Servus, Daniel ___ 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
Am Son, 2002-05-05 um 00.27 schrieb Nathan C Summers: It would be trivial to add some magic text like $^CUT HERE!^$ where the files need to be cut and then have a postprocessing script written in perl that takes the xslt output and cuts it appropriately. I'm not really happy with that approach as it complicates things quite a bit. It's messy enough what we have now and I hoped we could get everything a bit cleaner. -- Servus, Daniel ___ 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] Usage of mnemonics in GIMP 1.3
lör 2002-05-04 klockan 18.10 skrev Sven Neumann: * what will be the impact on the translations when we start using these? translations will break and need to be updated. However I don't see any particular problem here. Of course translators need to put some thoughts into the mnemonics they use in the translations and should try not to deviate too much from the original (english) mnemonics. I usually consider the mnemonics to be chosen so that they are easy to remember and access to be of much higher importance than any attempt to make them not deviate too much from their English equivalents. Often, the English characters are not even part of the translated word, so it's usually not particularily useful to use a strategy of not deviating too much, especially as this strategy may cause the mnemonic to clash with much better mnemonics where it's not even possible to use the English equivalent even if you would want to do so. For these reasons, I myself have long since given up any strategy to not deviate too much, and instead try to choose the mnemonics wisely. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
