Re: 2.2 features. was: Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
On Friday 26 September 2003 7:19 am, Sven Neumann wrote: > Hi, > > "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > > Well, I have never enve looked at Pango. > > You will not get around it, see below. > > > My idea would be to get the text chars and attributtes from the > > GIMP, generate a image without the text only layers with no other > > layers above it, and "hand code" the PS code necessary to write a > > similar layer with the same font and coordinates. To embbed the > > font, I then would run GS with "pdfwrite" on a temporary PS. > > I don't think it will be acceptable to write a "similar" layer. The > PDF text layer will have to identical to what you see on screen. > Tiny differences might be acceptable but you definitely want to > apply the same font mapping, glyph substitution, line-breaking and > bidi algorithms as the text tool. That's why you won't get around > using Pango for the text layout. > > > If Pango thinks about providing the pdf layers itself, them I > > will probably check what it does, and does need improvement. > > I was talking about a third-party Pango extension. It's not part of > the standard Pango package. > > > There are 4 things on this list: > > 1) The Custom Layer Combination Mode > > This will record a plain ASCII parasite with a mathematical > > c-like expression on how to combine pixels from this layer with > > the one bellow. (And with themselves, like dissolve mode). > > If not for the flexibility, this mode will avoid cluttering > > the UI each time one finds a fine-tune to the "add mode", as is > > the Grain merge. > > I don't see how this would avoid UI cluttering. You don't expect > people who want to use an effect like Grain Merge to enter the > mathematical formula manually, do you? No, I think of having a bunch of pre-loaded formulas as gimp resources (Plain ASCII in a .gimp-2.2/layer_modes/ ). And them, if someone wants to fine tune any of them he will just type his values there. > > > 2) Improve the postscript export (and maybe import) filter: > > - Easy: save indexed images as indeed indexed. They are > > saved as full RGB currently > > - Save text layers as text > > - Save multiple layers as multiple pages, with some > > meta-information - Change import filter to erad multiple page > > into multiple layers as an option. Use meta-info from above for > > offsets, and combination modes. > > 3 and 4 would be just plugins. > > (2) would be plug-in only as well, no? Well yes...sorry, is that this one would come with the GIMP, the others might or not get in. > > > Sven JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: 2.2 features. was: Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > Well, I have never enve looked at Pango. You will not get around it, see below. > My idea would be to get the text chars and attributtes from the > GIMP, generate a image without the text only layers with no other > layers above it, and "hand code" the PS code necessary to write a > similar layer with the same font and coordinates. To embbed the > font, I then would run GS with "pdfwrite" on a temporary PS. I don't think it will be acceptable to write a "similar" layer. The PDF text layer will have to identical to what you see on screen. Tiny differences might be acceptable but you definitely want to apply the same font mapping, glyph substitution, line-breaking and bidi algorithms as the text tool. That's why you won't get around using Pango for the text layout. > If Pango thinks about providing the pdf layers itself, them I will > probably check what it does, and does need improvement. I was talking about a third-party Pango extension. It's not part of the standard Pango package. > There are 4 things on this list: > 1) The Custom Layer Combination Mode > This will record a plain ASCII parasite with a mathematical c-like > expression on how to combine pixels from this layer with the one > bellow. (And with themselves, like dissolve mode). > If not for the flexibility, this mode will avoid cluttering the UI > each time one finds a fine-tune to the "add mode", as is the Grain > merge. I don't see how this would avoid UI cluttering. You don't expect people who want to use an effect like Grain Merge to enter the mathematical formula manually, do you? > 2) Improve the postscript export (and maybe import) filter: > - Easy: save indexed images as indeed indexed. They are saved as >full RGB currently > - Save text layers as text > - Save multiple layers as multiple pages, with some meta-information > - Change import filter to erad multiple page into multiple layers as >an option. Use meta-info from above for offsets, and combination >modes. > 3 and 4 would be just plugins. (2) would be plug-in only as well, no? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
2.2 features. was: Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Ok. let's see. Sven Neumann wrote: Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: Arranging for the GIMP to be able to generate PDFs with "text layers as text" is on my "todo for 2.2" list. To get that done in sane way, you'd have to use a PDF Pango backend. There is such a beast but last I checked it wasn't working that well and it depends on PDFLib. Also the current PDB API for text is definitely not sufficient for this but it would be worth to extend it for this matter. Well, I have never enve looked at Pango. My idea would be to get the text chars and attributtes from the GIMP, generate a image without the text only layers with no other layers above it, and "hand code" the PS code necessary to write a similar layer with the same font and coordinates. To embbed the font, I then would run GS with "pdfwrite" on a temporary PS. If Pango thinks about providing the pdf layers itself, them I will probably check what it does, and does need improvement. BTW, it would be really nice if you could communicate this better. Your "todo for 2.2" should better be made available to the other developers since we will soon have to decide on the feature list for GIMP 2.2. Ok. There are 4 things on this list: 1) The Custom Layer Combination Mode This will record a plain ASCII parasite with a mathematical c-like expression on how to combine pixels from this layer with the one bellow. (And with themselves, like dissolve mode). If not for the flexibility, this mode will avoid cluttering the UI each time one finds a fine-tune to the "add mode", as is the Grain merge. 2) Improve the postscript export (and maybe import) filter: - Easy: save indexed images as indeed indexed. They are saved as full RGB currently - Save text layers as text - Save multiple layers as multiple pages, with some meta-information - Change import filter to erad multiple page into multiple layers as an option. Use meta-info from above for offsets, and combination modes. 3 and 4 would be just plugins. 3) Plugin to manage postscript scriptlets (scale and color) The scriptlets would live in a .gimp-2.0 subdir, and be resources just like brushes and patterns. Them provide a bunch of scritlets like: - Radial stripes - Hex. grid - Peano's curve - more. (those two are ready) This one will need GS installed. 4) Scriptable graphic turtle plugin - Actually, i've made a Python g.t. to use with the GIMP. The uses of this one would overlap with the above...maybe this one will obsolete the one above. Instead of PS, there would be a LOGO like set of statements to make scrippted drawings. Besides that, what I am looking forward most for post 2.0 are: Brush transformations - dinamically resize and rotate the brush. Seens like much of what is needed for this is done already. Maybe even working And above all!! : MACRO RECORDER (with python output, please)... :-) Is someone looking at it? it made a lot of noise here a couple of months ago. I also think we can get in touch with the scribus guys to have some of that color-correction-cmyk-CIE in place just to shut some of the said "professionals" up (and me no longer needing to load my images on f&&$$corel draw before sending them to the printer). And, why not, get a "edit in the GIMP" option inside scribus :-) Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
On Wed, Sep 24, 2003 at 07:14:43PM +0200, Guillermo S. Romero / Familia Romero wrote: > > I'd just like to say: Well done. I managed to create a A1 poster at 600 > > dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). > > Was there a real difference between 600 DPI and 300 DPI? I have a mag > here that is done in 300-400 DPI, with good paper... and it looks > nice, and it is something you look nearer than a wall poster. Well, the printing guys told me "600 dpi" and I wanted every detail I could get from that Julia set - I think every missed detail is a loss for such a nice picture. And it looks like the printer managed to get all that detail onto the poster (though I'm not sure what it's physical resolution is). > > BTW: Is it possible that there is a 3 Gig limit on per-process memory? > > The machine has 6 GB, no ulimits and I got a "could not allocate x > > bytes" message when I gave 3 Gig tile cache to GIMP (it took about 500 > > Meg for other stuff, so I settled with 2.5 GB tile cache and still got a > > 3 Gig swap file plus 3 Gig memory usage). > > What kind of processor and OS was used? It was a dual Xeon 2.4GHz machine running Linux. I already guessed that it would be the Highmem stuff limiting the available address space. 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] Re: Kudos to The GIMP Developers!
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > Arranging for the GIMP to be able to generate PDFs with "text layers > as text" is on my "todo for 2.2" list. To get that done in sane way, you'd have to use a PDF Pango backend. There is such a beast but last I checked it wasn't working that well and it depends on PDFLib. Also the current PDB API for text is definitely not sufficient for this but it would be worth to extend it for this matter. BTW, it would be really nice if you could communicate this better. Your "todo for 2.2" should better be made available to the other developers since we will soon have to decide on the feature list for GIMP 2.2. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Kudos to The GIMP Developers!
Guillermo S. Romero / Familia Romero wrote: [EMAIL PROTECTED] (2003-09-24 at 1132.48 +0200): I'd just like to say: Well done. I managed to create a A1 poster at 600 dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). Was there a real difference between 600 DPI and 300 DPI? I have a mag here that is done in 300-400 DPI, with good paper... and it looks nice, and it is something you look nearer than a wall poster. IMO - Text...reading text in 600 DPI and on 300 DPI just feels different. For graphics however, the " lots of DPI" are just used - in most cases - to emulate the color deph we have on CRT. Arranging for the GIMP to be able to generate PDFs with "text layers as text" is on my "todo for 2.2" list. Last month I made an artowork here that went to press either: 150DPI and A4, with text over graphics. Since the graphics in the case were "washed out" to work as a background, 150DPI was just good for it. The text however loooked a bit "steppy" ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
