At 20:31 23.05.03 +0200, Sven Neumann wrote:

[...]
I would appreciate if you could update the makefiles for Win32 and attempt a build of the current CVS version on Win32.

Done for the msvc build and just committed. _But_ there are other more serious issues with the win32 build:

- GIMP's direct usage of fontconfig IMO fontconfig is a X-only library which shouldn't be ported to win32. Why should one want to inherit the mess which X fonts are on a platform with better font support built-in ?

- GIMP's dependency on pangoft2 (1.2) The dependency on Ft2 isn't such severe as the fontconfig one, but pangoft2-1.2 does depend on fontconfig. http://mail.gnome.org/archives/gtk-devel-list/2002-June/msg00008.html

I'm still convinced that the native pangowin32 backend should be the first class citizen on win32, but I appear to be the only one: http://bugzilla.gnome.org/show_bug.cgi?id=94791 has the rotten bits :)

- Some brokeness of glib::g_spawn_async on win32 Without patching it The Gimp can't talk to it's plug-ins anymore. Although I have a patch it is probably too dirty to be included in GLib ...

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

Hans Breuer writes:
> IMO fontconfig is a X-only library

No it isn't. Its sources don't require any X headers, so in what way could it be an X-only library? On the contrary, when fontconfig is used on X11 (by Xft), this is precisely in order to *avoid* using the (core) X font technology, and instead use client-side fonts.

> Why should one want to inherit the mess which X fonts are

I assume you refer to the core X font mechanisms, with XLFDs etc, here? Nothing of that is "inherited" by fontconfig.

> on a platform with better font support built-in ?

