On Fri, May 21, 2010 at 09:51:36PM +0200, Jonas Smedegaard wrote: > On Fri, May 21, 2010 at 08:19:23PM +0200, Bill Allombert wrote: > >On Fri, May 21, 2010 at 05:11:18PM +0200, Jonas Smedegaard wrote: > > >>> #define D_MAX_BLOCKS_IN_MCU 64 > > >>Please provide a variant of libjpeg with above definition > >>declared, so that Ghostscript (and perhaps other projects as > >>well?) can use the shared code while still staying compatible > >>with non-standard Adobe Postscript files. > > > >Do you have a test file that I could use while building libjpeg to > >prevent an update to libjpeg to accidentaly breaks that feature? > > Good idea! > > No, so far I only have that quoted text. I will ask upstream: most > of their VCS commit messages refer to a large pool of test files > used for regression tests, so quite likely they can dig out a sample > for exactly this. > > I guess this means you are interested in supporting this?
Interested yes, but unfortunately after writing this email I discovered this was not possible. The problem is that this change breaks both the API and ABI of libjpeg62, and unfortunately providing a second libjpeg62.so with a different ABI would cause the same symbol clashes problems than was caused by libjpeg8, so I could only provide a static library, which seems more trouble that benefit. Now two points: 1) In twelve years, there are not been a single DSA issued against libjpeg6b. 2) I assume that ghostscript only generated stadard jpeg in postscript file. Since Adobe has mostly moved to PDF, is there still a lot of such non-standard Adobe Postscript files in use ? Cheers, -- Bill. <[email protected]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
