That was the initial plan, but I found out that having FreeType grok
such fonts required more changes than David Turner was wililng to make
in the 2.1.* series. So I'm generating a zero-length glyf and a
one-entry loca. (No EBSC indeed.)
Ok, I'm currently posting a new build of PfaEdit which will
On Tue, 15 Jul 2003, Alex Deucher wrote:
> This proposal comes up periodically on this and other xfree lists, but
> never really goes anywhere. Why not raise money from the open source
> community to fund open source driver development?
It is very difficult to convert money into code. It's
HI!
I would be interested in contributing on drivers in open source
development ,provided I have resources like datasheets and H/W details.
Could u let me know more about this?
Regards,
Nitin Mahajan
mail:[EMAIL PROTECTED]
Ph:51101667. Mobile : 9886099925
==
The
This sounds like a great idea indeed. There are many questions, I'm sure.
One that comes to mind is:
*Who* would be able to vote?
Luis
On Tue, 15 Jul 2003, Alex Deucher wrote:
> This proposal comes up periodically on this and other xfree lists, but
> never really goes anywhere. Why not
This proposal comes up periodically on this and other xfree lists, but
never really goes anywhere. Why not raise money from the open source
community to fund open source driver development? everything from
revamping X (ie, speeding up the development of 5.0 features) to adding
a new Xfree86 3D dr
On 15 Jul 2003, Juliusz Chroboczek wrote:
> MLF> I think the best thing to do here is to recode DPS to rely on xtrans.
> Shall we remove libdps from the tree?
Why? Is DPS dead? It's just a matter of time before I find the time to
convert it. And that doesn't preclude someone else beating me t
MLF> I think the best thing to do here is to recode DPS to rely on xtrans.
Shall we remove libdps from the tree?
Juliusz
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
GW> Is there a real need to distinguish between bitmap only and ouline
GW> sfnts?
I feel that having the same extension for bitmap and scalable fonts is
confusing -- without a naming extension, you need tools such as ftdump
to find out what your fonts are.
GW> I presume that an .otb font would ju
>> As far as I know, Microsoft doesn't use bitmap-only sfnts -- they use
>> scalable fonts throughout, nowadays, only keeping the legacy .FON
>> format for backwards compatibility.
TR> Windows XP still has Terminal, Courier, MS Serif and MS Sans
TR> Serif, all of which are bitmapped and in common
> The best thing to do is file a bug report in bugzilla at
> http://bugs.xfree86.org and attach your patch to the bug report
> as a unified diff (diff -Naur) to the report using the bugzilla
> file attachment feature. You should ensure the patch applies to
> the current developmental CVS head
Nick Hudson writes:
> On Tuesday 15 July 2003 4:00 pm, Marc Aurele La France wrote:
> [...]
> > The imake rule in question will not be removed because there is nothing
> > to preclude its use by external packages such as those found in X.Org's
> > contrib/.
>
> Ok. Thanks for explaining.
>
On Mon, 14 Jul 2003 20:58:21 -0700 (PDT), Alan Messer wrote:
>
>I've been using the 4.3.99 CLE266 (ProSavage) driver
>on my Via EPIA M1 board.
The CLE266 is a Castlerock, not a ProSavage. To the best of my knowledge, the
two chips are unrelated.
--
- Tim Roberts, [EMAIL PROTECTED]
Provid
On Tue, 15 Jul 2003, Nick Hudson wrote:
> > The imake rule in question will not be removed because there is nothing
> > to preclude its use by external packages such as those found in X.Org's
> > contrib/.
> Ok. Thanks for explaining.
> Am I on a road to nowhere in attempting to change the build
On Tuesday 15 July 2003 4:00 pm, Marc Aurele La France wrote:
[...]
> The imake rule in question will not be removed because there is nothing
> to preclude its use by external packages such as those found in X.Org's
> contrib/.
Ok. Thanks for explaining.
Am I on a road to nowhere in attempting to
On Tue, Jul 15, 2003 at 11:49:42AM +0200, Daniel Blueman wrote:
>An alternative would be to update the freetype support in XFree86 mainline,
>to the current version.
I don't know anything about the context of this discussion, but the
XFree86 CVS trunk has FreeType 2.1.4, which appears to be the cu
On Tue, 15 Jul 2003, Nick Hudson wrote:
> On Tuesday 15 July 2003 1:32 pm, Marc Aurele La France wrote:
> [...]
> > I feel that the fact SharedLibObjCompile() is unused in our _current_ tree
> > is insufficient reason to remove it.
> It provides nothing over and above NormalSharedLibObjCompile wh
On Tue, 2003-07-15 at 16:17, Michel Dänzer wrote:
[ citation without new stuff ]
Sorry about that, fun time with Evolution. :\
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer
_
> > >>> latest CVS build (by myself) as of yesterday (4.3.99...)
> > >>
When did you try exactly ? I've seen more fixes for TMDS getting
in the CVS recently. I'm not sure what's up here, definitely not
something the doc explains. I suspect it's the path of pixel
data from the framebuffer to the TM
On Wed, 2003-06-04 at 14:11, Simon Urbanek wrote:
> On Wednesday, June 4, 2003, at 01:19 AM, Michel Dänzer wrote:
>
> > On Tue, 2003-06-03 at 15:22, Benjamin Herrenschmidt wrote:
> >> On Fri, 2003-05-30 at 11:52, Simon Urbanek wrote:
> >>> Summary:
> >>> 1) CRT + TMDS dual head configuration does
VIA/S3 released fully featured driver that it developed in house. they
were based on 4.2.0. VIA had previously released a 2D only driver for
the CLE266, which was integrated into xfree86 CVS. The released
drivers are available on Alan Cox's website:
http://www.linux.org.uk/~alan/S3.zip
http://w
Hello,
> As per xc/programs/Xserver/hw/xfree86/common/atKeynames.h:
>
> /*
> * Fake 'scancodes' in the following ranges are generated for 2-byte
> * codes not handled elsewhere. These correspond to most extended keys
> * on so-called "Internet" keyboards:
> *
> * 0x79-0x93
> *
On Tuesday 15 July 2003 1:32 pm, Marc Aurele La France wrote:
[...]
> I feel that the fact SharedLibObjCompile() is unused in our _current_ tree
> is insufficient reason to remove it.
It provides nothing over and above NormalSharedLibObjCompile which is used.
Maybe I'm wrong...
Nick
___
On Tue, 15 Jul 2003, Nick Hudson wrote:
> I sent a patch in
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg01959.html
> was this the wrong place to send it? Can someone commit it/give me feedback?
I feel that the fact SharedLibObjCompile() is unused in our _current_ tree
is insufficient rea
I sent a patch in
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01959.html
was this the wrong place to send it? Can someone commit it/give me feedback?
Thanks,
Nick
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Alan Messer writes:
> Tim Roberts wrote:
> > I've recently been made aware of the XFree86 Savage
> > driver that VIA released
> > and is now available on Alan Hourihane's web site.
> > This driver is so much
> > superior to the one I've been maintaining that I
> > should be embarrassed.
An alternative would be to update the freetype support in XFree86 mainline,
to the current version.
This would benefit would yield much higher benefit, I think
What caveats would that bring about? What about the development costs?
> Daniel schrieb:
>
> > Any takers?
>
> > This sounds like
26 matches
Mail list logo
