--The pain of knowing and not just assuming--
In the never ending debate about how features in different applications and file formats work, we're now at a point of needing to journal about this apparently. I definitely feel like this
. For the record, this is me addressing this journal entry
and some of the subsequent discussion that has taken place in the comments. I hope to not offend anyone with my following comments, but understand that I undoubtedly will.
Sometimes being on the software development side of things and knowing EXACTLY how things work under the hood, and being told by users that this is "really" how it works (based on their superficial perceptions/observations), makes one crazy. No matter how many times and how many ways you try and explain it, it's still the way they think it is as far as they are concerned... not the way it ACTUALLY is. It's like arguing about palettes with the color blind. What they see is what they see regardless of what's really there... however, they have a legitimate reason to not see/get it.
One of the primary reasons to use vector programs/formats is the ability to create and edit creative works in a non-destructive fashion while utilizing a format that is resolution independent (working with math, not blocks... even though sometimes things are described in pixels, it's just a unit type). You need it in any size? You have it in any size. An issue that many vector formats have? They're pretty old (plenty still get updated though). Welcome SVG.
**Warning, what follows is common and open speculation from more than just myself**
SVG (Scalable Vector Graphics) came about as an open standard to be an alternative to Flash, and to get native vector graphics in the web browser. Adobe was a very active contributor to this initiative for years. That is, until they acquired Macromedia, and with it... Flash. After this point, Adobe's priorities changed and they focused on their acquisition rather than an open standard that was browser/viewer native and that more people and companies could benefit from.
Some of the greatness that makes SVG better than PDF is in some ways thanks to Adobe. Then again, it's also thanks to a not too shabby list of other corporate contributors (Apple, Mozilla, RIM, Cisco, Samsung, Opera, Canon, and many others including most recently Microsoft and Zynga) as well as Invited Experts.
Adobe got what they wanted, web dominance. With their acquisition however, their goal of best format around mattered much less. They also had next to no reason to continue adding support for more SVG features in Illustrator, and instead focused on getting more Flash compatible (it makes both monetary and corporate sense, but is still sad either way). Unfortunately, with the goal of the best format that can be collectively created now being unimportant, what Adobe did was go for the lowest common denominator. Stick with what they have, PDF & Flash, and make their authoring tools more Flash friendly rather than SVG friendly.
To sum up... Adobe helped make a format awesome and gave up implementing the awesome parts in their software because they got Flash.
--A flawed experiment--
Copying and pasting between applications is a terrible testing method if you want to approach things in a scientific way. This testing method breaks under any number of conditions. The most basic way? If App A produces data that App B doesn't know what to do with, App B generally disregards the data it doesn't understand. The simple explanation? Use what you can, discard what you don't know what to do with. In other words, compatibility of features between applications is a HUGE stumbling block in this type of testing. A simple example would be taking heavily formatted text from a word processor, copying it, and then pasting it into a text editor (such as Notepad). What happens? The formatting is stripped because the text editor doesn't know what to do with that extra formatting data and therefore has no use for it. This is what happened in the testing done in that journal post. Illustrator doesn't know how to interpret the SVG blur filter and it most likely outright stripped out the extra descriptive pieces... it also doesn't know how to interpret the gradient fills either when pasting.
Another simple way this testing method is flawed? Clipboard applications and their preferences. On both the Linux & Windows sides, clipboard managers are a common offender and tend to break this test rather easily given the contents of the clipboard (because the app mangles the data). They're not the only ones that suffer, a necessary component to run Inkscape on OSX is X11. If one is to use Inkscape on OSX, you will run into a nasty bug for copying and pasting all vector content within Inkscape as it gets copied as bitmap/raster data. Our FAQ addresses this issue here
. (Note to those wondering, it's not an Inkscape issue.)
As brought up in the comments, try to paste a gradient mesh copied from Illustrator into Inkscape. It doesn't work, besides, Inkscape doesn't support gradient meshes anyway. Guess what though, if Inkscape added support for gradient meshes as defined by the SVG spec as opposed to the PDF spec, it still would not work. If the syntax and data (clipboard content) is simply just different, it gets lost in translation. Oh but wait, since it can't copy and paste and be editable... what does that mean? According to the journal's logic, Illustrator's gradient meshes must not be vector! "To put it simply: if the blur you applied on your object in Inkscape was 100% vector, you could copy said object over to AI without losing the blur as it maintains all vector data when it's copied across." & a second quote "It means that the programs are perfectly capable of copying and maintaining vector data between the programs. Simple!"
--I can do testing too--
I decided I needed to do my own tests to further point out how flawed the copy and paste method is. So I decided to dust off my win7 partition and proceeded to download the latest and greatest trials of Illustrator, Xara, and Corel Draw.
Here were my observations:
Copying a path from Illustrator:
Pastes as bitmap in Inkscape, Xara (if selecting the EMF option on paste it doesn't paste anything), & Draw. Why is their path data not friendly with non-Adobe apps? Using the above quoted logic, apparently Illustrator doesn't create vector data.
Copying a path from Inkscape:
Pastes as a path in Illustrator, Draw, and Xara.
Copying a path from Draw:
Pastes as a path in Inkscape, Illustrator, and Xara.
Copying a path from Xara:
Pastes as a path in Inkscape and Illustrator, and as a bitmap in Draw.
Copying a gradient mesh from Illustrator:
Pastes as a bitmap in Xara and Draw, does not paste anything into Inkscape at all (BUG! I will ask Jon Cruz about this).
Opening the Illustrator file in Draw allows editing the mesh, however it renders VERY differently than Illustrator. Unfortunately, Illustrator can't open Draw X5's files, so I can't test the reverse. Opening the Illustrator file in Xara unsurprisingly ends up with a big black box where my test mesh was, additionally only the points on the exterior of the shape are recognized. Again, reference the above mentioned logic. Not all of Illustrator's path data is recognized by Xara... my take? Big whoop. It's a compatibility/features issue. Inkscape seemed to hang when trying to open the AI file, I will need to debug when I reboot.
Oh, and gradients don't copy and paste across *any* of the applications I tested either. The only way that it shows up as something other than path data with no fill is when the bitmap pastes happen. All this means is that they all just describe gradients differently... that is unless ChewedKandi
wants to say gradients are no longer okay to use in the vector category because they don't paste over (one of her criteria for something being vector). Good thing I did this test though, apparently Inkscape thinks the clipboard is empty when AI has copied something with a gradient on it too (finding 3 bugs in this exercise is a huge win, expect them to be fixed in the next release).
Now for the other test. Opening an SVG produced with Inkscape that has a blurred rectangle in the other apps. Well, Xara doesn't have an SVG import filter, no dice. Corel renders the rectangle without blurring it. Adobe does the same as Corel, however, they admit that they aren't processing it correctly but don't say why. Adobe's dialog simply says "An error occurred while processing the appearance of an object." At least it tells you that though.
Now, opening the file in Firefox, Opera, Chrome, and Batik all shows exactly what we see in Inkscape, also just like Inkscape you can zoom to your heart's content and you will never see pixels (possibly a little banding though). IE & Safari render it how Illustrator and Draw do because they have not implemented that part of the specification yet either.
--People not understanding about Free & Open Source--
There seems to be this false notion of value based on strange criteria. Version number is an entertaining one (I won't even go there). Plus, people hear words like "Industry Standard" and assume that it's automatically the best/most capable tool out there. Likewise, they see a higher price tag and assume that somehow that price is acutally merited or because it costs more than X, Y, or Z, it must be BETTER than them. There's also this bizarre notion that commercial software gets the best or most useful features first.
When was transparency in gradients first supported?
Inkscape - 2003
Illustrator - 2008
When was editing gradients on the canvas first supported?
Inkscape - 2005
Illustrator - 2008
When was support for elliptical gradients first supported?
Inkscape - 2003
Illustrator - 2008
A "Content Aware Fill" feature in the raster counterparts?
The GIMP - 2004 (via the free and open source Resynthesizer plugin)
Photoshop - 2010
Now to be fair, does Inkscape support everything Illustrator does? Certainly not. The same way you see those examples above, it's a two-way street... both apps are filling in features that the other have had first. Is it because anyone is copying the other? Not usually. It's because the features are useful to users and at times makes them much more productive. There is a LOT lacking in Inkscape, specifically for a fully color-managed worflow that makes it through to creating print-ready PDFs. We don't have support for gradient meshes either (mainly due to a lack of definition in the SVG standard for the syntax and rendering, that's not to say that Tavmjong hasn't started a proposal
). I could go on and list a lot that Inkscape lacks, however, I could also do the same with most software too. The reality is that no one has a monopoly on good ideas.
Describing in pixel dimensions somehow conflicts with something being vector... it's a unit type, accept it for what it is. Pixels in a bitmap image are another story however. Create a blur in AI and zoom in, you will start to see pixels at some point... do it with Inkscape and guess what you won't see? PIXELS!
To quote the journal "Now when we talk about blurs, on a technical level you are asking an object to be morphed into it's defined surrounding area by a set amount. This amount is defined in pixels. Which to me is the tell tale sign that something is a raster effect."
First off... that object's size, coordinates, points/nodes and their grips/handles are ALL described in the containing format as relative in whatever ARBITRARY UNIT you should choose (generally your doc can be set to Inch, CM, *GASP* px, pt, etc). The statement that "this amount is defined in pixels" is an assumption... in Inkscape the units for blur are actually relative.
Want to test this yourself? Create a 50x50 rectangle in Inkscape, open the Fill & Stroke dialog, set the blur to 10. Now, switch to the selector tool, hold ctrl+shift and grab a corner handle and scale it really large. What you will see is the blurred area is MUCH larger than 10 pixels, but somehow the blur amount in the Fill & Stroke dialog remains the same.
--Live Effects Confusion--
Given what she said, she doesn't understand what Live Effects actually are and how they really work behind the scenes. Not a fault of hers, but when you don't know about what goes on behind the scenes and you're not familiar with document formats and how they store various elements (and how they are interacted with), it's just a lack of exposure.
Live effects (both vector effects and raster effects) are used to maintain the original data and apply a destructive effect so that you can go back and modify the original data or modify said destructive effect in the future (it reapplies the effect to your original path/raster data again). In other words, it is stacked and stored as "Original Data"+"My Modifier"+"Destroyed Data" (Results of the previous two). A portion of the time it's only ever showing you the third item. You can always change either the original data or the modifier again, it will re-perform the destructive operation, and it will overwrite the previous "destroyed data".
Inkscape does have Live Path Effects, but no Live Raster Effects currently. Illustrator has Live Raster Effects because it creates and embeds fixed sized bitmap data (they have dpi preferences for it even)... meaning they're performing a destructive operation, but since they store all 3 layers of data, they get to claim it's no longer destructive. Inkscape's blur does not use destructive operations.
Want a good test? Create a new document in Illustrator saying it's for web (so we get an awesome 72dpi), create a 16x16px rectangle, apply the gaussian blur filter. Zoom in a bunch. You will see pixels pretty quickly. Now, fire up inkscape, create a 16x16px rectangle, Open the Fill & Stroke dialog and use the blur slider to add blur to it. Zoom in a bunch. Guess what you're not seeing?
--At the core of it--
SVG is a more modern and robust format in many regards than PDF... the reverse (about PDF having very important things that SVG lacks) is also true. Filter effects are something which SVG just does better (PDF doesn't even handle them), and it does them better because the primary goal is to be shown on screen. The key is it's on-screen for devices of all shapes and sizes so it can't be fixed resolution bitmap junk.
Illustrator creates a piece of binary bitmap data and embeds it in the file to achieve a blur. This element is of a fixed resolution. Inkscape describes the blurring effect in the same way that it describes path data, patterns, markers, masks, gradient information, etc. Unlike Illustrator, it is resolution independent, does not use an embedded bitmap, and always is rendered in real-time.
In Inkscape, a 10 by 10 px blurred square with a linear gradient fill at the 0x by 0y coordinates of the document is described as:
<rect id="rect3861" style="enable-background:accumulate;color:#000000;" fill-rule="nonzero" height="10" filter="url(#filter802)" width="10" y="1041" x="1.2" fill="url(#linearGradient3947)"/>
The filter or blur effect it references? (again, no embedded bitmap here)
<filter id="filter802" height="1.24" width="1.24" y="-0.12" x="-0.12">
<feGaussianBlur id="feGaussianBlur804" stdDeviation="0.5"/>
What does a gradient look like? (if our blur is a "Live Effect", are gradients?)
<linearGradient id="linearGradient3947" y2="1051" gradientUnits="userSpaceOnUse" x2="2" gradientTransform="matrix(5,0,0,5,1.2,-4210.64)" y1="1051" x1="-0.06313">
<stop id="stop3943" stop-color="#000" offset="0"/>
<stop id="stop3945" stop-color="#F00" offset="1"/>
All calculated and rendered right then, resolution independent with no need to modify or further instructions. You zoom in, it recalculates and re-renders everything.
What does Illustrator do? It contains a rectangle in PDF's syntax describing it, containing descriptive information (somewhat similar in theory to the filter information above), but then does the nasty task of creating destructive data for what you see and what it embeds... something akin to the following is stored in the file. Note: This example is REALLY small, this actually just a bitmap copy of the 10x10 pixel square example above. If it were 1000x1000px or of a high dpi expect significantly more data to be embedded, whereas the SVG would maybe be different by a few bytes due to the rectangle information itself being different... not the blurring. Note about the dimensions it's referencing, the 10x10 pixel above increases in size when blurred.
<image id="image4005" xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAMCAYAAABWdVznAAAABHNCSVQICAgIfAhkiAAAAL5JREFU KJGd0kFOwzAUBNDnxKWAUJUVStew6Zqz9RQcsNdAVQWiiW0WcUSJKAtGGn1bnpn/bTmg6dg8ER8J PXpsa+3xTNky4hg7NmteR3aJtiBUtrjBmfTO4Z59vGWV2WVeEAuKb+RpPwacWMUT7qawWEk1LdhC 84fgB2c0c9ulyaLmS4NfhMt1uTRcS12O8687zK+SCuOyy4wwnaWAGBkShypsr6SnwuGBIb5x7Nhn YiIMOOMTH3XmTCn1a3wBxAFgU3zxz+QAAAAASUVORK5CYII= " height="12" width="12" y="1040" x="14"/>
--It really boils down to--
My issue is that I don't want Inkscape users punished because there are some things that it handles in a more modern/robust way than the "Industry Standard" tools. Adobe CONTRIBUTED to the specification that Inkscape uses as our file format... they just chose not to adopt certain things in their own software yet (should they ever chose to). In the same way Illustrator doesn't know what to do with SVG Filter Effects, neither does Internet Explorer 9. Why? Microsoft prioritized other parts of the specification in their current implementation, but you can be sure IE 10 will have support.
Inkscape's blurs are on a technical level in no way any more raster than Gradient Meshes, Masks, Opacity/Transparency, or Compositing (composite modes such as Normal, Lighten, Darken, Multiply) are considered in Illustrator. There is a description of the operations to perform, and it does it on the fly... no embedded fixed-resolution bitmap crap, that's an Illustrator thing.
If you can understand it, there is no trickery... point here, line to here, located at this place on the canvas (for base path data). In the same way, I'm telling you to fill the path in this way and then to filter it in that way... they're instructions to reproduce something without any embedded bitmap junk. It's the exact same way that everything else is treated.
--Rebutting a common conclusion--
Realistically, I can give two VERY good reasons why Illustrator may (note: speculation, but solid reasoning) still handle things like blurs in the way that they do. 1) Is to ensure that the effect is exactly what the author intended and to ensure visual integrity that can not be misinterpreted by another renderer (which is exactly what happens when Draw tries to render Illustrator created gradient meshes). 2) Is to keep performance as snappy as possible. After all, re-rendering a gaussian blur on-the-fly because the canvas has been scrolled or zoomed is expensive in CPU time. Having fixed resolution bitmaps embedded in the file ensures that the only rendering to be done is the less expensive stuff, and the expensive stuff only gets rendered when it's modified.
Free and open source can't compare how? Firefox is free and open source. Chrome (Chromium) is free and open source. Linux is free and open source (if you've got an Android phone you run Linux under the Android OS, the New York Stock Exchange runs on Linux, Google runs their servers on Linux... amateur stuff surely). They're all pretty awesome in my book. Oh, and how does Adobe distribute their Trial of Illustrator that I used to check against the tests? One of the two files it downloaded was "Illustrator_15_LS1.7z".
See that 7z file? That's a 7-zip compressed file... created using a free and open source compression algorithm. Also, 7-zip does what it does very well. However, why didn't adobe use something proprietary? Because after all free can't be as good as (or better than) something you paid for. Right?
Additionally worth considering is that Illustrator was first released in 1987, and the first incarnation of an Inkscape predecessor was produced in 1999 (I believe), Inkscape proper was 2003. 12 years of lead time over our "Grandfather" and corporate funding is probably going to amount to a solid foundation. Also a long time for old design decision to possibly come back and bite you.
Also, to address the comment that Illustrator has had millions of dollars put into it at this point... Ohloh's estimation for Inkscape (in the ~8 years it has existed) has a value of over $7,400,000 (7.4 million USD) and an estimated 135 person years of contributions (in other words, the equivalent of 17 fulltime employees for 8 years). I'm quite sure that our translators' contributions are included in that estimate as well (meaning work other than just programming, including localization). Note: The estimates are based on analysis of the changes to our public version controlled source code repository.
Another thing to note is that we have contributors (past & present) who work and have worked for Adobe, Google, Canonical (Ubuntu), The Linux Foundation (formerly the Open Source Development Labs), Dish Network, Symantec (think Norton Antivirus), military & NASA contractors, w3c Invited Experts for the SVG Specification, also, a handful posses PHDs in various fields of math and science as well, etc. In other words, it's very intelligent and competent people working on this stuff and they're generous to contribute.
--To wrap up--
At the heart of it, Raster is a REALLY loaded word. The very process of rendering your file to the screen is referred to as rasterization. Here is the summary from Wikipedia: "Rasterisation (or rasterization) is the task of taking an image described in a vector graphics format (shapes) and converting it into a raster image (pixels or dots) for output on a video display or printer, or for storage in a bitmap file format.".
The resolution independent blurs in Inkscape are better than the fixed resolution embedded bitmap stuff that Illustrator does. Our blurs work just like gradients, markers, masks, opacity/transparency, and everything else ChewedKandi
says are kosher. The testing method was beyond broken as explained and this was a colossal waste of everyone's time, unless she is finally able to understand.