Better than core X fonts? Maybe so, in a way. (But at least the X11 protocol is precisely defined, which is more than you can say about MS's vague documentation, and Win9x/NT/2k/XP differences.)

But then, fontconfig doesn't have anything to do with core X fonts.

> I'm still convinced that the native pangowin32 backend should be > the first class citizen on win32, but I appear to be the only one:

What gives you the impression that pangowin32 isn't a first-class citizen? If I recall correctly, I once wondered aloud whether pangoft2 should replace pangowin32 on Win32 (mainly because of the lack of resources to maintain/optimise pangowin32), but Owen said that in his opinion pangowin32 should stay.

> http://bugzilla.gnome.org/show_bug.cgi?id=94791 has the rotten bits

In order to get any progress with that, you probably should propose a backend-independent API instead of new pangowin32-only API, which then would be implemented by the Pango backends.

> - Some brokeness of glib::g_spawn_async on win32 Without patching > it The Gimp can't talk to it's plug-ins anymore. Although I have a > patch it is probably too dirty to be included in GLib ...

Please open a bug for this, including a description of what is happening, and attach the patch even if dirty. Or would you just want to get rid of the gspawn-win32-helper process whenever possible? I would, too... If so, just add comments to bug #98737.

--tml

At 01:21 25.05.03 +0000, Tor Lillqvist wrote:

Hans Breuer writes:

IMO fontconfig is a X-only library

No it isn't. Its sources don't require any X headers, so in what way could it be an X-only library? On the contrary, when fontconfig is used on X11 (by Xft), this is precisely in order to *avoid* using the (core) X font technology, and instead use client-side fonts.

Yeah I know. But still think it is a library to solve X design problems: Linking font files to list fonts selectable by feature. This sure is (almost) solved on win32 for years.

BTW: just tried to compile fontconfig with msvc. It does _not_ build out of the box. And although it certainly can be ported I'm pretty sure I dislike the 'give me another config file'-approach Also my motivation to solve problems again which are solved by GLib already is rather low ...

I'm still convinced that the native pangowin32 backend should be the first class citizen on win32, but I appear to be the only one:

What gives you the impression that pangowin32 isn't a first-class citizen? If I recall correctly, I once wondered aloud whether pangoft2 should replace pangowin32 on Win32 (mainly because of the lack of resources to maintain/optimise pangowin32), but Owen said that in his opinion pangowin32 should stay.

It strikes me odd to have to use two font backends (with diverging configurations) if one would be enough. As Linux will never use the pangowin32 backend it is common to throw in the pangoft2 dependency and don't see or accept the need f abstractions ...

http://bugzilla.gnome.org/show_bug.cgi?id=94791 has the rotten bits

In order to get any progress with that, you probably should propose a backend-independent API instead of new pangowin32-only API, which then would be implemented by the Pango backends.

Something like that ?
http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00612.html I'm not sure :) The results of that discussion where : "Having a pango_give_me_a_random_unknown_context_so_my_app_can_break() function sounds like a bad idea."

It's fine with me to build my own private GIMP which _has_ text support. See:
http://bugzilla.gnome.org/show_bug.cgi?id=113681

- Some brokeness of glib::g_spawn_async on win32 Without patching it The Gimp can't talk to it's plug-ins anymore. Although I have a patch it is probably too dirty to be included in GLib ...

Please open a bug for this, including a description of what is happening, and attach the patch even if dirty. Or would you just want to get rid of the gspawn-win32-helper process whenever possible? I would, too... If so, just add comments to bug #98737.

The dirty patch to make it work is attached to the bug report now. Though I'm pretty sure the current cvs glib does not work, I haven't tested it again.

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

At 16:06 25.05.03 +0200, Sven Neumann wrote:

Hi,

Hans Breuer writes:

- GIMP's direct usage of fontconfig IMO fontconfig is a X-only library which shouldn't be ported to win32. Why should one want to inherit the mess which X fonts are on a platform with better font support built-in ?

fontconfig has nothing to do with X11. It is not dependant on any X11 libraries.

I know. As noted in my previous mail. Yet I'm still not able to compile it with msvc. And I'm still not convinced it is useful on win32 in it's current shape.
One of the goals of Pango's fontconfig usage was to use the *same* font configuration with different backends. This goal is certainly not reached on win32.

- GIMP's dependency on pangoft2 (1.2) The dependency on Ft2 isn't such severe as the fontconfig one, but pangoft2-1.2 does depend on fontconfig. http://mail.gnome.org/archives/gtk-devel-list/2002-June/msg00008.html

I'm still convinced that the native pangowin32 backend should be the first class citizen on win32, but I appear to be the only one: http://bugzilla.gnome.org/show_bug.cgi?id=94791 has the rotten bits :)

IMO we should render text with the same backend on all platforms. Same holds true for selecting fonts. We use PangoFT2 and fontconfig since they provide a platform-independent architecture for this.

http://bugzilla.gnome.org/show_bug.cgi?id=113681 should have had some additional notes of mine, but cause it already is in the state of WONTFIX without them, here they are:

Feel free to have IMHO impossible goals: - having the *exactly* same results with fonts on different platforms would require to use the same font file (may be possible with M$ webfonts)
- ... and let the application find it. Even PangoFT2 offers the ability to add aliases to address fonts. AFAIK there is no way (but including the font vectors) to assure that the same name resolves to the same vectors, i.e. font file - Delivering font vectors would be possible as a PangoWin32 extensions as well. But I'm still not sure how much looking into the future is acceptable. Almost two years ago Sven had the same reasoning against the 'Pango Backend Abstraction' http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00627.html The only thing GIMP currently does is rendering to bitmap ... - affine transformation on fonts (or better text) would probably be done with the bitmap (not with the vector ?). With more backends supporting rendering to bitmap it would be simple to keep the GIMP code the same for all platforms.

To me the first 'is a must' is being able to render text at all. Which I am with the pangowin32 backend but _not_ with pangoft2.

Also having two font backends with independent configuration is not only a waste of disk/memory space and performance but also the source of inconvinients for users: - different lists of fonts depending on the configuration dialog used (either Gtk built-in or GIMP's) - Fontlist of pangoft2/fontconfig probably does not match the rest of the platform fontlists in native programs - Additional configuation (file) required

Anyway: the PangoFt2/fontconfig thing is probably a WONTFIX for me. As a result my GIMP version will diverge from the CVS version ...

Thanks for your fast (not so educated?) decision.

- Some brokeness of glib::g_spawn_async on win32 Without patching it The Gimp can't talk to it's plug-ins anymore. Although I have a patch it is probably too dirty to be included in GLib ...

Is it in Bugzilla? If not, please do file a bug-report for it asap.

Info appended to http://bugzilla.gnome.org/show_bug.cgi?id=98737

Hans -------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

On Sun, May 25, 2003 at 11:22:29AM +0200, Hans Breuer wrote:

Yeah I know. But still think it is a library to solve X design problems: Linking font files to list fonts selectable by feature. This sure is (almost) solved on win32 for years.

fontconfig certainly is a hack (design-wise, not code-wise), as it is designed from a single-machine perspective.

Client-side fonts are, in general, the wrong approach (the idea of two applications running that can't see the fonts of each other strikes me as a bug, and the speed penalty is immense). Exceptions exist but are exceptions.

The same design problem can be seen in xft, as xft is configured *per user* and not per display. However, subpixel rendering etc. are properties of the display ("is it a crt?"), and not a property of the users eyes, as xft suggests ;)

However, this does not mean that fontconfig is a bad thing (it *does* improve the situation a lot). It is, however, a workaround for shortcomings in X, where it should actually be solved.

At 19:15 25.05.03 +0200, Sven Neumann wrote:

Hi,

Hans Breuer writes:

I know. As noted in my previous mail. Yet I'm still not able to compile it with msvc.

That can surely be sorted out.

Sure it can. But you are probably developing long enough to know how long it takes to implement a solution you aren't convinced of, especially when not getting paid for it ...

And I'm still not convinced it is useful on win32 in it's current shape. One of the goals of Pango's fontconfig usage was to use the *same* font configuration with different backends. This goal is certainly not reached on win32.

It could be considered to move the win32 backend to fontconfig and to implement a fontconfig API on top of the Win32 font selection.

Please the other way around. First implement a win32 concept compatible fontconfig and _only than_ port pangowin32 to use it. But - who does? I've probably had enough versions of code against X Font concept limitations.

IMO we should render text with the same backend on all platforms. Same holds true for selecting fonts. We use PangoFT2 and fontconfig since they provide a platform-independent architecture for this.

http://bugzilla.gnome.org/show_bug.cgi?id=113681 should have had some additional notes of mine, but cause it already is in the state of WONTFIX without them, here they are:

Bugzilla states are something that can be easily changed. If you don't agree with the reslution, feel free to reopen the bug. That is something we are doing frequently.

When both maintainers have made their decision this appears to be rather useless ...

Feel free to have IMHO impossible goals: - having the *exactly* same results with fonts on different platforms would require to use the same font file (may be possible with M$ webfonts)

It is indeed a long-term goal to allow the user to include all resources in the XCF file. BTW, AFAIK webfonts is not a Microsoft invention. It is specified as part of CSS2.

I didn't mean it as buzz word but was refering to the concrete true type fonts from them which probably improve most of the Linux installations.

- Delivering font vectors would be possible as a PangoWin32 extensions as well. But I'm still not sure how much looking into the future is acceptable. Almost two years ago Sven had the same reasoning against the 'Pango Backend Abstraction' http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00627.html The only thing GIMP currently does is rendering to bitmap ...

We will add support for converting Text to Vectors in a time frame of a few weeks, definitely before the next release. After all it is very simple and gimp-freetype shows how to do it.

So my interpolation of the progress since 2001 to some weeks in the future was wrong.

- affine transformation on fonts (or better text) would probably be done with the bitmap (not with the vector ?). With more backends supporting rendering to bitmap it would be simple to keep the GIMP code the same for all platforms.

Of course we don't want to transform the bitmap. Freetype allows us to specify a transformation matrix before the glyphs are rendered to bitmaps. This is a feature we absolutely rely on.

Some weeks in the future ?

In the long term I'd like to see this functionality in Pango and I would also like to see an abstracted render API similar to what you suggested. But since we need features that only PangoFT2 can offer at the moment and since there is no substantial problem using PangoFT2 on Win32, I don't think we have much choice.

This is what I tried to start with the Pango Backend Abstraction thread http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00612.html

I tried to get something similar again to support Dia 0.91/win32 : http://bugzilla.gnome.org/show_bug.cgi?id=94791 (2002-10-03)

And now it is the reason why The GIMP _must_ rely on pangoft2. If all major applications implement their own work-arounds why should Pango be changed ever ?

Anyway: the PangoFt2/fontconfig thing is probably a WONTFIX for me. As a result my GIMP version will diverge from the CVS version ...

Please don't call it GIMP then. But I'd rather have this discussed before we see a fork here. I wonder why your reaction is that drastic.

I don't plan to distribute it. And for a very short time I had the impression we were discussing the issue. But since your WONTFIX I have the impression that the usage of (pango)ft2 is already enscribed in stone.

To me the right way to go is to implement the abstraction during the usage in a demanding application and have the required patches for Pango in the first place.
See again: http://bugzilla.gnome.org/show_bug.cgi?id=94791 and: http://bugzilla.gnome.org/show_bug.cgi?id=107668

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

At 20:46 25.05.03 +0200, Sven Neumann wrote:

Hi,

Hans Breuer writes:

That can surely be sorted out.

Sure it can. But you are probably developing long enough to know how long it takes to implement a solution you aren't convinced of, especially when not getting paid for it ...

Before we started to use fontconfig directly, we checked that fontconfig packages for win32 exist. I don't understand what issues you could be having with it. The only thing I can imagine is that you simply don't want to since you are not convinced.

Exactly. And by the way: instead of checking if something on win32 exist, why not simply ask ?

[...]

I don't plan to distribute it. And for a very short time I had the impression we were discussing the issue. But since your WONTFIX I have the impression that the usage of (pango)ft2 is already enscribed in stone.

In my opinion we are way too close to feature freeze and release to change the text tool design once more.

Oh, there is a text tool design ? References ?

Actually I'm a bit pissed off ...

Fine, that makes two of us :-)

... since there was a lot of time to bring this issue up.

Did you follow _one_ of the links provided in my previous mails ? Did you notice dates in them ??
I've brought up the issue of 'Pango Backend Abstraction' almost two years ago. There were some response from you a long the line of :

"the current state of the Gimp Text Tool in Gimp is in no way final nor has it been designed with care. I haven't yet found the time to think about this much, but I was under the impression we could use the FT2 backend on all supported platforms."

And with Heads up on Pango HEAD PangoFT2 broke. There still was a working version 1.0 but nowadays The GIMP relies on Pango 1.2.

Now that the development cycle ends, you declare that you want things completely different than what we have been doing the last two years. We are trying hard to make gimp-1.3 compatible with win32 even though there is almost null feedback from you and Tor.

I've got the impression that you and Mitch are thinking ChangeLog entries are enough to show design decisions. Almost any of my mail to gimp-devel list ended up with: we don't know why you want to do this or something like this.

We have to guess what your prolems are. You didn't even tell us if the latest changes worked.

I think my response time was rather good: - Your mail 23 May 2003 20:31:35 +0200 - My ChangeLog entry 2003-05-24
- The bug report from 2003-05-25 04:56 -???

And for the record: beside the issue with pangoft2 The GIMP cvs appears to work as expected (a little unstable though).

There is almost no communication between the main GIMP developers and the people working with GIMP on Win32.

I always thought I was working on GIMP on windoze instead of with. And communictaion should be bidirectional. Can't talk about people working _with_ Gimp on windoze.

This doesn't give you a good position if you want to change how we implement things. Perhaps we could change that first.

What? I was providing a patch and you were simply dropping it as WONTFIX. So do I need to guess when you finally get to implement the long announced Texttool revamp?

That's fine with me but _please_ don't complain about lack in communication skills.

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

At 22:57 25.05.03 +0200, Sven Neumann wrote:

Hi,

Hans Breuer 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

Hans Breuer writes:
> - having the *exactly* same results with fonts on different > platforms would require to use the same font file

And even with identical font files, the results might be different because some platforms will have the TrueType bytecode interpreter disabled in Freetype (as it is by default in the sources, AFAIK) because of the patent issues. Possibly this doesn't matter for text sizes one would typically use a GIMP text tool for, though.

--tml

Hans Breuer writes:
> BTW: just tried to compile fontconfig with msvc. It does _not_ > build out of the box.

Did anybody claim it would? Builds fine with gcc (mingw), but it has more POSIX emulation stuff bundled than MSVC.

And although it certainly can be ported

Yeah, wasn't annything particularily difficult, just needed to add some #ifdef HAVE_UNISTD_H, point it to the dirent emulation package, write up a nmake makefile for the src directory, use a prebuilt config.h. Still, in order to be able to build totally from scratch with MSVC, would need write nmake makefiles for the other directories. Shall I send you what I have, do you want to continue?

--tml

In regard to: [Gimp-developer] Re: GIMP-1.3 and Win32, Tor Lillqvist said...:

Hans Breuer writes:

- having the *exactly* same results with fonts on different platforms would require to use the same font file

And even with identical font files, the results might be different because some platforms will have the TrueType bytecode interpreter disabled in Freetype (as it is by default in the sources, AFAIK) because of the patent issues. Possibly this doesn't matter for text sizes one would typically use a GIMP text tool for, though.

With very recent FreeType (IIRC 2.1.3 and later) the FreeType authors no longer recommend enabling the bytecode interpreter (even if the patent issues are a non-issue for you), because the improvements to the hinter actually make it do a better job than the patent-restricted bytecode interpreter.

Not everyone will have a recent enough version, but it does mean that "Is the bytecode interpreter enabled?" question will eventually go away.

See:

http://www.freetype.org/freetype2/2.1.3-explained.html http://freetype.sourceforge.net/patents.html

and note that 2.1.4 contains additional improvements to the hinter.

Tim

At 02:37 27.05.03 +0000, Tor Lillqvist wrote:

Hans Breuer writes:

BTW: just tried to compile fontconfig with msvc. It does _not_ build out of the box.

Did anybody claim it would?

Not that I know of.

Builds fine with gcc (mingw), but it has more POSIX emulation stuff bundled than MSVC.

Yeah, almost stuff handled by GLib ...

And although it certainly can be ported

Yeah, wasn't annything particularily difficult, just needed to add some #ifdef HAVE_UNISTD_H, point it to the dirent emulation package, write up a nmake makefile for the src directory, use a prebuilt config.h. Still, in order to be able to build totally from scratch with MSVC, would need write nmake makefiles for the other directories. Shall I send you what I have,

Yes, please.

do you want to continue?

Though I'm still not convinced it's useful to have two similar font engines in one program, is sure would be useful to have both buildable to compare results.

Thanks, Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert