Actually, at the moment SVG doesn't support CMYK. However it is proposed that it will at some point. What you cited there was the proposed draft requirements from over four years ago. I think they might be getting close to finally putting 1.2 out, but even in the last rounds of finalizing SVG 1.1 they dropped things, so one mustn't count one's chickens before they're hatched.
In fact, back in April of 2005 they pulled back their draft 1.2 spec and replaced it with a simple placeholder stating that things were in flux. So we're all now just sitting, waiting with baited breath.
Could Inkscape be used to generate art for a videogame?
Yes. Depends on what and how you're planning to do things. The GNOME games migrated to SVG artwork quite a while back.
Another approach is to create your artwork in SVG and then render to bitmap at different sizes. This mirrors a lot of the workflow used for creating icons.
Are there any libraries to render this stuff?
As far as libraries go, there are librsvg and KSVG for a start. For other gaming needs, one can do some interesting things with SVG and XHTML in a browser with a little JavaScript sprinkled in.
That's a bit vague. However, it was actually being followed up on before that strip even hit the web. And among other pertinent things, Little CMS integration into Inkscape started shortly after Libre Graphics Meeting not too many weeks ago. Illiad hasn't covered any of the features he'd actually like for his workflow, but he has been asked.
As soon as the next release of Inkscape is done (starting any day now), then more CMS support will go in and also hit the UI. (So anyone who might want to use this, be sure to drop a note or some such).
This has been done before, as a previous post links. NOT an original idea.
True. But there is one that one bit that makes this somewhat more geek-worthy. They actually got sponsorship from the Duck tape people themselves. Not bad for a little week's hack.
This is the type of screen resolution for my Digital Reader, the resolution that made me send it back the day I got it. There's nothing paper-like about reading dot-matrix like resolutions. The eye doesn't adapt but instead becomes increasingly fatigued.
This technology may have some application for computer-like applications. I was hoping for e-books. This screen resolution won't cut that....
It all depends on the specifics of the device. I'ved used a Handspring Prism with a resolution of only 160x160 for years for an ebook reader, and it's great. I've gone through quite a few, especially from Baen
It ends up with a column width around that of an article in a newspaper or magazine, and is quite readable. Even when only using a limited number of colors (default fonts are only 1-bit) ti works well. I think much of it is due to having a white background. So the reflective properties and contrast of the display itself could make a huge difference.
Or, to put it another way, Opera doesn't support SVG - it supports a subset of SVG.
Are you only speaking of incomplete SVG, or actually of SVG Tiny (the first profile of SVG Mobile)? If you're meaning the latter, then it really isn't a subset of SVG, just a different flavor of it. In fact, the SVG working group is moving away from SVG Tiny being a 'subset' of SVG Full. Instead they're are moving to having SVG Tiny be the base language and SVG Full to be "extensions to [it], forming a superset". So, as long as an implementation supports SVG Tiny, it seems completely fair to say it "supports SVG." (And in that case it's also very different than MSIE and CSS)
Won't that take loads of bits for anything more than simplest?
A few years ago I was investigating SVG, and did sevaral tests of sample content. For all the icons I tested, the SVG versions turned out to be the same size or smaller than the existing PNG versions. And that also was before doing anything like compressing the data. Given the regularity of the text in XML, just turing on gzip compression on the server could boost things significantly.
Remember, YMMV and all that, but in many cases the anticipated 'bloat' is just speculative, and not actual or significant.
For a fairly comprehensive list of editors and converters check out the W3C SVG Implementations
Actually, that list is fairly out of date. The last content dates are from 2002, and there's no mention yet of Inkscape, that came on the scene over a year and a half ago.
vector graphics solve the problem of scaling artefacts; they do not, by themselves, adjust the level of detail as you zoom.
Actually, they're starting to. Just look at section 12.3 of the SVG 1.2 spec: "Alternate content based on display resolutions". Not only is it in the spec, but it's shown up on the roadmaps of things such as librsvg. Just two or three levels can replace a slew of bitmap icons.
Don't even try telling me that you as a programmer have the slightest idea of how artists think. There is an old truism, it is easier to make an artist into a computer tech than it is to make a computer tech into a talented artist. Artistic thinking cannot be developed by taking a few art courses. What would you say if someone came up to you and said, "I have been an artist for 20 years but I took a couple of programming courses, so now I know how programmers think"?
No, but I as an artist have much of an idea how artists work. No, artistic thinking can not be developed by a few art courses, but if one does have the base talents, college courses can help. In addition to other coursework, I took an entire certificate program in computer animation. My intro professor in the art department (classes were split between the fine arts department and the computer arts department) held me up as having some of the best talent in the class, especially when it came to charcoals. (Oh, and this was the same college that had many profesionals come through, including Rob Liefeld just a bit before me.)
I also started my carreer doing as much artwork as programming, including Interplay among my artwork clients. And one of the reasons I was a founding member of a multimedia company was that I could do artwork as well as programming. And as the company grew to include a half dozen full time artists, one of my main jobs was to work with them daily, ensuring their workflow went smoothly. Oh, and many artists do not demand that nothing interrupt their 'artistic flow'. While some do need that 'focus' and isolation, many others enjoy and often thrive on a collaborative environment. I've also worked with other artistic programmers, including many that took turns earning a living at artistic endeavors in addition to programming. Perhaps less common, but nowhere near impossible.
Your argument seems to be that artistic ability and technical or scientific bent are mutually exclusive. To see that this is false, all one has to do is look a bit and see things like Van Gough's letters on color theory or DaVinci's body of work. Yes, the skills and talents needed for one are fairly different, but there are many people who have a mix, and many at a decent degree of competence.
The real problem with OSS apps for graphic artists is that programmers do not understand how artists work. This has always been the dichotomy between programs with good GUIs and programs that don't.
Actually, you're making a fairly wide-ranging and erroroneous generalization there. For example, one of the key people and admins for Inkscape is a professional artist, not programmer. Several other artists are also involved (including those with MFA's, etc). I myself am a programmer, but cut my teeth in charge of engineering for a small multimedia company, and even have formal art training. I can say with certainty that how artists work is well known and considered by most involved in the project (and man, some of those artists can be quite vocal).
The Gimp also has been fairly well used by art professionals. The Film Gimp (aka CinePaint) being one of the more intereting branches. That one is used by serious professional artists, and is worked on by many engineers who are paid to support those artists and give them what they need...
However, have you seen how they're taking their branch in regards to UI? They're switching it to FLTK. Personally I think it's one of the oooooogliest UI toolkits around (and very un-photoshop-ish). However, it is highly functional, and helping the artists get their work done is what the programmers at Rythm & Hues, Sony Imageworks, ILM, Dreamworks and such are paid to do. Trust me, they know art workflow.
You could argue that all the other OO notation schemes, OOT, Booch, etc.. could be used as languages as well, I don't think the argument is particular to UML. Unfortunately, I don't think most folks would use UML for anything more than documentation and 'sketching'. You could think of UML as a language or dialect to communicate with. Is that what Mellor is suggesting?
I think the original author of this thread was referring to the actual application of UML as a programming language, and not as a dialect for materializing thoughts in a software process.
Go ahead and check into some of the references. As I mentioned, those experts classify 'programming language' as one of the three major modes of UML use. Of course, Fowler seems to consider executable UML as a 'holy grail' ideal that probably will never be practical, but there are ways to go about it. Mellor's recent book 'Executable UML' explores some of this. In general, some of the feel I get (remember, I haven't done UML as Programming Language myself) is that in those cases UML is the language worked in, and it can later be compiled to lower-level languages just as to execute C++ was originally compiled to C and then assembly while the programmer stayed working in C++.
To get up to speed on things, I'd suggest UML Distilled to get a good overview of things. Although he focuses on the ways most folks use UML, he does explain the "UML as Programming language" use as well.
there's an HTML way to do it. Tada, the <acronym> tag.
Well... if you want to get into pdeantic details... the <abbr> tag is probably to be favored. The W3C spec spells out the difference down in section 9.2.1. Of course, finding out which versions of which browsers support which tags is another problem altogether.
BTW, I find the WDG's guides to be more technically accurate and helpful. Much of that could be due to their documentation being machine generated from the official DTD's and such.
You're right that the initial idea is always different after seeing prototypes. But for this exact reason you shouldn't document your code. Code should be disposable, so don't waste time writing other than what the computer needs.
And this is where I'll have to strongly disagree with you. Even "Extreme Programming Installed" (a book I personally belive wonders off a bit from Beck's best XP) says to use UML.
Additionally, some of what I've seen in the best projects is the use of good Javadoc, DOC++, Doxygen or some such comments. The best time to write those is while the design is fresh in people's minds, such as in writing up initial tests or first writing each class. Additionally, it's much easier to keep up to date, and helps greatly as people need to go in and refactor code. Oh, and Eclipse has good Javadoc support, and having Javadoc comments helps it work even better.
Of course, I've gone Extreme myself on different projects by writing Docs in XML. Just poke a single XML with different XSLT stylesheets and get end-user API documentation, internal implementor guide documentation, and full test case source code all from that single sparse XML source. (But especially with all the workflow benefits one gets in Eclipse from having proper Javadoc comments around, those are well more that "disposable").
Until I got to the end of the blurb I thought this was about user mode linux...and now, of course, I have no idea what it is.
Well, I'm definitely not trying to troll here or anything, but in this instance I'd be willing to give the poster the benefit of the doubt on the TLA use here. Given the target audience (Slashdot tech-heads), and the prevalence of UML in the tech field (among other things there are literally hundreds of available books on the modeling language, but no easily found ones on User Mode Linux), it's not that unreasonable to assume that most would know the Unified Modeling Language, and that those aware of User Mode Linux would fall in the group that probably 'should' know about the UML.
At the company I worked for until very recently we mostly used 'UML as a sketch' on the whiteboard as a way of turning our ideas into something concrete we could implement...
I'd definitely have to strongly second this. I've seen this boil out from working at a few different companies. Those who used UML most strongly also seemed to gain less from it (and one architect seemed amazed and could not even fully grasped the concept that I'd been doing OO design for years without any UML at all... even when many projects I worked on even predated UML).
And it's not only my professional opionion and experience that lend support to this. Martin Fowler himself professes this position, and explains it fairly well throught UML Distilled
"In fact, the UML is a few different things to different people. This comes both from its own history and from the diffrent views that people have about what makes an effective software engineering process."
UML can be a programming language in and of itself, where all the code for some application is UML, or it can also be merely used for varrying degrees of documentation.
Both he and Steve Mellor independently came up with three modes in which most people use the UML:
Sketch
Blueprint
Programming Language
Sounds like you're familiar with the first two, but the latter does exist as one of the primary three modes.
UML, like most other other software engineering fads exist mostly because groups like OMG want to push new consulting fees to large commercial companies, publish more series of books and create forums for them to lecture to (and charge fees).
On this, I'd also would have to say you're probably a bit off. The UML exists mainly because there was a Tower of Babel of somewhat similar approaches to the same problems being invented and used all over the place. At least the UML did manage to unify that mess. Of course, the consultants would be makining money regardless, however my personal feeling is probably that the multiple pre-UML solutions would have offered them even more fertile ground to exploit.
Ever since the early days, one thing that has annoyed me about Pixar is their strange love of over-saturated light. From their early TV commercials on they've had it. The one part of Toy Story I didn't like was that lighting (most often in sunset scenes, etc.), especially since I had just figured out that general problem in some 3D work I had been doing myself at that time and was very attuned to the look.
However... as the review pointed out, in this picture the lighting is just beautiful. The choices are great, and the look enhances without intruding. Basically it's moved up to being a strong supporting character
Slashdot Mirror
Actually, at the moment SVG doesn't support CMYK. However it is proposed that it will at some point. What you cited there was the proposed draft requirements from over four years ago. I think they might be getting close to finally putting 1.2 out, but even in the last rounds of finalizing SVG 1.1 they dropped things, so one mustn't count one's chickens before they're hatched.
In fact, back in April of 2005 they pulled back their draft 1.2 spec and replaced it with a simple placeholder stating that things were in flux. So we're all now just sitting, waiting with baited breath.
Yes. Depends on what and how you're planning to do things. The GNOME games migrated to SVG artwork quite a while back.
Another approach is to create your artwork in SVG and then render to bitmap at different sizes. This mirrors a lot of the workflow used for creating icons.
As far as libraries go, there are librsvg and KSVG for a start. For other gaming needs, one can do some interesting things with SVG and XHTML in a browser with a little JavaScript sprinkled in.
Why, here ya go: Reporting Bugs.
That's a bit vague. However, it was actually being followed up on before that strip even hit the web. And among other pertinent things, Little CMS integration into Inkscape started shortly after Libre Graphics Meeting not too many weeks ago. Illiad hasn't covered any of the features he'd actually like for his workflow, but he has been asked.
As soon as the next release of Inkscape is done (starting any day now), then more CMS support will go in and also hit the UI. (So anyone who might want to use this, be sure to drop a note or some such).
True. But there is one that one bit that makes this somewhat more geek-worthy. They actually got sponsorship from the Duck tape people themselves. Not bad for a little week's hack.
It all depends on the specifics of the device. I'ved used a Handspring Prism with a resolution of only 160x160 for years for an ebook reader, and it's great. I've gone through quite a few, especially from Baen
It ends up with a column width around that of an article in a newspaper or magazine, and is quite readable. Even when only using a limited number of colors (default fonts are only 1-bit) ti works well. I think much of it is due to having a white background. So the reflective properties and contrast of the display itself could make a huge difference.
That was supposed to be "SVG", not "CVS". I guess that's what I get for coding and posting at the same time.
Are you only speaking of incomplete SVG, or actually of SVG Tiny (the first profile of SVG Mobile)? If you're meaning the latter, then it really isn't a subset of SVG, just a different flavor of it. In fact, the SVG working group is moving away from SVG Tiny being a 'subset' of SVG Full. Instead they're are moving to having SVG Tiny be the base language and SVG Full to be "extensions to [it], forming a superset". So, as long as an implementation supports SVG Tiny, it seems completely fair to say it "supports SVG." (And in that case it's also very different than MSIE and CSS)
A few years ago I was investigating SVG, and did sevaral tests of sample content. For all the icons I tested, the SVG versions turned out to be the same size or smaller than the existing PNG versions. And that also was before doing anything like compressing the data. Given the regularity of the text in XML, just turing on gzip compression on the server could boost things significantly.
Remember, YMMV and all that, but in many cases the anticipated 'bloat' is just speculative, and not actual or significant.
Ahh... but that's where things like the <switch> element, CSS, and the new <multiImage> support coming in 1.2
all come in handy. That gives you 'hinting' and/or 'level-of-detail' (LOD).Oh, and I forgot. There's no mention of Opera supporting SVG either.
Actually, that list is fairly out of date. The last content dates are from 2002, and there's no mention yet of Inkscape, that came on the scene over a year and a half ago.
Between CSS and the new support in SVG 1.2, they've got much of that.
Actually, they're starting to. Just look at section 12.3 of the SVG 1.2 spec: "Alternate content based on display resolutions". Not only is it in the spec, but it's shown up on the roadmaps of things such as librsvg. Just two or three levels can replace a slew of bitmap icons.
No, but I as an artist have much of an idea how artists work. No, artistic thinking can not be developed by a few art courses, but if one does have the base talents, college courses can help. In addition to other coursework, I took an entire certificate program in computer animation. My intro professor in the art department (classes were split between the fine arts department and the computer arts department) held me up as having some of the best talent in the class, especially when it came to charcoals. (Oh, and this was the same college that had many profesionals come through, including Rob Liefeld just a bit before me.)
I also started my carreer doing as much artwork as programming, including Interplay among my artwork clients. And one of the reasons I was a founding member of a multimedia company was that I could do artwork as well as programming. And as the company grew to include a half dozen full time artists, one of my main jobs was to work with them daily, ensuring their workflow went smoothly. Oh, and many artists do not demand that nothing interrupt their 'artistic flow'. While some do need that 'focus' and isolation, many others enjoy and often thrive on a collaborative environment. I've also worked with other artistic programmers, including many that took turns earning a living at artistic endeavors in addition to programming. Perhaps less common, but nowhere near impossible.
Your argument seems to be that artistic ability and technical or scientific bent are mutually exclusive. To see that this is false, all one has to do is look a bit and see things like Van Gough's letters on color theory or DaVinci's body of work. Yes, the skills and talents needed for one are fairly different, but there are many people who have a mix, and many at a decent degree of competence.
Those are all very good books. You'll want them. And especially take note of Peopleware, it's often overlooked.
But there are two good ones missing:
by Steve McConnell
by Ken Schwaber, Mike Beedle
I'd say you'd definitely want to read Rapid Devlopment before Code Complete. And the Scrum book will save you.
Actually, you're making a fairly wide-ranging and erroroneous generalization there. For example, one of the key people and admins for Inkscape is a professional artist, not programmer. Several other artists are also involved (including those with MFA's, etc). I myself am a programmer, but cut my teeth in charge of engineering for a small multimedia company, and even have formal art training. I can say with certainty that how artists work is well known and considered by most involved in the project (and man, some of those artists can be quite vocal).
The Gimp also has been fairly well used by art professionals. The Film Gimp (aka CinePaint) being one of the more intereting branches. That one is used by serious professional artists, and is worked on by many engineers who are paid to support those artists and give them what they need...
However, have you seen how they're taking their branch in regards to UI? They're switching it to FLTK. Personally I think it's one of the oooooogliest UI toolkits around (and very un-photoshop-ish). However, it is highly functional, and helping the artists get their work done is what the programmers at Rythm & Hues, Sony Imageworks, ILM, Dreamworks and such are paid to do. Trust me, they know art workflow.
Go ahead and check into some of the references. As I mentioned, those experts classify 'programming language' as one of the three major modes of UML use. Of course, Fowler seems to consider executable UML as a 'holy grail' ideal that probably will never be practical, but there are ways to go about it. Mellor's recent book 'Executable UML' explores some of this. In general, some of the feel I get (remember, I haven't done UML as Programming Language myself) is that in those cases UML is the language worked in, and it can later be compiled to lower-level languages just as to execute C++ was originally compiled to C and then assembly while the programmer stayed working in C++.
To get up to speed on things, I'd suggest UML Distilled to get a good overview of things. Although he focuses on the ways most folks use UML, he does explain the "UML as Programming language" use as well.
Well... if you want to get into pdeantic details... the <abbr> tag is probably to be favored. The W3C spec spells out the difference down in section 9.2.1. Of course, finding out which versions of which browsers support which tags is another problem altogether.
BTW, I find the WDG's guides to be more technically accurate and helpful. Much of that could be due to their documentation being machine generated from the official DTD's and such.
I have. And way back into last century even. :-)
And this is where I'll have to strongly disagree with you. Even "Extreme Programming Installed" (a book I personally belive wonders off a bit from Beck's best XP) says to use UML.
Additionally, some of what I've seen in the best projects is the use of good Javadoc, DOC++, Doxygen or some such comments. The best time to write those is while the design is fresh in people's minds, such as in writing up initial tests or first writing each class. Additionally, it's much easier to keep up to date, and helps greatly as people need to go in and refactor code. Oh, and Eclipse has good Javadoc support, and having Javadoc comments helps it work even better.
Of course, I've gone Extreme myself on different projects by writing Docs in XML. Just poke a single XML with different XSLT stylesheets and get end-user API documentation, internal implementor guide documentation, and full test case source code all from that single sparse XML source. (But especially with all the workflow benefits one gets in Eclipse from having proper Javadoc comments around, those are well more that "disposable").
Well, I'm definitely not trying to troll here or anything, but in this instance I'd be willing to give the poster the benefit of the doubt on the TLA use here. Given the target audience (Slashdot tech-heads), and the prevalence of UML in the tech field (among other things there are literally hundreds of available books on the modeling language, but no easily found ones on User Mode Linux), it's not that unreasonable to assume that most would know the Unified Modeling Language, and that those aware of User Mode Linux would fall in the group that probably 'should' know about the UML.
Of course, writing it out long-hand is always handy, and a few links sprinkled around could help.
You're not alone here. Sounds like you're close to 'UML as Sketch' as touched on in comments here.
I'd definitely have to strongly second this. I've seen this boil out from working at a few different companies. Those who used UML most strongly also seemed to gain less from it (and one architect seemed amazed and could not even fully grasped the concept that I'd been doing OO design for years without any UML at all... even when many projects I worked on even predated UML).
And it's not only my professional opionion and experience that lend support to this. Martin Fowler himself professes this position, and explains it fairly well throught UML Distilled
.Actually, you're wrong there. It's a floorwax AND a dessert topping.
As Martin Fowler states in UML Distilled:
UML can be a programming language in and of itself, where all the code for some application is UML, or it can also be merely used for varrying degrees of documentation.
Both he and Steve Mellor independently came up with three modes in which most people use the UML:
Sounds like you're familiar with the first two, but the latter does exist as one of the primary three modes.
On this, I'd also would have to say you're probably a bit off. The UML exists mainly because there was a Tower of Babel of somewhat similar approaches to the same problems being invented and used all over the place. At least the UML did manage to unify that mess. Of course, the consultants would be makining money regardless, however my personal feeling is probably that the multiple pre-UML solutions would have offered them even more fertile ground to exploit.
Ever since the early days, one thing that has annoyed me about Pixar is their strange love of over-saturated light. From their early TV commercials on they've had it. The one part of Toy Story I didn't like was that lighting (most often in sunset scenes, etc.), especially since I had just figured out that general problem in some 3D work I had been doing myself at that time and was very attuned to the look.
However... as the review pointed out, in this picture the lighting is just beautiful. The choices are great, and the look enhances without intruding. Basically it's moved up to being a strong supporting character