Re: Map Symbols [was Re: [Sodipodi-list] Getting lines straight]
Maybe a novel idea would be to make separate project on sourceforge that is svg clipart. Like svg-clipart.sf.net would be great.
The benefits would be open source designing of symbols, maps, etc for the SVG-compliant community.
It might also be nice to push the artwork developed via different SVG apps to a standard, well defined place that might promote interoperability and compliance of all,or many :) ofthe different SVG drawing programs.
It would be totally cool to use CVS to design with and allow ppl. from all over the world to work on designs.
Thoughts? (I hope I haven't just gotten a little too utopian)
Jon
On Fri, 2003-12-05 at 07:03, Pat Suwalski wrote:
Áki G. Karlsson wrote:
Hi
I would be more than happy to participate in a svg map symbols project, contributing images like below that are most relevant for my present work...
I am just worrying that maybe the sodipodi list doesn't want to be subjected to it and that it would perhaps be better served as, say, a part of wikitravel...
Should I be starting a "map symbols" clipart section on the sodipodi web site?
Right now, I'm still a little fazed by the whole sodipodi.com thing.
--Pat
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Sodipodi-list mailing list Sodipodi-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sodipodi-list
Hi
Maybe a novel idea would be to make separate project on sourceforge that is svg clipart. Like svg-clipart.sf.net would be great.
It would surely be great and have a high degree of usability. Question is then, how can it best benefit/promote free software like sodipodi? ("ask not what sodipodi can do for you, ask what you can do for sodipodi" ;) Is an independent repository of svg better than an application-tied clipart gallery (like dia has fex)? The flag rally DID increase visibility of sodipodi, for example.
It would be totally cool to use CVS to design with and allow ppl. from all over the world to work on designs.
Is that better than any peer-review system (a mailing list fex)? (I've never used cvs except for downloading development snapshots.) The key is probably active developers and admins, as always, I expect.
*Continuing the case for map symbols... (the wikitravel mapmaking thing really got me started ;)
Having map symbols available in svg is nice (understatement) because it allows people to adapt the symbols to national requirements, traditions, overall design of the map etc. It will also be very useful for a lot of website design and even logo design. The designs could even, with a certain degree of exactness, be used for making actual roadsigns... (hence useful for municipalities, hence useful for promoting linux on the desktop :):)
They could be used as a basis for another free-as-in-freedom dingbats font...
Map symbols present a high degree of standards-defying environmental/cultural/industrial diversity that has been best served in open-source projects (see pango). US road number signs are different from European signs, but i've seen the road "badge" used in various restaurant logos in Europe... In the service signs dpt. I'm hoping to see things like "ostriches crossing", "kosher restaurant", "camel rental", "left-hand driving ahead" and "pet washing facilities". In return I have some beauties like "seal nurturing grounds" and "whale-watching".
Point is, it's useful, interesting and fun... :)
Best regards
Áki
On Fri, 2003-12-05 at 07:03, Pat Suwalski wrote:
Áki G. Karlsson wrote:
Hi
I would be more than happy to participate in a svg map symbols
project,
contributing images like below that are most relevant for my present work...
I am just worrying that maybe the sodipodi list doesn't want to be subjected to it and that it would perhaps be better served as, say, a part of wikitravel...
Should I be starting a "map symbols" clipart section on the sodipodi web site?
Right now, I'm still a little fazed by the whole sodipodi.com thing.
--Pat
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Sodipodi-list mailing list Sodipodi-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sodipodi-list
Removing CC'es, I really dont like crossposting so I try not to do it. if this message is still relevant feel free to forward it.
Maybe a novel idea would be to make separate project on sourceforge that is svg clipart. Like svg-clipart.sf.net would be great.
not what sodipodi can do for you, ask what you can do for sodipodi" ;) Is an independent repository of svg better than an application-tied clipart gallery (like dia has fex)? The flag rally DID increase visibility of sodipodi, for example.
[is 'fex' the username of someone inlcuded in the crosspost? It is quite confusing I dont know the word at all]
Dia shapes/clipart/symbols could be made more generally reusable. Most of it is SVG based with some additional markup for things like connection points and I've said before that it could reasonably easily be converted to SVG with embedded Dia instead of dia with embedded SVG to simplify things for other applications.
Dia cannot yet reuse other projects SVG clipart (sodipodi flags, jimmacs fantastic icons and artwork) because it only has very simple SVG support (any an all help would be very much appreciated, the Dia developers always welcome patches, both simplifying and standardizing the SVG in the collections and getting Dia to handle namespaces properly are what is needed to start).
*Continuing the case for map symbols... (the wikitravel mapmaking thing really got me started ;)
Dia has some Map Symbols, if i recally correctly Ian Redfern used his perl scripting to generate files for Dia from PDF (and postcript i think), and i think he had plans to update his script to also generate pure SVG.
Having map symbols available in svg is nice (understatement) because it allows people to adapt the symbols to national requirements, traditions, overall design of the map etc. It will also be very useful for a lot of website design and even logo design. The designs could even, with a certain degree of exactness, be used for making actual roadsigns... (hence useful for municipalities, hence useful for promoting linux on the desktop
They could be used as a basis for another free-as-in-freedom dingbats font...
Symbol libraries, vectors, fonts, - head spinning. SVG seems to be the best format to standardize upon, I'll assume you mentioned dingbats because of some special license it has rather than suggesting using Fonts to store libraries of vector symbols.
Point is, it's useful, interesting and fun... :)
I'd love to see a shared library of clipart, preferably in a cleaned homogenized SVG and installed to a standard location (freedesktop.org anyone?) with a few categories that could be shared across any application that was interested (I'm thinking Gnome-office).
Sincerely
Alan Horkan.
On Sun, 7 Dec 2003, Alan Horkan wrote:
Maybe a novel idea would be to make separate project on sourceforge that is svg clipart. Like svg-clipart.sf.net would be great.
not what sodipodi can do for you, ask what you can do for sodipodi" ;) Is an independent repository of svg better than an application-tied clipart gallery (like dia has fex)? The flag rally DID increase visibility of sodipodi, for example.
[is 'fex' the username of someone inlcuded in the crosspost? It is quite confusing I dont know the word at all]
I parsed it as "for example".
*Continuing the case for map symbols... (the wikitravel mapmaking thing really got me started ;)
Dia has some Map Symbols, if i recally correctly Ian Redfern used his perl scripting to generate files for Dia from PDF (and postcript i think), and i think he had plans to update his script to also generate pure SVG.
I've been trying to collect tools that can be useful to mechanically convert things into SVG: http://inkscape.org/tools.php
Perhaps existing collections can be run through these tools, as a time-efficient way to bulk up the symbol repository. Probably a lot wouldn't convert across well, but even if you get just a portion, that'd be an easy way to start building the collection. Of course, licensing would need to be taken into account...
There are probably some WMF symbol lib's out there with licenses that can be used, or authors that are willing to allow them to be used under open source licenses if asked. The WMF->SVG tools I've used have not worked very well for me, but this may have been due to the way the symbols were made.
Point is, it's useful, interesting and fun... :)
I'd love to see a shared library of clipart, preferably in a cleaned homogenized SVG and installed to a standard location (freedesktop.org anyone?) with a few categories that could be shared across any application that was interested (I'm thinking Gnome-office).
That'd be very cool.
Note that they key enabling factor for this project to work well and scale is to have a smooth and easy clipart submission process. Minimizing human administration per submission is very important. CVS can work in a pinch, although many artists won't know it and may not want to bother learning it.
A web-based file-upload tool might be a good start, especially if it can keep track of the author, explicit licensing statement, etc. Keep it simple though - if it takes more than 3 min for a new contributor to learn, it's probably too complicated.
The ideal approach would be a WebDAV repository that people could mount as a local file system (much like NFS or Samba, but works over http). I don't think SF supports WebDAV, and even if it did, you're limited to 100mb on the website. Instead I would recommend looking at tigris.org, who host subversion (which is WebDAV-based), and provide services similar to SourceForge. This seems like the type of project they may be very interested in, and they certainly have WebDAV know-how.
Anyway, with WebDAV set up, you can use the repository using a file manager like File Explorer (on Windows), or mounted as a file system (on Linux). Some applications such as Illustrator, understand WebDAV directly, and I understand they can load-from and save-to the remote repository directly. One could imagine that having an active WebDAV repository would be ample motivation to get similar support built into Inkscape... ;-)
Bryce
On Sun, 2003-12-07 at 16:28, Bryce Harrington wrote:
Anyway, with WebDAV set up, you can use the repository using a file manager like File Explorer (on Windows), or mounted as a file system (on Linux). Some applications such as Illustrator, understand WebDAV directly, and I understand they can load-from and save-to the remote repository directly. One could imagine that having an active WebDAV repository would be ample motivation to get similar support built into Inkscape... ;-)
Wow, that subject line is getting large. My subject line is bigger than your subject line (sorry).
Anyway, the WebDAV support would be something that we'd get for free if we supported GNOME-VFS. I'd like to do that sometime, is there any issues with using GNOME-VFS on Windows or Mac OS X? It would be nicer if we could go to GNOME-VFS exclusively.
--Ted
Ted Gould wrote:
On Sun, 2003-12-07 at 16:28, Bryce Harrington wrote:
Anyway, with WebDAV set up, you can use the repository using a file manager like File Explorer (on Windows), or mounted as a file system (on Linux). Some applications such as Illustrator, understand WebDAV directly, and I understand they can load-from and save-to the remote repository directly. One could imagine that having an active WebDAV repository would be ample motivation to get similar support built into Inkscape... ;-)
Wow, that subject line is getting large. My subject line is bigger than your subject line (sorry).
Anyway, the WebDAV support would be something that we'd get for free if we supported GNOME-VFS. I'd like to do that sometime, is there any issues with using GNOME-VFS on Windows or Mac OS X? It would be nicer if we could go to GNOME-VFS exclusively.
--Ted
Sounds good, but there is a danger. Once you get deeply into the Gnome world, you start adding dependencies quickly. Quickly it will become compilable only on Gnome.
There -is-, however, the lovely Neon WebDAV library, which has long been ported to many architectures, including Win32, and is used every day. It is the backbone transport of Subversion, even. And Subversion's webdav FS code would be a good starter example. It is LGPL.
Bob
On Mon, 8 Dec 2003, Bob Jamison wrote:
Ted Gould wrote:
On Sun, 2003-12-07 at 16:28, Bryce Harrington wrote:
Anyway, with WebDAV set up, you can use the repository using a file manager like File Explorer (on Windows), or mounted as a file system (on Linux). Some applications such as Illustrator, understand WebDAV directly, and I understand they can load-from and save-to the remote repository directly. One could imagine that having an active WebDAV repository would be ample motivation to get similar support built into Inkscape... ;-)
Wow, that subject line is getting large. My subject line is bigger than your subject line (sorry).
Anyway, the WebDAV support would be something that we'd get for free if we supported GNOME-VFS. I'd like to do that sometime, is there any issues with using GNOME-VFS on Windows or Mac OS X? It would be nicer if we could go to GNOME-VFS exclusively.
--TedSounds good, but there is a danger. Once you get deeply into the Gnome world, you start adding dependencies quickly. Quickly it will become compilable only on Gnome.
Are you speaking of GNOME in general or of this library specifically? I have these same concerns with any GNOME libs, but in theory some of the lower level libs might be clean. I don't know on this one and couldn't quickly find a dependency list on the GNOME-VFS website. I also did not see any specific mention of WebDAV, although support of URI's kind of implies that sort of capability.
There -is-, however, the lovely Neon WebDAV library, which has long been ported to many architectures, including Win32, and is used every day. It is the backbone transport of Subversion, even. And Subversion's webdav FS code would be a good starter example. It is LGPL.
This looks very cool. It supports many of the basic WebDAV functions (PUT, GET, HEAD) as well as auth, metadata properties, SSL, etc. It says it's set up with autoconf macros for embedding into an existing code tree. Even has a test suite and perl bindings. :-)
Judging from the function list this appears to be a touch lower level than the GNOME-VFS stuff, so if we used it we'd need to build a file management layer of some form on top of it. There's an examples package, so I'd expect this to not be too difficult.
I've updated the feature list and roadmap to mention "something like GNOME-VFS or neon". This'll need to be investigated a bit further before we can plan out implementation. Nice to know we have some options.
Bryce
Bryce Harrington dubitò:
Sounds good, but there is a danger. Once you get deeply into the Gnome world, you start adding dependencies quickly. Quickly it will become compilable only on Gnome.
Are you speaking of GNOME in general or of this library specifically? I have these same concerns with any GNOME libs, but in theory some of the lower level libs might be clean. I don't know on this one and couldn't quickly find a dependency list on the GNOME-VFS website. I also did not see any specific mention of WebDAV, although support of URI's kind of implies that sort of capability.
According to dpkg, libgnomevfs2-0 and libgnomevfs2-common depend on libbonobo, libbz2, fam, libgcrypt, libpopt, libtasn, gconf, glib, gnutls, orbit2, libxml, zlib and gnome-mime-data.
At least abiword use it as a configurable dependency and it's successfully ported to windows.
On Mon, 8 Dec 2003, Emanuele Aina wrote:
Bryce Harrington dubitò:
Sounds good, but there is a danger. Once you get deeply into the Gnome world, you start adding dependencies quickly. Quickly it will become compilable only on Gnome.
Are you speaking of GNOME in general or of this library specifically? I have these same concerns with any GNOME libs, but in theory some of the lower level libs might be clean. I don't know on this one and couldn't quickly find a dependency list on the GNOME-VFS website. I also did not see any specific mention of WebDAV, although support of URI's kind of implies that sort of capability.
According to dpkg, libgnomevfs2-0 and libgnomevfs2-common depend on libbonobo, libbz2, fam, libgcrypt, libpopt, libtasn, gconf, glib, gnutls, orbit2, libxml, zlib and gnome-mime-data.
At least abiword use it as a configurable dependency and it's successfully ported to windows.
Thanks, I've added this info to the page:
http://www.inkscape.org/cgi-bin/wiki.pl?AdvancedFileAccess
Bryce
On Mon, 8 Dec 2003, Bob Jamison wrote:
Anyway, with WebDAV set up, you can use the repository using a file manager like File Explorer (on Windows), or mounted as a file system (on Linux). Some applications such as Illustrator, understand WebDAV directly, and I understand they can load-from and save-to the remote repository directly. One could imagine that having an active WebDAV repository would be ample motivation to get similar support built into Inkscape... ;-)
Wow, that subject line is getting large. My subject line is bigger than your subject line (sorry).
Anyway, the WebDAV support would be something that we'd get for free if we supported GNOME-VFS. I'd like to do that sometime, is there any issues with using GNOME-VFS on Windows or Mac OS X? It would be nicer if we could go to GNOME-VFS exclusively.
Sounds good, but there is a danger. Once you get deeply into the Gnome world, you start adding dependencies quickly. Quickly it will become compilable only on Gnome.
That is reason to have Gnome build as well as a plain GTK build.
Havoc Pennington has made it known that he would very much like to see a standardised VFS that both KDE and Gnome could share but I dont know how far that idea has progressed.
If you are considering replacing file.c you might go a bit further and use libgsf and let it do the hard work. http://freshmeat.net/projects/libgsf/
Using libgsf it would get you the svgz support for free and gnome-vfs would be entirely optional (you'd also get copy/paste "for free" as well as BonoboStream support "for free", and Win32 IStream support "for free"). [1]
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
[1] Thanks to Dom Lachowicz for the clarification and useful information about libgsf.
On Mon, 2003-12-08 at 17:47, Alan Horkan wrote:
That is reason to have Gnome build as well as a plain GTK build.
That's a direction I'd really rather not go.
I don't mind using libraries like Gnome-VFS, but I would specifically want to limit dependencies on them to plugins.
That makes it easier for binary packagers, among others -- they can package a single build of the main binary with no special dependencies, and supply individually packaged plugins/modules that would individually depend on any extra libraries.
If you are considering replacing file.c you might go a bit further and use libgsf and let it do the hard work. http://freshmeat.net/projects/libgsf/
Using libgsf it would get you the svgz support for free and gnome-vfs would be entirely optional (you'd also get copy/paste "for free" as well as BonoboStream support "for free", and Win32 IStream support "for free"). [1]
That sounds rather appealing...
-mental
On Mon, 8 Dec 2003, MenTaLguY wrote:
If you are considering replacing file.c you might go a bit further and use libgsf and let it do the hard work. http://freshmeat.net/projects/libgsf/
Using libgsf it would get you the svgz support for free and gnome-vfs would be entirely optional (you'd also get copy/paste "for free" as well as BonoboStream support "for free", and Win32 IStream support "for free"). [1]
That sounds rather appealing...
Here's a page for capturing pros/cons of the various options that have been discussed:
http://www.inkscape.org/cgi-bin/wiki.pl?AdvancedFileAccess
This is linked onto the NewFeatureProposals page.
Bryce
On Mon, 8 Dec 2003, Alan Horkan wrote:
If you are considering replacing file.c you might go a bit further and use libgsf and let it do the hard work. http://freshmeat.net/projects/libgsf/
Using libgsf it would get you the svgz support for free and gnome-vfs would be entirely optional (you'd also get copy/paste "for free" as well as BonoboStream support "for free", and Win32 IStream support "for free"). [1]
I took a brief look at this, however the documentation is extremely inadequate. In fact, I could not find any sort of features list so wasn't able to verify any of the above statements. This lib appears to be used by several GNOME projects, and the dependencies are very modest, but I don't think we should consider adopting this lib unless some detailed docs can be found. There is the start of a docbook document in the doc/ directory of the libgsf package, but it was too skeletal to be of use.
Bryce
On 8 Dec 2003, Ted Gould wrote:
On Sun, 2003-12-07 at 16:28, Bryce Harrington wrote:
Anyway, with WebDAV set up, you can use the repository using a file manager like File Explorer (on Windows), or mounted as a file system (on Linux). Some applications such as Illustrator, understand WebDAV directly, and I understand they can load-from and save-to the remote repository directly. One could imagine that having an active WebDAV repository would be ample motivation to get similar support built into Inkscape... ;-)
Wow, that subject line is getting large. My subject line is bigger than your subject line (sorry).
Anyway, the WebDAV support would be something that we'd get for free if we supported GNOME-VFS. I'd like to do that sometime, is there any issues with using GNOME-VFS on Windows or Mac OS X? It would be nicer if we could go to GNOME-VFS exclusively.
--Ted
That looks pretty interesting, especially given that our file.c is in desperate need of an overhaul already. It looks like GNOME-VFS promises a number of useful features beyond WebDAV such as monitoring files for changes, accessing files within tarball archives, etc.
Some questions we'd want to get answered before deciding to go this way: How bad is the dependency situation for this (we have been tending to avoid GNOME libs due to dep issues)? What version of the lib is most widespread? Has its API been stable for a long enough period of time? Does it work on Win32 and OSX?
I've added mention of it to our proposed features page in Wiki.
Bryce
Hi
Removing CC'es, I really dont like crossposting so I try not to do it. if this message is still relevant feel free to forward it.
You're right. I did a reply-all to a message posted to both lists, and immediately regretted it... :) Not that I don't think that this is any less relevant to inkscape than sodipodi, just that it seemed to follow more naturally from the flag rally and related threads than any discussion that I had previously seen on the inkscape list.
[is 'fex' the username of someone inlcuded in the crosspost? It is quite confusing I dont know the word at all]
(it's "for example", sorry about the personal idiosyncracy...)
Dia shapes/clipart/symbols could be made more generally reusable. Most of it is SVG based with some additional markup for things like connection points and I've said before that it could reasonably easily be converted to SVG with embedded Dia instead of dia with embedded SVG to simplify things for other applications. Dia has some Map Symbols...
I've not been able to find any map symbols clipart in the dia collection (default install). I personally think, for the specific subject of decorative mapmaking, that dia could be an ideal tool for thing such as roadmaps, just like autotrace performs nicely for region/country boundaries. I've created diagrams in dia, finishing them in SP. It worked quite nicely. The whole point is that neither SP or inkscape are as of yet sufficient in themselves for something like mapmaking, but there are free tools out there that can be productively combined to achieve the desired end, at least for this particular purpose.
Symbol libraries, vectors, fonts, - head spinning. SVG seems to be the best format to standardize upon, I'll assume you mentioned dingbats because of some special license it has rather than suggesting using Fonts to store libraries of vector symbols.
No no no. I'm not suggesting that a font should be used to store vector symbols... :) Just that having a good collection of simple b/w symbols (such as mapmaking symbols) easily translates into a font, if that is useful to anyone... If these have a GPL compatible license, so much the better.
I'd love to see a shared library of clipart, preferably in a cleaned homogenized SVG and installed to a standard location (freedesktop.org anyone?) with a few categories that could be shared across any application that was interested (I'm thinking Gnome-office).
Such a collection would be invaluable. Somebody would, however, need to fire it up and define some goals for it. The sodipodi flag rally seemed to me a natural example to follow, especially as the peer-review mechanism seemed to be working nicely in that case. Standardization of the svg can happen naturally, I think, through any such mechanism that is not too complex. A set of instructions on how to clean up your svg could be useful, but should not form a threshold for submissions I think. If someone finds out that the svg of some image doesn't work in some application, and has sufficient svg know-how, they will hopefully try to fix the problem and submit a correct version to the project...
For those that haven't been following the thread on the SP list, it seems that the idea is to branch off the clipart, and collaborate with projects like Klipart (KDE), that I'm unfamiliar with. The important thing for me (and the reason for my meddling) is to have a free collection of international service signs available. I will submit my own work to any project to that end, be it SP, a shared library of clipart or even dia... :)
Best regards
Áki
PS. The new inkscape interface looks great!
participants (8)
-
"Áki G. Karlsson" -
Alan Horkan -
Bob Jamison -
Bryce Harrington -
Emanuele Aina -
Jonathan Phillips -
MenTaLguY -
Ted Gould