Re: [Lcms-user] Re: tifficcc and jpegicc

[James Burgess]

Marti,
I'd like to propose a bit of a change in lcmsio1.c. The purpose of this is to help people integrating lcms into other existing applications and libraries. The problem comes from the implementation of how LoadProfileFromMemory works and how in fact file reading in general happens. I'll outline the problem, then my proposal here.

The current implementation (you know all this but for other readers this is necessary) right now all profile reading happens by lcms making calls the fopen() and friends, which is true even of opening profiles from memory. Behind the scenes those are written to a file. I want to use lcms in an environment where I already have the profiles in memory (in opaque chunks of bytes) and I want to hand them to lcms. I don't for a variety of reason want to open any more files and more importantly I'm going to have a lot of profiles open (for reading).

I don't really want to change from using fopen() for files as we pretty much have that on most platforms now. But for reading from memory I really don't think writing a temp file is necessary or desirable. My solution is to copy what many other libraries do which is to centralize all of the IO into a set of function pointers in the profile structure which can them be implemented in any way the application wants. So a few new fields would be added to the profile structure with the following types.

typedef int (LCMSOpenFileProc*)(const char* path, const char*mode, void *clientData);
typedef int (LCMS OpenFromMemFileProc*)(void* bytes, size_t length, const char*mode, void *clientData);
typedef size_t (LCMS ReadProc*)(void *clientData, void* data, size_t size, size_t count);
typedef size_t (LCMS WriteProc*)(void *clientData, const void* data, size_t size, size_t count);
typedef int (LCMS SeekProc*)(void *clientData, ssize_t size, int whence);
typedef int (LCMS CloseProc*)(void *clientData);

Two flavors of each of the profile creating functions are then provided - one with the default implementation and one where you get to pass in a value for each of the above fields. The open-from-memory call can then have a default implementation that just uses pointer arithmetic to move around some memory.

A couple of issues come up which are the semantics of having the profile "open" and whether the lcms library is allowed to do a write at any moment. I think this should just be cleared up with extending the open mode parameter to allow a "r" as well as a "w".

What do you think? Yes I'm going to volunteer a patch.




-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user