accept issue.

add giuseppe to CC

"Terms of use

To anyone who acknowledges that the files "sRGB_IEC61966-2-1_noBPC.icc" and
"sRGB_IEC61966-2-1_withBPC.icc" are provided "AS IS" WITH NO EXPRESS OR IMPLIED
WARRANTY, permission to use, copy and distribute these file for any purpose is
hereby granted without fee, provided that the files are not changed including 
the HP copyright notice tag, and that the name of Hewlett-Packard Company shall
not be used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission. Hewlett-Packard Company
makes no representations about the suitability of this software for any purpose. "

"provided that the files are not changed [...]"

-> non-free.

The sentence is quite ambiguous though.
You can read it as "don't change it at all" or "don't change the copyright info
therwise you can change it"

You want to clarify with HP

In the first case it's definitely non-free

That said, icc-profiles, which contains other ICC profiles, is in non-free
(http://packages.debian.org/icc-profiles), so I'd bet HP/ICC means the first
possibility

I just looked a bit closer, and incindetially sRGB Color Space Profile.icm is
under the same license:

[...]
Hewlett-Packard Company

sRGB Profile Licensing Agreement:
To anyone who acknowledges that the file "sRGB Color Space Profile.icm" is
provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY: permission to use, copy
and distribute this file for any purpose is hereby granted without fee,
provided that the file is not changed including the HP copyright notice tag,
and that the name of Hewlett-Packard Company not be used in advertising or
publicity pertaining to distribution of the software without specific, written
prior permission. Hewlett-Packard Company makes no representations about the
suitability of this software for any purpose.

(ttp://packages.debian.org/changelogs/pool/non-free/i/icc-profiles/icc-profiles_1.0.1-4/icc-profiles.copyright,
last paragraph)
some files in icc-profiles are under the same license...

http://oyranos.org/ has a set of color profile which are supposed to be Free
software compliant.

I checked on http://oyranos.org/ but the ICC profiles pointed to from there are
all copyrighted material (the copyright is embedded in the binary file itself).

So I'm exploring the possibility to build the profile myself, the ICC profile
sRGB data computation and other related necessary stuff are described by Norm
IEC 61966-2.1:1999.

It seems that the necessary software is available here:
http://www.color.org/sampleicc.xalter ,in source, Public Domain licensed.

I'll be back ASA I worked out something.

@mh: I'm almost done with the creation of the custom sRGB file. 

There is a copyright section inside it. Should I write something or leave it empty?

Since I'm creating it myself from scratch I think it will be under the JCA I
signed, right?

I successfully created an ICC sRGB profile binary file using the public
available example code downloaded from http://sampleicc.sourceforge.net.

The profile file is copyright neutral, e.g. there is no copyright embedded in
the file, only the numerical data needed.

@mh: is it ok? Can I add it to the code and commit to the CWS?

If it's needed I can generate the human readable form of the profile and attach
it here.

beppec56: as you mentioned in your last-but-one post, there is a copyright
section. I'd mention the LGPL (JCA is implied for any code inside OOo anyway) to
not confuse people later which do not know about this issue.

wrt human readable: yes, would be good, although the ideal way would be to
commit the human readable form and generate the binary one on the fly from it
during the build with whatever tool is used/available for this (no clue about
ICC profiles..) or commit the code you used to generate this if this is possible
(no clue about ICC profiles..), build it and generate the file on-the fly by
running the program.
Thus you don't have a binary-only file there, can fix it if it's needed, have
cvs diffs etc..

@rene:

Actually you cannot obtain the binary form from the human readable one, with the
SampleICC library it's the other way around.

I'm sorry, it's going to be a long description, but I think it's better to have
a clear picture of the matter.

The steps I followed were:
1) got the SampleICC library from http://sampleicc.sourceforge.net.
2) hacked it to compile under Debian testing, current.
3) from a sample application in the sample library source code I obtained the
base code of a custom application and by modifying it I got what I needed to
build the binary ICC profile file (an application I named: create_sRGB_profile),
according to both the suggestions of ICC Consortium and IEC61966-2.1 (the
primary sRGB profile info source). The data in the profile binary file is
composed by the create_sRGB_profile application as this:
- the constant data are from the ICC recommendations and hardcoded in
create_sRGB_profile;
- the look up tables are computed by create_sRGB_profile.
- the other data (strings, other kind of constants) are hardcoded in
create_sRGB_profile.

