This is a case of not using the right tool. It does not matter how much you change the user interface on a hammer, it's still the wrong tool for working with screws... Acrobat is not the right tool to redact a document. You can install an Acrobat plug-in that does that, but with Acrobat alone, you will only cover up information that can be uncovered later.
Removing text or images with Acrobat may not necessarily remove these elements from the PDF file: Acrobat does an incremental save when you use the "Save" function. This means that only the differences to the last version are stored. You have to do a "Save As" after such edits to make sure that the just removed information does not stay in the PDF file. It's actually pretty interesting how the incremental save is implemented: The original content of the PDF file remains unchanged. Acrobat just attaches a new section after the end of the original document with the updates.
To reliably redact a PDF file you need software that's written for specifically this task. This is not a trivial job, so you better make sure that the company who's selling the redact solution to you lives and breaths PDF.
I only know about one such solution: Appligent's Redax Acrobat plug-in. (I don't have any financial interest in this company, I'm just a happy user of one of their other products).
You are right that this idea is nothing new, and you also picked the right company, but the wrong product: The PhotoCD is just a CDR, no hybrid. Kodak does however have the PictureCD, which contains lower resolution images than a PhotoCD, but in addition to the images (which are written to the CDR portion of the disk), you also get some software to manipulate/display/print your images. This software is on the CD portion of this CD-PROM.
Unfortunately, Kodak does not seem to have information about this technology on their web site anymore. The only thing I was able to find is this discontinuation notice.
I hate to reply to my own posting, this only shows that I did not think enough before clicking on "Submit"...
One other important feature that is missing here (and is part of most commercial DMSs) is an integrated version management system.
Working with documents is not that much different from working with source code: It's always a good idea to keep old versions around so that you can go back and recover the one paragraph you thought would definitely not be needed anymore.
This is a good start, but it's still missing one important feature of a complete document management system: To find a given document when you don't remember or don't have any of the meta data, the only way to not open every single document in the system is to do a full text search. Commercial document management systems (DMS) allow this regardless of the file format.
ALso, have you ever heard about ODMA (Open Document Management API)? This was intended as a cross-pattform interface for DMSs, but so far only has Windows implementations. Why not use an already established standard so that any DMS-aware application can use whatever DMS is installed on the system?
I don't know any details, but here is some background: I am maintaining the Sane backend for EPSON scanners. This is the software that sits between the frontends (e.g. xsane or xscanimage) and the hardware. I have a pretty good relationship with EPSON, so a while ago they asked me if I would have any objections to them taking my backend, modifying it (still under the GPL) and adding their own frontend to it.
The Sane backends are GPL'ed, but provide one exception: "it is permissible to link against such a library without affecting the licensing status of the program that uses the libraries." - this is a quote from the LICENSE file that is part of the Sane distribution.
EPSON KOWA did actually release the source code for their backend - even though they were not required to do so, they would still be allowed to link against the backends if their software were closed source. They did however make one exception: The image manipulation routines that they use to in their Windows and Mac drivers is delivered as a library without sources. They do provide the sources (under the GPL) for the rest.
My opinion is that they are the owner and the copyright holders of their frontend code, so they should be allowed to do anything with it - e.g. link agains a closed source library, but this is probably just my naive common sense interpretation, everybody with a law degree probably has a different opinion.
So EPSON did not try to sneak some GPL code into their closed source applications, they did not relabel GPL code, they wanted to do the right thing and provide us with their source code.
EPSON is very pro open source, they provide programming information for their scanners (and printers for the gimp-print project) and if I run into problems they even provide hardware to debug problems.
I don't get payed for saying this, but if you are in the market for a scanner (or a printer) then please consider an EPSON device. Not only are these pretty good scanners and probably the best inkjet printers around, they are very nice to us Linux users.:-)
The problem with bamboo is not that it grows taller, the problem is that it spreads out like crazy. If you have bamboo in one area, it's roots will spread out and will spawn new plants several feet away. I once had some dwarf bamboo in my yard, the "dwarf" however only related to the parts above ground. I had to take it out, otherwise it would have overtaken the neighborhood. Once the main plant was out, it took about a year until we got rid of all traces of the plant below and above ground.
You are right, quality will degrade if you go from RGB to CMYK and back to RGB. That's why this dual convertion is usually not done. You would convert only once into your (device dependant) CMYK color space once you know where and how an image is going to be printed and do your final image adjustments there.
The reason for this is that you RGB is basically a monitor color space and CMYK is a priner color space. There are colors that you can display on a monitor that can not be printed, and there are colors that can be printed, but not displayed on a monitor. If you convert RGB to CMYK using a profile, the conversion process will take care of adjusting your colors to that either the colors that can not be printed are either clipped, or the whole image is (color-wise) compressed, so that overall the colors look "right".
This is correct, but you get CMY or CMYK that has nothing to do with any particular device. The decomposition is done by just inverting the RGB values plus some black generation. When the conversion is done the right way, you always have one particular device in mind, otherwise CMYK is not different from RGB - anything that can be done in one colorspace has a similar corresponding operation in the other color space.
CMYK only becomes useful if you have device specifid CMYK. This however means that for the conversion of RGB or Lab or any other color space you are working in into CMYK you need a "device description file", which is usually an ICC profile that was created for your device.
To make Gimp fully CMY/CMYK aware, you need to add two things: All image manipulation operations have to work in the CMYK colorspace (this means that you don't have to first decompose the image) and we need a way to convert any image into a device specific CMYK file.
As long as you don't inhale you should be fine...:-)
CMYK is how printers print, so if CMYK would be illegal you would not be able to do any color prints on your inkjet. If you look at e.g. gimp-print (or for that matter any other software that can print to a color printer) you are actually creating CMYK output, otherwise your printer would only print BW.
So CMYK support in e.g. Gimp would not be a problem from a patent point of view (now keep in mind that I am no lawyer and there may actually be patents covering some aspects of a CMYK workflow) - actually, Gimp can already convert RGB images into "kind of CMY / CMYK separations" and back into RGB. However, this does not make a lot of sense if you can not convert to "real" (meaning device specific CMYK). This is only possible using some sort of a device description, which usually is an ICC color profile. And this is where we run into problems with patents.
But just because there are patents on certain processes, this does not mean that we can not come up with different mechanism that can accomplish the same, but using a different method.
I would not call Raph's write up a negative review, it's actually not a review at all: He says that he did cut corners so we don't know how good or bad the ARGYLL profiles could be.
LCMS is actually being used by a few software packages and is installed by default with every SuSE system. It's the more useable system of the two at this time, but this is not surprising: ARGYLL is not a finished package yet, so I think it's too early to talk about how good or bad it is. It is however a pretty good start and a lot of functionality is already there, just not for the 'normal' user: It's not easy to install and you have to use a number of command line programs with fairly complex parameters to get something working.
Again, it's a beginning and a very impressive one.
You can use both LCMS and ARGYLL to make an application ICC profile capable without having to use the profiling functionality both packages offer: Just use a commercial package to create profiles and then use them e.g. when you convert an image or when you print.
... and: not every bright developer is a good web designer. Creating a glizzy web site usually also takes too much time away from more fun stuff like figuring out stuff and coding...
Even though this is OT here, there are two projects that will eventually provide a (actually two) free color management system:
LittleCMS (at http://www.littlecms.com) and Argyll (at http://web.access.net.au/argyll/argyllcms.html). All the basic stuff is already there, Argyll can even create ICC profiles for printers.
... and to bring this thread back on track: I can do everything that Turboprint does with gimp-print and CUPS.
I've never used a FireWire hard disk, but I am using an EPSON Expression1680 scanner that is connected over FireWire. This device is hot-swappable, you just disconnect it, reconnect it and it is still working. I would suspect that disks behave similar as long as they are unmounted.
If you have an empty slot in the machine you could add e.g. a standard NIC card with an EPROM socket. The EPROM socket on these cards has nothing to do with the cards core functionality, it's just a place where you can put a BIOS extension EPROM.
It's been a long time since I played with booting a machine over the net and I don't remember the name of the package that allows to create an EPROM image or a floppy image from the same data. The floppy image allows you to test the package before you burn it into an EPROM. Use this and see if you can the machine to boot via the wireless card. If it works, then burn the EPROM and put it into the standard NIC card (which you don't even have to configure).
... the SP0256 was a great chip. I wrote a development environment in Modula-2 for it... and
then built a couple of talking alarm clocks.
Adobe Acrobat "Paper Capture" can do this
on
From Paper To PDF?
·
· Score: 2
If you don't have to process huge amounts of pages then Adobe Acrobat can do what you want: It's basically a cheap version of Adobe Capture that is probably not as fast and not as easy to use. The "Paper Capture" option is located under the "Tools" menu. I don't think that Adobe will bring out a Unix version of Acrobat 4.0, therefore this is a MS/Mac only solution. But it's more cost effective than Capture.
Any real scientist would rather spend time in the lab than creating pretty pictures. Just because you feel light headed doesn't mean that you've manipulated gravity.
... you're welcome (even though I did not yet participate in the discussion:-)
I think you've discovered the right approach to Linux: It can be a different thing to everybody. You like the directness of the command line (as do I), but there are others out there intimidated by that. Just let them have their kdf GUI version of df (even though I can not understand why that's neccessary, but it certainly has it's place).
I'm personally using KDE, just because I don't care what kind of borders my vi running in an exterm has. Linux gives us the freedom to have a command line
We need the masses to make things happen. I'm trying to get information from a manufacturer. About half a year ago I tried the same thing without even a response. Now I've received an email, a contact address and a draft version of a document. This only happened because Linux now is something the mainstream media is reporting about.
We really have nothing to lose if we can invite the world to our Linux experience. Let's just not scare them away with an attitude that does not tolerate any window managers that look like some Microsoft products.
Let me guess: You don't follow the Wine development at all, but like to complain? If you would have read the wine mailing list, or looked into the Wine CVS tree every once in a while you would have noticed that Corel did work on the project and contributed to the code base.
I've just done a quick search on the web, but was not able to come up with an answer to my question: When two different manufacturers label their products as 802.11 complient, does this mean that I can use them together (as long as the frequency is the same, e.g. 2.4GHz)?
And here is another one: When I buy a card in the US, will I be able to connect to lets say the European version?
Slashdot Mirror
This is a case of not using the right tool. It does not matter how much you change the user interface on a hammer, it's still the wrong tool for working with screws... Acrobat is not the right tool to redact a document. You can install an Acrobat plug-in that does that, but with Acrobat alone, you will only cover up information that can be uncovered later.
... that's what I usually tell people when they ask me if I'm into games. Most people don't know what this is, so I add "it's a text adventure" :)
See the Linux Journal article at http://www.linuxjournal.com/article.php?sid=6887
Removing text or images with Acrobat may not necessarily remove these elements from the PDF file: Acrobat does an incremental save when you use the "Save" function. This means that only the differences to the last version are stored. You have to do a "Save As" after such edits to make sure that the just removed information does not stay in the PDF file. It's actually pretty interesting how the incremental save is implemented: The original content of the PDF file remains unchanged. Acrobat just attaches a new section after the end of the original document with the updates.
To reliably redact a PDF file you need software that's written for specifically this task. This is not a trivial job, so you better make sure that the company who's selling the redact solution to you lives and breaths PDF.
I only know about one such solution: Appligent's Redax Acrobat plug-in. (I don't have any financial interest in this company, I'm just a happy user of one of their other products).
Robert H. Goddard did his rocket test flights in and around Roswell. The local museum has a replica of his work shop.
Unfortunately, Kodak does not seem to have information about this technology on their web site anymore. The only thing I was able to find is this discontinuation notice.
One other important feature that is missing here (and is part of most commercial DMSs) is an integrated version management system.
Working with documents is not that much different from working with source code: It's always a good idea to keep old versions around so that you can go back and recover the one paragraph you thought would definitely not be needed anymore.
ALso, have you ever heard about ODMA (Open Document Management API)? This was intended as a cross-pattform interface for DMSs, but so far only has Windows implementations. Why not use an already established standard so that any DMS-aware application can use whatever DMS is installed on the system?
They did no t"snatch" any code. Please read my reply to one of the first posts for some background information.
The Sane backends are GPL'ed, but provide one exception: "it is permissible to link against such a library without affecting the licensing status of the program that uses the libraries." - this is a quote from the LICENSE file that is part of the Sane distribution.
EPSON KOWA did actually release the source code for their backend - even though they were not required to do so, they would still be allowed to link against the backends if their software were closed source. They did however make one exception: The image manipulation routines that they use to in their Windows and Mac drivers is delivered as a library without sources. They do provide the sources (under the GPL) for the rest.
My opinion is that they are the owner and the copyright holders of their frontend code, so they should be allowed to do anything with it - e.g. link agains a closed source library, but this is probably just my naive common sense interpretation, everybody with a law degree probably has a different opinion.
So EPSON did not try to sneak some GPL code into their closed source applications, they did not relabel GPL code, they wanted to do the right thing and provide us with their source code.
EPSON is very pro open source, they provide programming information for their scanners (and printers for the gimp-print project) and if I run into problems they even provide hardware to debug problems.
I don't get payed for saying this, but if you are in the market for a scanner (or a printer) then please consider an EPSON device. Not only are these pretty good scanners and probably the best inkjet printers around, they are very nice to us Linux users. :-)
The problem with bamboo is not that it grows taller, the problem is that it spreads out like crazy. If you have bamboo in one area, it's roots will spread out and will spawn new plants several feet away. I once had some dwarf bamboo in my yard, the "dwarf" however only related to the parts above ground. I had to take it out, otherwise it would have overtaken the neighborhood. Once the main plant was out, it took about a year until we got rid of all traces of the plant below and above ground.
You are right, quality will degrade if you go from RGB to CMYK and back to RGB. That's why this dual convertion is usually not done. You would convert only once into your (device dependant) CMYK color space once you know where and how an image is going to be printed and do your final image adjustments there.
The reason for this is that you RGB is basically a monitor color space and CMYK is a priner color space. There are colors that you can display on a monitor that can not be printed, and there are colors that can be printed, but not displayed on a monitor. If you convert RGB to CMYK using a profile, the conversion process will take care of adjusting your colors to that either the colors that can not be printed are either clipped, or the whole image is (color-wise) compressed, so that overall the colors look "right".
This is correct, but you get CMY or CMYK that has nothing to do with any particular device. The decomposition is done by just inverting the RGB values plus some black generation. When the conversion is done the right way, you always have one particular device in mind, otherwise CMYK is not different from RGB - anything that can be done in one colorspace has a similar corresponding operation in the other color space.
CMYK only becomes useful if you have device specifid CMYK. This however means that for the conversion of RGB or Lab or any other color space you are working in into CMYK you need a "device description file", which is usually an ICC profile that was created for your device.
To make Gimp fully CMY/CMYK aware, you need to add two things: All image manipulation operations have to work in the CMYK colorspace (this means that you don't have to first decompose the image) and we need a way to convert any image into a device specific CMYK file.
As long as you don't inhale you should be fine... :-)
CMYK is how printers print, so if CMYK would be illegal you would not be able to do any color prints on your inkjet. If you look at e.g. gimp-print (or for that matter any other software that can print to a color printer) you are actually creating CMYK output, otherwise your printer would only print BW.
So CMYK support in e.g. Gimp would not be a problem from a patent point of view (now keep in mind that I am no lawyer and there may actually be patents covering some aspects of a CMYK workflow) - actually, Gimp can already convert RGB images into "kind of CMY / CMYK separations" and back into RGB. However, this does not make a lot of sense if you can not convert to "real" (meaning device specific CMYK). This is only possible using some sort of a device description, which usually is an ICC color profile. And this is where we run into problems with patents.
But just because there are patents on certain processes, this does not mean that we can not come up with different mechanism that can accomplish the same, but using a different method.
I would not call Raph's write up a negative review, it's actually not a review at all: He says that he did cut corners so we don't know how good or bad the ARGYLL profiles could be.
...
LCMS is actually being used by a few software packages and is installed by default with every SuSE system. It's the more useable system of the two at this time, but this is not surprising: ARGYLL is not a finished package yet, so I think it's too early to talk about how good or bad it is. It is however a pretty good start and a lot of functionality is already there, just not for the 'normal' user: It's not easy to install and you have to use a number of command line programs with fairly complex parameters to get something working.
Again, it's a beginning and a very impressive one.
You can use both LCMS and ARGYLL to make an application ICC profile capable without having to use the profiling functionality both packages offer: Just use a commercial package to create profiles and then use them e.g. when you convert an image or when you print.
... and: not every bright developer is a good web designer. Creating a glizzy web site usually also takes too much time away from more fun stuff like figuring out stuff and coding
Even though this is OT here, there are two projects that will eventually provide a (actually two) free color management system:
LittleCMS (at http://www.littlecms.com) and Argyll (at http://web.access.net.au/argyll/argyllcms.html). All the basic stuff is already there, Argyll can even create ICC profiles for printers.
... and to bring this thread back on track: I can do everything that Turboprint does with gimp-print and CUPS.
I've never used a FireWire hard disk, but I am using an EPSON Expression1680 scanner that is connected over FireWire. This device is hot-swappable, you just disconnect it, reconnect it and it is still working. I would suspect that disks behave similar as long as they are unmounted.
If you have an empty slot in the machine you could add e.g. a standard NIC card with an EPROM socket. The EPROM socket on these cards has nothing to do with the cards core functionality, it's just a place where you can put a BIOS extension EPROM.
It's been a long time since I played with booting a machine over the net and I don't remember the name of the package that allows to create an EPROM image or a floppy image from the same data. The floppy image allows you to test the package before you burn it into an EPROM. Use this and see if you can the machine to boot via the wireless card. If it works, then burn the EPROM and put it into the standard NIC card (which you don't even have to configure).
Karl Heinz
... the SP0256 was a great chip. I wrote a development environment in Modula-2 for it... and
then built a couple of talking alarm clocks.
If you don't have to process huge amounts of pages then Adobe Acrobat can do what you want: It's basically a cheap version of Adobe Capture that is probably not as fast and not as easy to use. The "Paper Capture" option is located under the "Tools" menu. I don't think that Adobe will bring out a Unix version of Acrobat 4.0, therefore this is a MS/Mac only solution. But it's more cost effective than Capture.
Any real scientist would rather spend time in the lab than creating pretty pictures. Just because you feel light headed doesn't mean that you've manipulated gravity.
... you're welcome (even though I did not yet participate in the discussion :-)
I think you've discovered the right approach to Linux: It can be a different thing to everybody. You like the directness of the command line (as do I), but there are others out there intimidated by that. Just let them have their kdf GUI version of df (even though I can not understand why that's
neccessary, but it certainly has it's place).
I'm personally using KDE, just because I don't care what kind of borders my vi running in an exterm has. Linux gives us the freedom to have a command line
We need the masses to make things happen. I'm trying to get information from a manufacturer. About half a year ago I tried the same thing without even a response. Now I've received an email, a contact address and a draft version of a document. This only happened because Linux now is something the mainstream media is reporting about.
We really have nothing to lose if we can invite the world to our Linux experience. Let's just not scare them away with an attitude that does not tolerate any window managers that look like some Microsoft products.
Let me guess: You don't follow the Wine development at all, but like to complain? If you would have read the wine mailing list, or looked into the Wine CVS tree every once in a while you would have noticed that Corel did work on the project and contributed to the code base.
... now this is interesting: There is Europe and there is France. Something I suspected all along :-)
I've just done a quick search on the web, but was not able to come up with an answer to my question: When two different manufacturers label their products as 802.11 complient, does this mean that I can use them together (as long as the frequency is the same, e.g. 2.4GHz)?
And here is another one: When I buy a card in the US, will I be able to connect to lets say the European version?