[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] FT_Set_Hint_Flags problem
From: |
David Turner |
Subject: |
Re: [Devel] FT_Set_Hint_Flags problem |
Date: |
Tue, 29 Apr 2003 17:31:04 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 |
Hello Owen,
Owen Taylor wrote:
On Thu, 2003-04-24 at 13:04, David Turner wrote:
I don't know about RH 9, by the way, the "problem" might still persist
as well.
No, I switched over to setting the target, and made that work.
(remember the patch that I sent you?)
I remember the patch, I just didn't realize it was for RH9 :-)
But anyways, from *my* perspective, if we use something that
isn't in the public API, or is marked experimental, and you
break it, that's our problem, and if people complain, just point
them at us. It's my responsibility to:
A) Make sure that things as well as possible in each version.
B) Make sure that things work when upgrading between Red Hat
versions.
I understand your point of view, but mine is that 99% of users
who encounter this kind of problem will think it's either their
own fault, or that of FreeType. Only a fraction will ask about it
on the mailing list, or dare to look at the archives for more
information. The rest will just grow frustated.
Leaving the function in the 2.1.4 release code was a very simple
way to avoid confusion for *many* people, and speed up its adoption
to more systems.
Apart from that, and joke aside, it's free software: you're absolutely
free to do wathever you want with the code, and I'm free to be a bit
angry about certain of your changes :-) this should prevent us from
working together when needed anyway.
> But if a new version of the FreeType package requires a new
> version of the Pango package, well, that's a side effect I
> can't always prevent. What we certainly would avoid is making
> 3rd party applications compiled against release depend on
> customizations in our packages that might change in future
> releases.
Since we're talking about it, I'd like to find a way to get rid
of these horrible (IMO) uses of FreeType internals within Pango.
You did went through various autoconf hacks to make this seamless
when building the library, but problems arise sometimes when trying
to build Gnome on non-standard locations or setups.
Would you be interested if we provided in FT2 an API similar to
what FT1 does and the code you ported from there to Pango ? I was
thinking about performing the following:
- providing an API similar to what FT1 provides to manage
OpenType Layout tables. This assumes you didn't make too
many changes to the code when "porting" it to
Pango + FreeType internals.
- bringing back the old stream functions within the library,
as simple calls to the new ones. this, to avoid "breaking"
old Pango installations when upgrading FreeType.
- maybe even bring back a dummy FT_Set_Hint_Flags for the
same reasons :-)
I've re-started working on "src/otlayout" but the final code
will not be available before long. In the mean-time, sort of
porting the old FT1 code to FT2 should be easy, even if the
implementation is a bit intimidating..
And I'd like Werner's opinion on the subject too...
Cheers,
- David Turner
- The FreeType Project (www.freetype.org)
--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
CANAL+TECHNOLOGIES will not therefore be liable for the message if modified.