A color profile from the ink vendor would help, but the vendor would need to release a number of profiles, one for each type of paper. The perceived color is a function of the interaction between the ink (the optical properties of the particular pigment or dye) and the paper (how absorbent is it, does it contain any flourescents or optical brightners, is it glossy or matte).
Accurate color is a very tricky thing. When a business depends on accurate color (commercial printing, ad agency work, etc), they expect to pay more for it, and usually will go with the original manufacturer's consumables.
A quick search on BestBuy shows that mfg's cartridges are priced at about $1300 Cdn / litre. Obviously, ink doesn't cost that much to manufacture, but the mfg's do have to also recover the costs of the plastic casing, any electronics, packaging, and freight costs, but there is still plenty-o-money on the table for everyone in the supply chain.
Even the 3rd party refill/refurb market is charging around $450 / litre, so they still have a decent profit margin.
I used to work for Kodak designing commercial inkjet printers with a $40K pricetag. Our customers would pay about $450 for an ink kit, which worked out to about $250 US / litre. Again, there was still plenty of margin in that.
I think the biggest concerns with 3rd party inks for consumers are:
Nozzle clogging - TFA mentions clogging in passing, but doesn't say they are going to test for this. In my experience, clogging occurs over time, as crystals form at the print head. More expensive inks contain a better (or just more) biocide to prevent crystal growth. Clogged print heads (or even worse, clogged ink lines) can be expensive to fix, and usually the cheapest repair is to toss the printer in the dumpster and buy new.
Archival quality - TFA does mention pictures fading over time and they will be testing for this. Subtle differences in ink and paper composition can have a dramatic effect. Remember, color is the effect produced by the combination of ink and paper. I think there are some techniques used in both paper and ink that can lessen the effects of UV rays. Again, this will cost money.
Color accuracy - TFA has side by side images of original vs. 3rd party prints, using the same driver settings, and it is pretty easy to see a big difference. Fortunately, you can correct for this by creating a custom ICC profile for your ink+paper combination. Profiling is not something that your Mom will want to do (unless she's a graphic designer), but it can be done. Profiling might be cost effective if you are a small design shop, producing some color-critical work, but you need to optimize costs.
As for me? I've switched over to laser printing for most of my work, and when I do need color output (which is rare), I use HP multi-function printer that cam with my PC and use geniune HP inks, just so that I won't have to worry long term nozzle clogging from infrequent use.
If my HP inkjet ever packs it in, then I'll switch over to a color lazer and be done with it.
No, I don't think a Flash developer will find the switch to Apollo as seemless as Flex developers. But the transition is still doable if you are quite comfortable with ActionScript in your Flash apps. Said differently, if you are more of a Flash coder than a Flash designer, you should be up and running in Apollo fairly quickly. I'm not sure how many Flash developers that previous statement applies to, since any of those Flash coder could have made the switch to Flex months ago. If they didn't make that switch because the they couldn't grok Flex, then they will have a hard time groking Apollo as well.
The developer transition cases as I see them:
If you're a Flex developer comfortable with ActionScript 3 Apollo is just a minor tweak on things, adding a few more classes to the framework. You'll be up and running in minutes, not hours or days.
If you're a Flex developer, but limited to ActionScript 2 The biggest hurdle is the switch from the AS2 framework to the AS3 framework. The Apollo VM can still run AS2 code and does allow AS2 code to bridge into AS3 code and vice versa, but that soon turns into a maintenance hassle. A couple of the developers I spoke with at Adobe said it was really worth the hassle to convert the AS2 code to AS3 first and then recompile for Apollo.
If you're a Flash developer Get comfy with Flex first, then move to Apollo. http://www.lynda.com/ has great online courses for learning Flex and ActionScript3.
If you're an HTML/CSS/AJAX developer If you're app runs in Safari, then it very likely will work in an Apollo sandbox as well. The biggest hurdle for these developers will be choosing how to integrate Apollo into their development environment. They could switch over to Flex builder ($$), switch over to Eclipse with Flex&Apollo plugins (free), or just integrate some of the Apollo command line tools into their existing configs.
Oops. I should have double-checked before I posted the last reply.
A properly-installed Apollo app does change its process name to the app name, so that will make software firewall configuration more manageable than Java apps. My first test was on an Apollo app launched from with the Flex builder IDE. But after checking some of the other apps installed on my system, I confirmed that process is correctly named after the app.
The security of the Apollo runtime sandbox is still unknown. At least, that is the official word from Adobe. A number of developers in attendence on Friday night were asking security-related questions about the new framework, and Adobe was pretty up front that the final security architecture has not been chosen.
It wasn't the case that the Apollo product was dealing with security as an afterthought, instead I got the feeling that they were evaluating a bunch of different options and were asking for feedback about how fine-grained the security control should be. I'm guessing that each implementation choice will need to be reviewed and vetted by people much smarter than I.
Here are a few security-related observations from Friday's discussions:
1) The installation process for Apollo apps will allow for digitally signed apps.
2) The Apollo team was saying that people should treat the installation of an Apollo app just like the installation of any other desktop app. If you don't trust the supplier of the app, don't install it. Use #1 to verify the supplier of the app.
3) Security is just plain hard, even with VMs like Java or Apollo.
I think that the Apollo runtime will suffer from the same firewall problems as Java apps. Apollo apps are launched within a process called adl (ADobe Launcher, I'm guessing). Java apps are launched within a process called javaw. I'm betting there will be a bunch of WinXP firewall exceptions listed as "adl.exe" just like there are currently many exceptions for "javaw.exe".
The Apollo architect raised an interesting point when he said it was fine for all of us geeks to talk about the details of various security implementations, but how do we architect a security solution so that our grandparents can understand the right thing to do. The answer isn't obvious at all.
Wow. Most of the posts on this topic are so far from reality, I'm not sure where to begin. Maybe this comment will be modded up as flame bait or 'Adobe FanBoy', but oh well.
I was at the Apollo pre-release event in San Francisco last Friday night, along with 200 other geeks. Adobe called it ApolloCamp, but there were no wienie roasts or sleeping bags. Adobe put on a fine show, with each attendee receiving a free full version of Flex Builder 2 for either Mac or PC, plus a copy of the Apollo alpha runtime, a free DVD of instructional material from http://www.lynda.com/.
I wrote my first Apollo app at about 12:30 AM Saturday morning, 20 minutes after I got out of the cab returning from the Adobe event. If you're already a Flex developer (and I wasn't), then you're an Apollo developer now too! If you have a web-based app that already runs in Safari, chances are very good it will just run on the Apollo runtime too. Oh, and if you were a web developer, now you're a desktop developer too.
I think Adobe has a winner on their hands, so it will be interesting to look back at this post in a couple of years and see how things go.
Check out the videos of the event at http://video.onflex.org/ to get a more clear idea of what Apollo is and isn't. Yes, Linux support isn't in 1.0, but it is planned. Many of the developers in attendance were asking about Linux. Other platforms being targeted after Linux include mobile devices and game console platforms.
Slashdot Mirror
A color profile from the ink vendor would help, but the vendor would need to release a number of profiles, one for each type of paper. The perceived color is a function of the interaction between the ink (the optical properties of the particular pigment or dye) and the paper (how absorbent is it, does it contain any flourescents or optical brightners, is it glossy or matte). Accurate color is a very tricky thing. When a business depends on accurate color (commercial printing, ad agency work, etc), they expect to pay more for it, and usually will go with the original manufacturer's consumables.
Even the 3rd party refill/refurb market is charging around $450 / litre, so they still have a decent profit margin.
I used to work for Kodak designing commercial inkjet printers with a $40K pricetag. Our customers would pay about $450 for an ink kit, which worked out to about $250 US / litre. Again, there was still plenty of margin in that.
I think the biggest concerns with 3rd party inks for consumers are:
Nozzle clogging - TFA mentions clogging in passing, but doesn't say they are going to test for this. In my experience, clogging occurs over time, as crystals form at the print head. More expensive inks contain a better (or just more) biocide to prevent crystal growth. Clogged print heads (or even worse, clogged ink lines) can be expensive to fix, and usually the cheapest repair is to toss the printer in the dumpster and buy new.
Archival quality - TFA does mention pictures fading over time and they will be testing for this. Subtle differences in ink and paper composition can have a dramatic effect. Remember, color is the effect produced by the combination of ink and paper. I think there are some techniques used in both paper and ink that can lessen the effects of UV rays. Again, this will cost money.
Color accuracy - TFA has side by side images of original vs. 3rd party prints, using the same driver settings, and it is pretty easy to see a big difference. Fortunately, you can correct for this by creating a custom ICC profile for your ink+paper combination. Profiling is not something that your Mom will want to do (unless she's a graphic designer), but it can be done. Profiling might be cost effective if you are a small design shop, producing some color-critical work, but you need to optimize costs.
As for me? I've switched over to laser printing for most of my work, and when I do need color output (which is rare), I use HP multi-function printer that cam with my PC and use geniune HP inks, just so that I won't have to worry long term nozzle clogging from infrequent use.
If my HP inkjet ever packs it in, then I'll switch over to a color lazer and be done with it.
No, I don't think a Flash developer will find the switch to Apollo as seemless as Flex developers. But the transition is still doable if you are quite comfortable with ActionScript in your Flash apps. Said differently, if you are more of a Flash coder than a Flash designer, you should be up and running in Apollo fairly quickly. I'm not sure how many Flash developers that previous statement applies to, since any of those Flash coder could have made the switch to Flex months ago. If they didn't make that switch because the they couldn't grok Flex, then they will have a hard time groking Apollo as well.
The developer transition cases as I see them:
If you're a Flex developer comfortable with ActionScript 3
Apollo is just a minor tweak on things, adding a few more classes to the framework. You'll be up and running in minutes, not hours or days.
If you're a Flex developer, but limited to ActionScript 2
The biggest hurdle is the switch from the AS2 framework to the AS3 framework. The Apollo VM can still run AS2 code and does allow AS2 code to bridge into AS3 code and vice versa, but that soon turns into a maintenance hassle. A couple of the developers I spoke with at Adobe said it was really worth the hassle to convert the AS2 code to AS3 first and then recompile for Apollo.
If you're a Flash developer
Get comfy with Flex first, then move to Apollo. http://www.lynda.com/ has great online courses for learning Flex and ActionScript3.
If you're an HTML/CSS/AJAX developer
If you're app runs in Safari, then it very likely will work in an Apollo sandbox as well. The biggest hurdle for these developers will be choosing how to integrate Apollo into their development environment. They could switch over to Flex builder ($$), switch over to Eclipse with Flex&Apollo plugins (free), or just integrate some of the Apollo command line tools into their existing configs.
Oops. I should have double-checked before I posted the last reply.
A properly-installed Apollo app does change its process name to the app name, so that will make software firewall configuration more manageable than Java apps. My first test was on an Apollo app launched from with the Flex builder IDE. But after checking some of the other apps installed on my system, I confirmed that process is correctly named after the app.
The security of the Apollo runtime sandbox is still unknown. At least, that is the official word from Adobe. A number of developers in attendence on Friday night were asking security-related questions about the new framework, and Adobe was pretty up front that the final security architecture has not been chosen.
It wasn't the case that the Apollo product was dealing with security as an afterthought, instead I got the feeling that they were evaluating a bunch of different options and were asking for feedback about how fine-grained the security control should be. I'm guessing that each implementation choice will need to be reviewed and vetted by people much smarter than I.
Here are a few security-related observations from Friday's discussions:
1) The installation process for Apollo apps will allow for digitally signed apps.
2) The Apollo team was saying that people should treat the installation of an Apollo app just like the installation of any other desktop app. If you don't trust the supplier of the app, don't install it. Use #1 to verify the supplier of the app.
3) Security is just plain hard, even with VMs like Java or Apollo.
I think that the Apollo runtime will suffer from the same firewall problems as Java apps. Apollo apps are launched within a process called adl (ADobe Launcher, I'm guessing). Java apps are launched within a process called javaw. I'm betting there will be a bunch of WinXP firewall exceptions listed as "adl.exe" just like there are currently many exceptions for "javaw.exe".
The Apollo architect raised an interesting point when he said it was fine for all of us geeks to talk about the details of various security implementations, but how do we architect a security solution so that our grandparents can understand the right thing to do. The answer isn't obvious at all.
Wow. Most of the posts on this topic are so far from reality, I'm not sure where to begin. Maybe this comment will be modded up as flame bait or 'Adobe FanBoy', but oh well.
I was at the Apollo pre-release event in San Francisco last Friday night, along with 200 other geeks. Adobe called it ApolloCamp, but there were no wienie roasts or sleeping bags. Adobe put on a fine show, with each attendee receiving a free full version of Flex Builder 2 for either Mac or PC, plus a copy of the Apollo alpha runtime, a free DVD of instructional material from http://www.lynda.com/.
I wrote my first Apollo app at about 12:30 AM Saturday morning, 20 minutes after I got out of the cab returning from the Adobe event. If you're already a Flex developer (and I wasn't), then you're an Apollo developer now too! If you have a web-based app that already runs in Safari, chances are very good it will just run on the Apollo runtime too. Oh, and if you were a web developer, now you're a desktop developer too.
I think Adobe has a winner on their hands, so it will be interesting to look back at this post in a couple of years and see how things go.
Check out the videos of the event at http://video.onflex.org/ to get a more clear idea of what Apollo is and isn't. Yes, Linux support isn't in 1.0, but it is planned. Many of the developers in attendance were asking about Linux. Other platforms being targeted after Linux include mobile devices and game console platforms.