What could we do?
1) the SampleICC library files have a header that's neither GPL nor LGPL (I'll
attach an example file), I don't know if it qualifies to be added as a tool to
the OOo source tree. If the library file header is fine with OOo build tools
license requirements, than:
2) the whole SampleICC library along with what I wrote to obtain a C++ header
file containing the profile to be added during the PDF/A-1 export can be added
to OOo source tree, so at build time:
- build SampleICC library,
- build  create_sRGB_profile, the header file generated by it moved in a
suitable position (in solver ??)
- then build vcl.
This procedure will assure a way to change the sRGB profile, should the need
arise in the future.

But while I successfully build the library and used it under Debian, I don't
know what to do under the other platforms OOo is built under. It can be a little
tricky, especially for me.
Besides I don't have the slightest idea of what to do to add a new module, what
to do to make vcl build dependent on it, etc...

I'll attach the 'human readable' form of the profile, where there is the
copyright note rene suggested (in the first hundred of lines, the remaining,
>3000, are numerical look up tables).

Created attachment 48194 [details]
Example SampleICC source file, for license check.

Created attachment 48195 [details]
The 'human readable' form of the ICC profile, for copyright check.

> What could we do?
> 1) the SampleICC library files have a header that's neither GPL nor LGPL (I'll
> attach an example file), I don't know if it qualifies to be added as a tool to
> the OOo source tree. If the library file header is fine with OOo build tools
> license requirements, than:

It's the 4-clause BSD (with advertising clause, so GPL-incompatible but (afaik)
LGPL-compatible)

No problem here.

> 2) the whole SampleICC library along with what I wrote to obtain a C++ header
> file containing the profile to be added during the PDF/A-1 export can be added
> to OOo source tree, so at build time:
> - build SampleICC library,
> - build  create_sRGB_profile, the header file generated by it moved in a
suitable position (in solver ??)
> - then build vcl.
> This procedure will assure a way to change the sRGB profile, should the need
> arise in the future.

Yep. That was my point. That's the preffered way.

> But while I successfully build the library and used it under Debian, I don't
> know what to do under the other platforms OOo is built under. It can be a
> little tricky, especially for me.

Well, we can try. And for Windows/Solaris-specifics we can ask the
Windows/Solaris people.

> Besides I don't have the slightest idea of what to do to add a new module,
> what to do to make vcl build dependent on it, etc...

I do. I can help..

Well, summing things up.
1) we can use the library and the application I wrote and adding it somewhere in
the OOo source tree;

2) I simplified the build process of the library in order to be able to build
only the library, some helpers and the needed application;

3) I tried to build the stuff under cygwin on Windows XP where I succeeded by
editing manually some file (for some reason the patches which applied fine under
Debian did't work under cygwin, probably due to \r\n source file termination). I
obtained an application that running under cygwin produced the header file I want.

4) the hxx files generated in the two platforms match (but the creation date,
that being internally will be different among the different platforms).

@mh:
can we go on adding the code somewhere in OOo source tree?
May be a new issue dedicated to this effort should be opened?

@rene: thanks for your offer to help in adding the stuff, I think I'll need it.

adding module external/icc should be then work out.

For anyone interested, I'm going to attach a tarball containing the code that
should become the new module under project external (the external/icc).

As stated in the README file inside it, you can build it under both Debian and
Windows/cygwin, obtaining the same result.

@rene: asking for the adding module help :-) . Can you have a look at the
archive? Building it should take only a few minutes. This is the best
description I can do to show what I need to do in the new module.
I think that the application I wrote, the diffs and the library source should be
put under cvs, whereas the script should be 'translated' into the OOo build
sequence.

I read the wiki at
http://wiki.services.openoffice.org/wiki/CWS#Create_a_new_module, and the two
links it refers to, but I didn't get it though, and before breaking anything I
think I'd better ask for help.
To be pointed out to some other module usable as example would also help.

@mh: do you think this should start in a new CWS, different from the one I
currently have pdfa in (beppec56pdfa1b)?

Last, the first comment of this issue should be updated to:

