Date: Fri, 28 Dec 2001 16:50:32 -0500 (EST) From: Mikhail Teterin <mi@aldan.algebra.com> To: sobomax@FreeBSD.org 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: <200112282150.fBSLoZf35743@aldan.algebra.com> In-Reply-To: <3C2C362F.7A151056@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Dec, Maxim Sobolev wrote:
> Mikhail Teterin wrote:
>>
>> 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?
>>
>> 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.
>
> I would say "no" if it means that the resulting library would read, or
> even worse produce, non-conformant jpeg images,
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.
> especially considering that the code bloat is only around 100k.
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 :-)
--
|\__-----__/|
_____/ ::::: :::\_____
'__--( ::::::::..::)--__` -mi
If you have a / _- \/ :::::::\/ -_
serious knowledge / / :. .::::\ \
about computers -- | ::::::::::::| Ok, let's say you broke
keep it in a secret! _|/ ::::____::\|_ the wall with your head
"Rules of dating", / /:::::/:_::\::\:.\ What are you going to
'Playboy', ? 1994 | :| ..:(_/ \::|::|::| do in the next cell?
| :|:::::. ::|: |::|.:| Stanislaw J. Lec
\ |:: :::_/::/: :|:/
((___\____\____/___/___))
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?200112282150.fBSLoZf35743>