From owner-freebsd-ports Tue May 15 10:42:20 2001 Delivered-To: freebsd-ports@freebsd.org Received: from panda.pearlview.com (00-c0-df-46-9c-29.bconnected.net [209.53.12.21]) by hub.freebsd.org (Postfix) with SMTP id 49CE537B424; Tue, 15 May 2001 10:42:04 -0700 (PDT) (envelope-from kellyzg@hotmail.com) Date: Tue, 15 May 2001 17:28:32 +0000 (UTC) From: "Leonard K." To: Mikhail Teterin Cc: , , , , Subject: Re: GhostScript and JPEG In-Reply-To: <200105151458.f4FEwrt62595@aldan.algebra.com> Message-ID: <20010515172345.Q4904-100000@panda.pearlview.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-Status: X-Keywords: X-UID: 1 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 15 May 2001, Mikhail Teterin wrote: > > Ok, this is an argument to keep C_MAX_BLOCKS_IN_MCU at 10, but to bump > up the D_... to 64. Any objections to me applying this change to the > jpeg port? (JSeger seems to be off-line for months :( ) Then the > ghostscript ports can be modified to the shared jpeg library. Just out of curiosity: if we bump the jpeg library's 'max block' to 64, and I use the library to write a new jpeg file (using maybe xv), would the new file be sometimes non-standard-compliant and thus be rejected by some viewers ? (I guess what I mean to ask, is that whether the few arrays affected are only used during decoding, or if they're used during encoding as well.) If so, then in my humble opinion I think we need to keep jpeg library the way it is, and let ghostscript fend for itself. - LK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message