Dan Nicholson wrote:
--with-gs-aa-params="-sDEVICE=x11alpha -dNOPLATFONTS
-dGraphicsAlphaBits=4 -dTextAlphaBits=4": Slower CPUs may not handle
the default -dDOINTERPOLATE parameter for Ghostscript well.
Removal of -dDOINTERPOLATE would reintrioduce the bug.
--
Alexander E. Patrakov
--
http://
Dan Nicholson wrote:
But, in the bug report you say that older machines may not handle
-dDOINTERPOLATE well for large bitmap files.
In the bug, I reported a 2x slowdown. However,
1) it happens only on huge bitmaps that are uncommon
2) owners of slow machines won't build LFS
3) Your --with-gs-
On 2/12/06, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote:
> Compile Evince 0.5.0. It has this bug fixed. Just for the reference:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=319049
If I understand correctly from looking at evince-0.5.0 configure, the
default is now:
-sDEVICE=x11alpha -dNOPLAT
Randy McMurchy wrote:
Hi all,
This is mostly directed to Alexander, as he has provided input on
this very subject in the past, and seems to have a real good handle
on it. Anybody else can, of course, comment or provide input as well.
Seems I remember that we left GGV in the book because it does
Randy McMurchy wrote:
Chris Staub wrote these words on 02/07/06 21:39 CST:
Submitting some changes to the text at the beginning of the BLFS book...
I applied and committed your patch, Chris. I hope you don't mind I
took the liberty of some minor changes. Thanks for sending it in.
The change
Ivor Hewitt wrote:
>Hi,
>Building nfs-utils on an x86_64, gcc4.0.2 machine I needed the following small
>patch.
>
>
This patch is already in the repo,
http://www.linuxfromscratch.org/patches/downloads/nfs-utils/nfs-utils-1.0.7-gcc4-1.patch
--
http://linuxfromscratch.org/mailman/listinfo/blfs-d
Hi,
Building nfs-utils on an x86_64, gcc4.0.2 machine I needed the following small
patch.
Regards,
Ivor.
--- support/rpc/svc_auth_gss.c.old 2004-10-19 01:23:05.0 +0100
+++ support/rpc/svc_auth_gss.c 2006-02-13 00:22:32.0 +
@@ -382,7 +382,7 @@
r
Hi all,
This is mostly directed to Alexander, as he has provided input on
this very subject in the past, and seems to have a real good handle
on it. Anybody else can, of course, comment or provide input as well.
Seems I remember that we left GGV in the book because it does a
better job at renderi
Chris Staub wrote these words on 02/07/06 21:39 CST:
> Submitting some changes to the text at the beginning of the BLFS book...
I applied and committed your patch, Chris. I hope you don't mind I
took the liberty of some minor changes. Thanks for sending it in.
--
Randy
rmlscsi: [GNU ld version
Joe Ciccone wrote these words on 02/12/06 15:57 CST:
> I said I would test it as soon as I finished building packages. I
> encoded a video on my windows machine and played it back on my pII
> 366Mhz laptop in totem and mplayer and it didn't skip one bit and looked
> normal.
Only thing is that it
Dan Nicholson wrote:
>Joe, did you try the new codec yet?
>
I said I would test it as soon as I finished building packages. I
encoded a video on my windows machine and played it back on my pII
366Mhz laptop in totem and mplayer and it didn't skip one bit and looked
normal.
--
http://linuxfromscra
Randy McMurchy wrote:
Randy McMurchy wrote these words on 02/12/06 11:18 CST:
2. Bugzilla, functionality-wise seems to be better.
f) (just noticed) In a previous entry I enumerated some items
as 1. 2. 3. ... Later in the entry I referenced one of the
enumerated items as #2. Unknow
Randy McMurchy wrote these words on 02/12/06 11:18 CST:
> 2. Bugzilla, functionality-wise seems to be better.
f) (just noticed) In a previous entry I enumerated some items
as 1. 2. 3. ... Later in the entry I referenced one of the
enumerated items as #2. Unknowingly, and without any i
Hi all,
Now that I've actually *used* the Trac Ticket system, I feel I can
now provide comment as to its functionality. I never did provide
comments about functionality before, as I had not used it, I only
offered opinion on the reasons for changing and the method used to
implement Trac.
I don't
On Sun, Feb 12, 2006 at 10:30:16AM +0500, Alexander E. Patrakov wrote:
>
> However, I am not sure that this solution is indeed optimal. Reason: Bug
> 1648 is open for three months, this probably means that no editors use
> Mutt, and they are happy enough to ignore its brokenness. There is no
>
On Sunday 12 February 2006 09:06, you wrote:
>Bruce Dubbs wrote:
>> I think your observation is correct. Right now, we have mutt, pine,
>> and slrn. Perhaps we should drop these packages and just mention
>> them in the section "Other Mail and News Programs."
>
>+1 to "mention mutt, pine, tin and
On Sun, 12 Feb 2006, Bruce Dubbs wrote:
Right now, we have mutt, pine, and
slrn. Perhaps we should drop these packages and just mention them in
the section "Other Mail and News Programs."
OTOH, I have used nail on occasion, but certainly not regularly. It is
most useful in sending messages
Bruce Dubbs([EMAIL PROTECTED])@Sun, Feb 12, 2006 at 12:50:19AM -0600:
>
> I think your observation is correct. Right now, we have mutt, pine, and
> slrn. Perhaps we should drop these packages and just mention them in
> the section "Other Mail and News Programs."
>
> OTOH, I have used nail on oc
Bruce Dubbs wrote:
> Alexander E. Patrakov wrote:
>> Hello,
>>
>> I was going to report two issues in the current BLFS, but when expanding
> OTOH, I have used nail on occasion, but certainly not regularly. It is
> most useful in sending messages from scripts, so that package should stay.
>
> Oth
Bruce Dubbs wrote:
I think your observation is correct. Right now, we have mutt, pine, and
slrn. Perhaps we should drop these packages and just mention them in
the section "Other Mail and News Programs."
+1 to "mention mutt, pine, tin and slrn in that section instead of
giving explicit inst
20 matches
Mail list logo
