At 22:57 25.05.03 +0200, Sven Neumann wrote: >Hi, > >Hans Breuer <Hans@xxxxxxxxxx> writes: > >> Oh, there is a text tool design ? References ? > >The basic text tool design is in CVS since summer 2001. I didn't >expect it to take so long to get it finished and we are not there yet. >The plan is to get the following features in before the upcoming >release: >- add gui for text boxes: positioning, resizing >- store text layers in XCF; mostly there since GimpText implements > the GimpConfig interface >- convert text to vectors > >I'd like to address transformations (flip, rotate, affine) as well but >we might have to postpone this. However I definitely want to have some >migration path to this feature. At the moment only PangoFT2 seems to >allow these kind of things. Actually, it doesn't, but it can be done >using the FreeType API. If we accepted your patch, I would have to >workaround its #ifdefs and could only hope that there is a chance to >implement the same functionality in the win32 part of the code. We >have eliminated most of the special-casing in the current code base. >I really don't want to introduce new ones. > Sounds reasonable though I still would prefer to get the abstraction to use different backends in the first place. Having such a layer which simply hides the FT2 and fontconfig stuff for the rest of Gimp and can be implemented on top of released apis (pango, ft2, fontconfig) but would force to do some patches for pangowin32 (cause it does not expose enough internals) may be the way to make anybody happy ... Finally there would be a Pango api which applications with higher font demands could use (I'm building and _running_ The Gimp, Dia and Sodipodi quite regular) >There is no point in discussing 1.0 versus 1.2. We can't depend on an >unmaintained version of Pango. If we go for PangoFT2 as our text >rendering engine then it has to be the latest version. Otherwise we >have no chance to get any fixes into it. And we had to fix quite a few >bits of PangoFT2 to get the text tool to the point it is today. > Agreed. I like to have the pressure of GIMP's Pango usage for pangowin32 as well ... >Yes, and I must admit that I was impressed. Your text tool patch >shocked me quite a bit but I was happy to see the makefile changes >coming in that fast. > >However what I was really waiting for during the last months was some >feedback about the state of GIMP on windoze. It felt depressing that >obviously noone could compile this beast on windoze, let along run it. >The latest changes to libgimp were an attempt to make it easier to get >gimp compiled on windoze. > Again for the record: everytime I commit makefile changes I have successfully built and _run_ The GIMP on windoze with msvc. It than at least is able to open some PNG without instantly crashing. >> And for the record: beside the issue with pangoft2 The GIMP cvs >> appears to work as expected (a little unstable though). > >That is the very first time I ever hear that a GIMP-1.3 was run on >windoze. I assume it was the first time, you surely would have told us >if it happened before. Nope. See above. I'm trying to solve the problems and will complain if I see better solutions. But simply being able to build it isn't worth a notice beside the ChangeLog entry. >That is great news. Do you think it would make >sense to think about providing packages so more people can test it. Or >do believe it's too early for that? > Sorry, my limited resources don't allow to package and distribute a beast like The Gimp. I even dropped the binary distribution of Dia cause of it's bad fun-to-complaining ratio. Also - at least for the win32/msvc build - the pangoft2 issue will remain. But maybe Tor or somebody else with a working mingw environment could give it a try ... >> That's fine with me but _please_ don't complain about >> lack in communication skills. > >Sorry, but I do. The good thing about these little flames is that >things get said. Perhaps that is needed from time to time. I tried to >bring up the issue about lack of feedback before when I suggested we >merge the win32 mailing list into gimp-developer. Perhaps that would >have avoided a dispute like this one. > Be assured at least I do read gimp-devel much more serious than gimpwin-dev, but that's a different issue. Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
