[Clipart] Packaging and banned symbols

[Jon Phillips]

Glen Turner wrote:
> 
> Hi folks,
> 
> I was about to post a RPM .spec file for OpenClipArt
> when I noticed the discussion about legislatively-
> prohibited images.
> 
> To meet this requirement I'm re-working the .spec
> file and I'd like to ensure it meets with your
> approval before I put in too much effort.

Great! It would be excellent to have you on-board helping us create multiple 
packages. Generally we have been considering how to split up our packages.

> I am now considering the following packages
> 
>   openclipart
>     contains all images
> 
>   openclipart-de
>     obsoletes images in the openclipart package
>     that are legislatively-prohibited in Germany (DE)
>     with transparent images of the same dimensions
> 
> More generically
> 
>   openclipart-COUNTRYCODE
>     similarly for country with COUNTRYCODE
>     (eg: au)
> 
>   openclipart-COUNTRYCODE-JURISDICTION
>     similarly for JURISDICTION within COUNTRYCODE
>     (eg: au-sa, where SA is the state of South Australia)
> 
>   openclipart-COUNTRYCODE-JURISDICTION-CENSORSHIPCODE
>     similarly for CENSORSHIPCODE within JURISDICTION
>     within COUNTRYCODE
>     (eg: au-sa-pg, where PG is SA's classification Parental Guidance)
> 
> Obviously, this could be automated given appropiate
> meta-data in the images (in particular, a list of
> codes for which the image is outlawed).
> 
> Hopefully by substituting transparent images some
> interoperability across jurisdictions is retained
> (page formats are not broken, not "file not found"
> errors).  I'm not convinced that this is a good idea.
> Perhaps the file should just be obsoleted.

Right, I don't think it is good to have a file that is transparent or blanked 
out in any way, but better to just not include the files that are filtered out.

> The reason for a CENSORSHIPCODE is to allow computers
> in public places or schools to meet the sometimes
> peculiar censorship requirements of those situations.

That sounds interesting...is there a precedence for this? Or, any public 
standard on this? It would be good to stand behind some public standard on this 
topic.

> By obsoleting images out of the entire collection I
> hope to avoid a series of huge RPMs, most containing
> the same images.  It also limits the amount of meta-
> data required to be maintained.

Well, for something like a collection that is compliant for germany, it would be 
necessary to have images that would be in the largest package that has 
non-compliant images for germany in it.

> I also have a openclipart-httpd package which makes
> the clipart available to web pages hosted by Apache,
> by adding a configuration file to /etc/httpd/conf.d.
> A definitive statement on the URL for this would
> be appreciated, so that all distributions can align
> allowing web content to be easily moved.  I'm proposing
> "/openclipart" as the base URL.

So would this allow for anyone to have the distribution accessible at 
/openclipart, so enabling a basic mirroring of clipart for a website and its 
users use? Can you describe this more verbosely and what you are proposing by 
this. It sounds like a good idea. Also, could you provide a snippet for people 
to include in their httpd conf.d for this to work, please.

> BTW, before 1.0 please give some thought to directory
> structures. Changing these in production packages is
> near impossible (because it breaks documents which
> reference rather than include the images, in particular
> web pages).

Right, well, directory structures currently are temporary to get packages out. 
Our primary goal is to convert everything being keyword based, so that any 
template could be applied to the hierarchy and customization of packages. In the 
future our site and web services is being looked at as the primary way that 
users will get clip art. However, I think we are open for your recommendations 
on directory structure. Please check out the wiki for ideas and add your own 
please: http://www.openclipart.org/cgi-bin/wiki.pl

As for including absolute paths to linked images, this is something that needs 
to be fixed so that linked content within the primary SVGs is mobile. Is this 
what you are saying?

> Comments welcomed. I'd particularly like to align with
> the Debian package.

That sounds good...We haven't heard from the Debian maintainers directly, and I 
am curious as to what they are working on. Could someone update everyone on this 
please?

> As an artistically inept person I'd like to close by
> saying just what a marvellous a resource you are building.

Thanks Glen...it is great to have your contribution to the package. I really 
hope that you will continue in contributing to the project. We need more 
technical types, as we are getting a lot of submissions, but need help in 
technical infrastructure of the website.

Thanks!
Jon

-- 
Jon Phillips

USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)