Actually, why don't you read the original material he was replying to? I don't dispute that OOo isn't good enough for his needs, but then again that wasn't what was being debated.
If you actually read the original argument (from the story!), he's arguing about whether most users will be happy with "good enough". So what if they guy's original post said that he'll refuse to use OOo unless it will open all his documents correctly? He's not "most users".
Next time, try to actually read the article and stay on track with what I'm debating. It helps.
Me, me, me. It's all about me. What's wrong with this generation???
You are wrong. The parent post wasn't talking about just you. It was talking about the vast majority of users. It was you who changed the subject to be about yourself, not me.
Therefore, you are wrong. OpenOffice.org is fine for most users.
Wrong. As has been pointed out oh-so-many times, not even Microsoft can open their own documents in different versions of Word in the same way. So close enough is good enough for most users.
Well, I wouldn't. At least not in development, as I'd like to be able to contribute to the open source community one day, and I'd not want to risk "contaminating" the sources with MS's IPO.
Tongue in cheek/my own misconception. You *are* the press guy! Oops.
What you said was "but actually I have no idea what a professional DTP application needs JPEG or PNG support for as you need CMYK output if you want to use this professionally. (Please spare me the "but Photoshop saves CMYK JPEGs". Thank you.)"
Here's the thing... you can use a profile connection space in most DTP package (Adobe RGB 1998 or even better, CIE-LAB - from memory) that are immense and will just about fit all your possible colours of all the "objects" or images you use. Basically you work in the profile connection space when you use the DTP package and then apply your colour transforms when it gets to the final output device. Therefore you don't need to worry about whether your images are RGB or CMYK. This is called the late-binding model.
The other model is the early-binding model, where the colour is converted to the final output space as soon as possible. This is what you're using, and fair enough too. Many places use it - both ways of doing things have their good and bad points. Basically you *know* what your final output is going to be (a highly calibrated and profiled print press), and this is the colour space you work in. I'd imagine this means your entire organisation is using the same standardised CMYK colour space of your press to work in. Of course, if you get an image (even a TIFF tagged with a CMYK profile) from an external source you'll still need to convert it to your final colour space - in fact as soon as you get it. Hence the reason why it's called early binding.
Incidently, if you're editing on screen, then again you're image editor will need to be applying transforms on the fly as you'll be seeing only a representation of CMYK - your screen is, after all, a transmittive medium (RGB) and not reflective (CMYK). In fact I imagine that's one of the reasons you need the Epson 7600 and 9600 printers: for final proofing. Ironically enough (if this is the case) you'll be doing even more colour transforms, but I cover this below.
My point:
Anyway... I was trying to answer your question in regards to why you'd need support for JPEG or PNG images. (and by the way, if you tag JPEG with CMYK I can't see a problem with that). My point was that in many, many DTP packages the profile connection space is used, thereby largely making the fact that an image is RGB (gathered from a scanner, etc) or CMYK moot. As each of the images will exist in the larger PCS colour space, it only matters what happens when you finally output to press - thus the reason this methodology is called "late-binding".
With the EPSON's, btw, you're not printing PostScript to them. They don't take PostScript directly, they only take their own raster data format. What is actually happening with the Epson printers is that the PS data is being sent to a RIP, which is converting the vector data to proper raster data - it's why it's called a RIP:P - and then the RIP is sending this data to the printer. The fact that you're using PS is really beside the point though. PS is a vector language that just happens to be able to hold colour data (and it does have some colour transforms built-in AFAIK) as I know you're aware. What's happening when you print from captured image to screen to printer is the following:
image (CMYK, RGB - doesn't matter) -> DTP (PCS, like CIE-LAB) -> RIP (transform to RIP's CMYK profile) -> raster data (RGB) -> printer (map RGB to printer's CMYK)
You see how many colour transforms that this needs? That's late binding for you!
Incidently, one last thing. I'm not from the U.S. I'm an Aussie. And I think sticking to servers is better as it's more interesting than printers... I'm getting jealous:P
Ah yes. Trashing. An Aussie's favourite sport. Though not usually done in cowardice, usually most Aussies are quite happy to take the flames that result.
Hmmm. You're a professional designer, I see. Yep, a guy who designs documents, sends them to press guy without profiles or a reference target and then screams at them when things don't look right. I think that says it all.
You are aware that most DTPs use a profile connection space to work with? They bring in an embedded or input profile associated with the image or another object, then do a colour transformation to a device independent profile connection space. The DTP app then does all it's work in that profile connection space.
To view the image on screen, the DTP uses the display profile of your screen and the PCS and applies a rendering intent and then outputs the images/document to the screen. Similarly, to output the document to hardcopy the DTP applies a transformation with a rendering intent using the PCS and the output profiles.
You see, I'm unsure why you think it matters whether an image is in CMYK or not! (you obviously can't view images as CMYK on a computer screen as it's a transmittive device (RGB) anyway) In other words, yes, an output device needs CMYK (usually) for professional output, but as most DTPs use a PCS to store images - so what?
Incidently, slightly OT, but are you aware that most inkjets (even pro-graphics ones like the Epson Stylus Pro 10600) send RGB data to the device and let the printer map the RGB colours to CMYK for you? And also, when you send data down the line your app has to convert to raster data anyway and it won't be the same as your original compressed file?
Yeah. That's right. I'm trolling. I'm trolling when you discover that they forgot to add the postfix user and the lp user in their upgrade from OS X 10.2.x to OS X 10.3.x. And let's not mention the numerous bug-fixes they needed for the Print Centre in OS X 10.1.x
The only thing worse than a Linux fan-boy is a Mac fan-boy. Get a clue.
Uh... for Microsoft it's not about the money. It's about sowing the seeds of fear, uncertainty, doubt into the minds of potential developers and administrators.
They'll be thinking:
"Can I contribute to this project without getting into legal trouble?"
Maybe MS did release the source "accidently" - this would serve their purposes quite nicely
Slashdot Mirror
According to this site eFax is actually a propagator of fax spam.
To the victor go the spoils, huh?
If you actually read the original argument (from the story!), he's arguing about whether most users will be happy with "good enough". So what if they guy's original post said that he'll refuse to use OOo unless it will open all his documents correctly? He's not "most users".
Next time, try to actually read the article and stay on track with what I'm debating. It helps.
Me, me, me. It's all about me. What's wrong with this generation???
You are wrong. The parent post wasn't talking about just you. It was talking about the vast majority of users. It was you who changed the subject to be about yourself, not me.
Therefore, you are wrong. OpenOffice.org is fine for most users.
Wrong. As has been pointed out oh-so-many times, not even Microsoft can open their own documents in different versions of Word in the same way. So close enough is good enough for most users.
Well, I wouldn't. At least not in development, as I'd like to be able to contribute to the open source community one day, and I'd not want to risk "contaminating" the sources with MS's IPO.
wtf? why the hell is this listed as -1: Informative? What sort of idiot moderators do we have on slashdot?
Oh. Wait. It's slashdot, and moderators who don't have any knowledge about the subject matter people are commenting on are free to give people -1s.
Morons.
What you said was "but actually I have no idea what a professional DTP application needs JPEG or PNG support for as you need CMYK output if you want to use this professionally. (Please spare me the "but Photoshop saves CMYK JPEGs". Thank you.)"
Here's the thing... you can use a profile connection space in most DTP package (Adobe RGB 1998 or even better, CIE-LAB - from memory) that are immense and will just about fit all your possible colours of all the "objects" or images you use. Basically you work in the profile connection space when you use the DTP package and then apply your colour transforms when it gets to the final output device. Therefore you don't need to worry about whether your images are RGB or CMYK. This is called the late-binding model.
The other model is the early-binding model, where the colour is converted to the final output space as soon as possible. This is what you're using, and fair enough too. Many places use it - both ways of doing things have their good and bad points. Basically you *know* what your final output is going to be (a highly calibrated and profiled print press), and this is the colour space you work in. I'd imagine this means your entire organisation is using the same standardised CMYK colour space of your press to work in. Of course, if you get an image (even a TIFF tagged with a CMYK profile) from an external source you'll still need to convert it to your final colour space - in fact as soon as you get it. Hence the reason why it's called early binding.
Incidently, if you're editing on screen, then again you're image editor will need to be applying transforms on the fly as you'll be seeing only a representation of CMYK - your screen is, after all, a transmittive medium (RGB) and not reflective (CMYK). In fact I imagine that's one of the reasons you need the Epson 7600 and 9600 printers: for final proofing. Ironically enough (if this is the case) you'll be doing even more colour transforms, but I cover this below.
My point:
Anyway... I was trying to answer your question in regards to why you'd need support for JPEG or PNG images. (and by the way, if you tag JPEG with CMYK I can't see a problem with that). My point was that in many, many DTP packages the profile connection space is used, thereby largely making the fact that an image is RGB (gathered from a scanner, etc) or CMYK moot. As each of the images will exist in the larger PCS colour space, it only matters what happens when you finally output to press - thus the reason this methodology is called "late-binding".
With the EPSON's, btw, you're not printing PostScript to them. They don't take PostScript directly, they only take their own raster data format. What is actually happening with the Epson printers is that the PS data is being sent to a RIP, which is converting the vector data to proper raster data - it's why it's called a RIP :P - and then the RIP is sending this data to the printer. The fact that you're using PS is really beside the point though. PS is a vector language that just happens to be able to hold colour data (and it does have some colour transforms built-in AFAIK) as I know you're aware. What's happening when you print from captured image to screen to printer is the following:
image (CMYK, RGB - doesn't matter) -> DTP (PCS, like CIE-LAB) -> RIP (transform to RIP's CMYK profile) -> raster data (RGB) -> printer (map RGB to printer's CMYK)
You see how many colour transforms that this needs? That's late binding for you!
Incidently, one last thing. I'm not from the U.S. I'm an Aussie. And I think sticking to servers is better as it's more interesting than printers... I'm getting jealous :P
Except there's like, two developers working on an OS X version of OpenOffice.org
Might be nice of Apple to contribute some developers on this one if they want some competition on their desktop.
Too funny.
After all, no IT dept runs a well oiled machine, as we all know.
... that water is more healthy than Pepsi.
Hey, this part of the analogy even works when comparing OpenOffice.org to MS Office!
No chance of that. Internet Explorer is far too integrated into the Windows API to do such a thing.
Ah yes. Trashing. An Aussie's favourite sport. Though not usually done in cowardice, usually most Aussies are quite happy to take the flames that result.
:(
Ooooo... IHBT! IHL
Hmmm. You're a professional designer, I see. Yep, a guy who designs documents, sends them to press guy without profiles or a reference target and then screams at them when things don't look right. I think that says it all.
You are aware that most DTPs use a profile connection space to work with? They bring in an embedded or input profile associated with the image or another object, then do a colour transformation to a device independent profile connection space. The DTP app then does all it's work in that profile connection space.
To view the image on screen, the DTP uses the display profile of your screen and the PCS and applies a rendering intent and then outputs the images/document to the screen. Similarly, to output the document to hardcopy the DTP applies a transformation with a rendering intent using the PCS and the output profiles.
You see, I'm unsure why you think it matters whether an image is in CMYK or not! (you obviously can't view images as CMYK on a computer screen as it's a transmittive device (RGB) anyway) In other words, yes, an output device needs CMYK (usually) for professional output, but as most DTPs use a PCS to store images - so what?
Incidently, slightly OT, but are you aware that most inkjets (even pro-graphics ones like the Epson Stylus Pro 10600) send RGB data to the device and let the printer map the RGB colours to CMYK for you? And also, when you send data down the line your app has to convert to raster data anyway and it won't be the same as your original compressed file?
OK, put like that it's a good idea.
Yeah. That's right. I'm trolling. I'm trolling when you discover that they forgot to add the postfix user and the lp user in their upgrade from OS X 10.2.x to OS X 10.3.x. And let's not mention the numerous bug-fixes they needed for the Print Centre in OS X 10.1.x
The only thing worse than a Linux fan-boy is a Mac fan-boy. Get a clue.
Actually, it's nothing to do with the installer. It worked fine on OS X 10.2.8, then once upgraded to OS X 10.3.3 the software dies a horrible death.
Does this mean that Apple are taking the piss out of a shit company?
I work for a printer company, and every time they release a new OS X it breaks our software.
Actually, OOo does.
Two things:
1. Submit the document through IssueZilla, explainging why the document didn't work.
2. Get OO1.1.1rc3 - it fixes many things.
You might want to check out the Open Office Specification 1.0 Draft 12.
Is that anything like "asthmatic"?
Uh... for Microsoft it's not about the money. It's about sowing the seeds of fear, uncertainty, doubt into the minds of potential developers and administrators.
They'll be thinking:
"Can I contribute to this project without getting into legal trouble?"
Maybe MS did release the source "accidently" - this would serve their purposes quite nicely