[crossfire] Arch repository: layered art files?

[Mark Wedel]

David Delbecq wrote:
> En l'instant précis du 13/12/07 06:22, Mark Wedel s'exprimait en ces
> termes:
>>
>>   I'm a bit less sure if having a bunch of formats sitting about in the arch 
>> directory would be a good thing.  A concern I have is of formats which no one 
>> can easily use, and there is not certainty if anyone in fact is still using 
>> those images (hypothetical case here is someone adds some new images in some 
>> image format, and then disappears from the crossfire world.  Two years later 
>> ability for anyone else to read the originals may be gone, and not certain if 
>> anyone would care if they were removed).
>>   
> Well, either someone change that arch in future without being able to
> open source format, then he removes the old source file (eg caril draw
> 69.2.0.44) and provide his own one (gimp) matching the new arch picture.
> Then the old format disappear by itself from repository. Since svn
> handles deletion of files/directory properly, this is not a problem.
> Either no one change the arch, then i see no problem with keeping the
> source file. It's in accordance to GPL (you know, the provide source
> section) and maybe that guy will come 2 years later to redo some of his
> art work :D

Fair enough.  But suppose someone checks something in using adobe photoshop 
format, and a month later I want to change the image, but don't have photoshop.

  Is it OK then for me to remove the original (source) photoshop image and just 
have a PNG?  Even if the original author is still around, maybe he doesn't have 
time to make the change in the near future.

  I don't really mean belabor this point, but it is something that is going to 
come up.  The person that did the photoshop image may be upset that his source 
has been removed, but the person making the change didn't really have much choice.

  Now it may be that the answer is simply 'if the original artist is unable to 
make the change, no matter the reason, that the source file gets removed' is the 
rule, and I'd be fine with that.  But we just need to state that upfront so no 
one is surprised.

  And gimp's .xcf files are another odd case here.  Pretty much every linux 
distro will have gimp, but folks using windows or mac would need to download it. 
  Should it be considered proper that the mac/windows person download gimp and 
update the .xcf file, or is it ok for them to just write out a png and remove 
the .xcf source?

>>   Having everyone use a same format may not work.  But at the same time, if the 
>> format being used is obscure enough that only that single developer uses it, 
>> having that source checked in really gains nothing.
>>   
> But it cost nothing too, if we keep sopurce arch in a separate folder.
> When you want to edit arch monsters/kobold_111.png, you just have to
> list content of svn repository src/arch/monsters and checkout the source
> file you need.

  Disagree - it costs something here.  I'm not really concerned about the space 
- that is trivial.  But more the case of whenever I want to modify an png file, 
these are potential steps:

1) Check to see if the is a 'source' version of that file in the other repository.
2) If so, is it a format I can currently read & write?
3) If not, is it in a format I can easily get a program that can read/write it 
(or maybe we don't care about this, depending on comment above)
4) If can't get software & can't write it, now need to remove it from repository

  Now all that looks fairly trivial.  But if things got to the point where there 
was a dozen different formats out there, and there was some change you wanted to 
make to a bunch of image (lets take layering/animation - maybe you want to add 
an bow layer to a bunch of monsters), that could start to get annoying.

  OTOH, it could just be left as a free for all.  images are not changing that 
much, and you can always pull out old versions if someone overwrote a png you 
modified because they used the source that you weren't able to edit.

>>   As a compromise, I'd suggest that in principal, any format may be allowed, but 
>> has to be approved/discussed on a case by case basis.  For fairly popular 
>> formats or programs, that should pretty much be a rubber stamp.  But if someone 
>> pops up and wants to add a format no one has ever heard of, answer is probably no.
>>   
> Do we have yet a formal general approval process? If yes am ok with it,
> if no, that would just mean the commiter will have final word.

  I'd think in most cases, it would be fairly clear cut.  Everyone readily 
agreed to gimp .xcf

  If the quick vote is less clear cut, a more formal vote like has been done in 
the past could be done.  Note that inability to commit the source image files is 
unlikely to be a time sensitive issue - you could still commit the png files 
generated from them, so if it just turned out it was a few weeks before you 
could commit the source files, not likely an issue.

  And depending on what we decide in terms of image formats that users can't 
read, I'd guess that would clarify voting.

  For example, if the rule is something like 'if you don't have the program to 
deal with the source image, just update the png and delete the source image', I 
have a feeling most formats would quickly get accepted - I'd have no problems 
letting photoshop images be committed in that case, as it doesn't affect me much 
- just means I have to svn delete the source each time I modify an image.

>>   Last note would be licensing - I don't know if it would be an issue or not, 
>> but crossfire is GPL, and thus all files so checked in must be comformant with 
>> that license.  If adobe or other software has restrictions on what can be done 
>> with the data files, etc, that would be another reason to disallow software (an 
>> example could be the file format itself is patented, and thus freely 
>> redistributing files in that format requires some licensing or permission)
> Am not aware of such restriction. What you produce with a tool, in
> europe, afaik, can not subject to conditions coming from tool itself.
> The only problem i might see is general scurity and exportation laws,
> that could restrict distribution of a format that uses heavy
> cryptography but a crypted file in src is useless :) The licensing rules
> of a format (patents, etc) apply to algorithms uses to create / read
> that format, that mean someone might be required to acquire a commercial
> software to open the source file, but that's hardly agains the gpl license.

  I wasn't sure on that one.  I'd tend to guess images formats that are patented 
are less likely to be readable in other programs, but that isn't as much an issue.