Date: 29 Dec 2001 00:56:20 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Mikhail Teterin <mi@aldan.algebra.com> Cc: ports@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: ports/print/ghostscript-afpl Makefile distinfo pkg-plist ports/print/ghostscript-afpl/files escputil.contrib.mak hpijs.contrib.mak patch-hpijs:makefile patch-hpijs:platform.h patch-src:unix-gcc.mak stp.contrib.mak ports/print/ghostscript-afpl/scripts ... Message-ID: <1009580184.225.0.camel@notebook> In-Reply-To: <200112282150.fBSLoZf35743@aldan.algebra.com> References: <200112282150.fBSLoZf35743@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-EHVDX3EGPWwe8cXaMd5Y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2001-12-28 at 23:50, Mikhail Teterin wrote: > On 28 Dec, Maxim Sobolev wrote: > > Mikhail Teterin wrote: > >>=20 > >> On 27 Dec, Maxim Sobolev wrote: > >> > On Thu, 2001-12-27 at 21:59, Mikhail Teterin wrote: > >> >> On 27 Dec, Mario Sergio Fujikawa Ferreira wrote: > >> >> > >> >> > - Better support for jpeg WRKDIR location > >> >> > >> >> According to the Ghostscript's Make.htm, the only reason GS > >> >> needs its own version of JPEG, is because Adobe's PostScript > >> >> interpreters "don't follow JPEG standard exactly". Which forces GS > >> >> developers to build JPEG with the following: > >> >> > >> >> #define D_MAX_BLOCKS_IN_MCU 64 > >> >> > >> >> perhaps, this is how we should build our JPEG port to start with > >> >> and make gs use -ljpeg, like everything else? > >> > > >> > What's the gain? > >>=20 > >> Generally, it is considered advantageous to share the common > >> libraries between different executables. Smaller run-time memory > >> requirements, smaller on-disk binary size, easier maintainance, etc. > >=20 > > I would say "no" if it means that the resulting library would read, or > > even worse produce, non-conformant jpeg images, >=20 > It will read JPEG images, that Adobe thinks are conformant. I think, it > is a good thing. As I say elsewhere, the define only affects the reading > part of the JPEG library. Which means, we become more accepting to what > others generate, while still generating only what everybody can accept. If they (Adobe) feel the right to violate the standard in their own propiertary format - so be it, but I don't see any significant reason why standalone non-conformat images shouldn't be rejected. > > especially considering that the code bloat is only around 100k. >=20 > Well, that's 100K of a library, that often is already mapped into RAM by > some other process -- speed. It is also 100K multiplied by the thousands > of FreeBSD installations -- gigabytes of disk space. Besides, the size > itself does not matter to me -- it is too practical a consideration. I > think, this would be The Right Thing [TM] to do -- regardless of the > size :-) I don't think it's a practical consideration, so what??? I don't see why our jpeg library should differ from the same libraries on the number of platforms out there. If you really think that this patch should go into FreeBSD libjpeg - try to convice JPEG folks instead. -Maxim --=-EHVDX3EGPWwe8cXaMd5Y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD4DBQA8LPiUoNu5t4iCBa8RAgGuAJj2d9jvQtbSBaUHoBekOpovC2WWAJ4zgqhI qAOnJs9HWBFwNNFZElQbtA== =WuOw -----END PGP SIGNATURE----- --=-EHVDX3EGPWwe8cXaMd5Y-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1009580184.225.0.camel>