Re: [gtk-devel-list] Design decisions for GLib and GTK+ on Win32


Before all, I have to apologize that I vote No in spite of
I'm not GTK+/Win95 developer.

On Mon, 28 Aug 2006 11:33:21 +0300
Tor Lillqvist <tml iki fi> wrote:
>mpsuzuki hiroshima-u ac jp writes:
> > I vote No, but please let me ask a silly question:
> > if cairo works on Win9x, GTK+ HEAD will work as
> > newer Win32 platforms?
>I have no idea. GTK+ 2.8 might. But is there somebody working on
>making cairo run on Win9x?

I remember, a guy was trying to port cairo to Win9x, although
yet I've not heard successful report, at present.

>                           And if somebody did this, wouldn't it be
>enough to keep the Win9x support in GTK+ 2.10 (and earlier), and
>retire it from HEAD?

Dropping Win9x code from HEAD means "GTK+ 2.12 won't support for
Win9x"? Excuse me, I don't understand what you mean "enough".

> > Or, even if cairo works on Win9x, more additional (and hard to
> > maintain) codes for Win95 are required?
>Well, I wouldn't call the code hard to maintain as such, just
>messy. But it's not just a question of having to keep two code paths
>(one using wide characters strigns and "W" APIs, the other using
>system codepage char strings and "A" APIs) here and there. Some APIs
>that would be useful to use aren't available at all on Win9x, like
>GetFontUnicodeRanges. (Although GetFontUnicodeRanges seems to be
>broken in the sense that it can't handle fonts with coverage outside
>the BMP, so we couldn't use it anyhow, sigh.)

I see. Do you think it is possible that packaging Win95 support
code as separate library?

> > BTW, the request of Uniscribe backend is for Unicode text layout
> > by Uniscribe instead of HarfBuzz? Anything else?
>Er, Harfbuzz doesn't do the same thing Uniscribe, does it? Uniscribe
>is what takes care of the complex script processing, for which on Unix
>Pango uses the code in the pango-arabic-fc, pango-hangul-fc,
>pango-hebrew-fc, pango-indic-fc etc modules. Or am I confused?

Ah, sorry, I was confused and my English is too poor.
Let me explain wordily.

I guess, the import Uniscribe into pangowin32 is requested to
add complex script rendering feature to pangowin32 itself.
By Uniscribe rendering, the complex script rendering would
be exactly same with popular Win32 applications (e.g. wordpad.exe).
I guess it is the advantage prioritized by the people who
request default-and-builtin Uniscribe support. Am I right?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]