Version: unknown (using KDE 3.2 BRANCH >= 20040204, (testing/unstable)) Compiler: gcc version 3.3.3 20040214 (prerelease) (Debian) OS: Linux (i686) release 2.6.2 Please add an option to koconverter to send output to stdout. This would be helpful when koconverter is used by tools such as indexers. Michael
On Saturday 21 February 2004 22:55, Michael Schuerig wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=75799 > Summary: koconverter: output to stdout > Product: koffice > Version: unspecified > Platform: unspecified > OS/Version: Linux > Status: UNCONFIRMED > Severity: wishlist > Priority: NOR > Component: general > AssignedTo: koffice kde org > ReportedBy: michael schuerig de > > > Version: unknown (using KDE 3.2 BRANCH >= 20040204, > (testing/unstable)) Compiler: gcc version 3.3.3 20040214 > (prerelease) (Debian) OS: Linux (i686) release 2.6.2 > > Please add an option to koconverter to send output to stdout. This would be > helpful when koconverter is used by tools such as indexers. With the actual filter system outputing to stdout is not possible. As we are switching to the OO filter system, we are not going to change the filter system soon. > > Michael Have a nice day! (...)
Sending a ZIP file to stdout wouldn't give a very nice result (lots of binary characters). Sending only maindoc.xml would discard much other stuff and result in bugs... Why not use koconverter to a tempfile and then use unzip to send to stdout the wanted file(s)? See unzip -p.
David, that's what I'm doing right now. As the filter system is undergoing changes anyway, I suggest to close this bug for now. Michael
On Sunday 22 February 2004 20:31, Michael Schuerig wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=75799 > > > > > ------- Additional Comments From michael schuerig de 2004-02-22 20:31 > ------- David, that's what I'm doing right now. As the filter system is > undergoing changes anyway, I suggest to close this bug for now. No, please, keep it open please! > > Michael (...)
On Monday 23 February 2004 11:44, Nicolas Goutte wrote: > No, please, keep it open please! Why? IMHO it's a request that doesn't make much sense (as I said, binary characters on stdout are not a good idea).
I do not understand why binary characters on stdout would be a problem. It is not the default, it would need an option to work so. Other command line tools works so too (tar, zip, gzip...) Also you are assuming that the result is binary. But many file formats are text (RTF, AbiWord, CSV...) Have a nice day!
On Monday 23 February 2004 15:14, Nicolas Goutte wrote: > I do not understand why binary characters on stdout would be a problem. > It is not the default, it would need an option to work so. Other command line tools > works so too (tar, zip, gzip...) Sure but an indexing tool won't understand the zip format directly. But: > Also you are assuming that the result is binary. But many file formats are > text (RTF, AbiWord, CSV...) You are right. Didn't think about all those. OK.
Note that those tools (tar etc) listen to the encoding defined by the user (using an environment var) Doing this kind of re-coding adds a lot of complexity.. CSV is not a latin1 or even an ASCII defined standard IIRC since you can still type unicode characters (Chinese...) which should be encoded. All in all; its a lot harder then just dumping input. I agree with David that this is not a good idea. You did not answer Davids question why this should stay open, I'd like to know that as well.
> Note that those tools (tar etc) listen to the encoding defined by the user (using an environment var) ? > Doing this kind of re-coding adds a lot of complexity.. ? We would just cat the tempfile containing the result, even if it's ZIP. > CSV is not a latin1 or even an ASCII defined standard IIRC since you can still type unicode characters (Chinese...) which should be encoded. ? stdout isn't latin1-only either. But the encoding is already done, in the file itself. > All in all; its a lot harder then just dumping input. I don't see why. > I agree with David that this is not a good idea. I changed my mind since :) > You did not answer Davids question why this should stay open Because it's especially useful for text outputs, like CSV/HTML/RTF/TXT etc.
On Monday 23 February 2004 15:27, zander@kde.org wrote: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > http://bugs.kde.org/show_bug.cgi?id=75799 > > > > > ------- Additional Comments From zander kde org 2004-02-23 15:27 ------- > Note that those tools (tar etc) listen to the encoding defined by the user > (using an environment var) ? Where do you see an encoding in: tar -cvf - * | bzip2 -c - > file,tar.bz2 (Yes, I know, nowadays tar can do bzip2 with parameters and you do not need a pipe anymore.) > > Doing this kind of re-coding adds a lot of complexity.. Why re-coding? > > CSV is not a latin1 or even an ASCII defined standard IIRC since you can > still type unicode characters (Chinese...) which should be encoded. Selecting the encoding of CSV is a wish and we will need to give the possibilty to select it non-interactively. (That is part of supporting a batch mode for the filters.) > > All in all; its a lot harder then just dumping input. If you can drop it to a file, you can put it through a pipe too. If the next tool that you use cannot cope with the file format (e.g. with the encoding) you will have a problem anyway whatever you use a temporary file or a pipe. > > I agree with David that this is not a good idea. You did not answer Davids > question why this should stay open, I'd like to know that as well. Koconcverter is a tool for power users. Normal users will never touch it anyway. But power users know pipes and would prefer being able to use stdin and stdout with it. (And personally, I had to implement the raw filw support in the KWord 1.3 import filter just because I could not use stdin with koconverter. In this case I would have create a ZIP or TAR file on the fly.) Also pipes permits the reading program to start processing when the writing program is still writing. That is something that you cannot do with temp files. (However currently koconverter would need temp files to support stdin and stdout, so it has little sence to support it so. Otherwise I would have implented it already months ago.) Have a nice day! > ____________________________________ > koffice mailing list > koffice@mail.kde.org > To unsubscribe please visit: > https://mail.kde.org/mailman/listinfo/koffice
This need is fulfilled by strigi now.