approval for sRGB Profiles generation library needed:
# Product Name: SampleICC
# Product Version: 1.3.2
# Vendor or Owner Name: International Color Consortium
# Vendor or Owner Contact: International Color Consortium
# OpenOffice.org Contact: Giuseppe Castagno, Philipp Lohmann
# Date of First Use / date of License: 2007
# URL for Product Information: http://sampleicc.sourceforge.net/
# URL for License: http://sampleicc.sourceforge.net/
# Purpose: Sample library to generate color scheme
# Type of Encryption: none
# Binary or Source Code: source

Created attachment 48232 [details]
tarball as explained in the former comment

beppec56: will do

I'm going to attach a tarball containing the subproject to be added to external.

The tarball contains the new parts to be added to external, expand it somewere:
the patch contained (external-icc.patch, m227 based) can be used to add the new
external/icc to external/prj/build.lst and  external/prj/d.lst, the tar archive
(external-new-icc.tar.gz) contains the new parts to be added to the project
external, it should be expanded in OOo source root.

The icc library and applications are build when the external project is build,
since it's build before vcl, I didn't modify the vcl build dependance. In this
way I don't think that a module alias is needed.

In the end a new file (sRGB-IEC61966-2.1.hxx) will be delivered to solver, to be
then included in the pdfwriter_impl.cxx file in vcl project.

I tried to build it on Windows, on a 2.2.1 build tree I have in place, I had to
modify the external build.lst and d.lst manually ( the  external-icc.patch
didn't worked there) but the library built and the include file was correctly
delivered.
In MAC and Solaris it's to be checked.

@rene: is this structure ok for OOo projects?

@pl: is this ok for vcl inclusion?

As soon as I have some feedback I'll see how to add it to CVS.

Created attachment 48305 [details]
first version of the icc subproject

the produced header is of course OK. The create_sRGB_profile.cpp seems to have a
BSD like  license, which I think is OK for the external project, could mh and
rene please verify ?

pl: yes, BSD is ok for external

@mh: do I have a go to add the files proposed here in desc22 above?

@mh:
This Sunday I had some spare time, so I tried to add the new project under
external/icc.
It seems that at least the directory structure went in all right.
Unfortunately even reading the stuff at:
http://wiki.services.openoffice.org/wiki/CWS#Adding_modules
I wasn't able to add the file under the right branch (should be
cws_src680_beppec56pdfa1b, right?).

I removed the files, since IMHO they were not in the right location.

I think that I need to have the new module (icc) added to CVSROOT/modules, so to
be able to add it to my CWS.
Well, unless I miss something or the license stuff is not right...

Let me know how to proceed, in order to have the issue 59651 CWS ready for QA in
time; last CWS integration (UI freeze scheduled for 2.4 on Now 15th) is not that
far away.

@mh: after a couple of weeks without answer, I think a good temporary solution
would be to commit to my cws only the include file I produced
(sRGB-IEC61966-2.1.hxx inside tarball in desc22, above) stripping from it all
external references and adding it to the vcl/inc/vcl directory.

This because I'd like to check the cws on buildbots.

@pl: technically speaking there shouldn't be any problem, right?

When and if it will be possible, I'll add the repository the whole stuff needed
to rebuild it.

sorry, I'm also still waiting for approval, will come back to this this week, 

technically there is no problem at all.

And sorry for the delay, as soon as you have to get a lawyer to allow something
you're practically doomed ;-)

ping ? We need this for 2.4, so I'd hope we can get the approval soon ?

ping myself.

approved.

Accepted.
As soon as m238 is out I'll start adding the code to a new cws, along with some
polishing I have to do on pdflinks and PDF/A-1.

@rene: about that help on adding a module...

What would be the best course of action, adding a new alias icc for external/icc
or simply use the new icc as a subproject of external?

If I got things correctly, in the first case I need to rise another issue to
have the new alias declared.

the first

Hmm, I wonder what's so bad about a standard and thus presumably fixed ICC
profile that has a license that prohibits changing it? Isn't that a *good thing*
if it prevents proliferation of slightly different sRGBs profiles? Or am I
missing something...?

Hmm, I wonder what's so bad about a standard and thus presumably fixed ICC
profile that has a license that prohibits changing it? Isn't that a *good thing*
if it prevents proliferation of slightly different sRGB profiles? Or am I
missing something...?

Set fixed

Reassign to pl.
Please verify it in cws beppec56pdffix02.

Verified in CWS beppec56pdffix02

seen in OOH680m5, closing