Display OpenOffice Writer files inline with odt2txt]

Display OpenOffice Writer files inline with odt2txt]

[JJ]

Hi everybody:

In line with my experiments with antiword, I'd like to use odt2txt to
display OpenOffice Writer files inline in an Article buffer.

Using the setup:

(add-to-list 'mm-inlined-types "application/vnd.oasis.opendocument.text")
(add-to-list 'mm-inline-media-tests
	     '("application/vnd.oasis.opendocument.text"
	       (lambda (handle)
		   (mm-inline-render-with-stdin handle nil "odt2txt"))
	       identity))

doesn't work, as odt2txt doesn't work with standard input, i.e. `odt2txt
file.odt' works, but `cat file.odt | odt2txt' just displays odt2txt's
help which is what gets displayed inline when using the above setup.

I'm not sure how to pass the mime attachment directly to odt2txt and not
through standard input as mm-inline-render-with-stdin seems to be doing.

Further, using this:

(add-to-list 'mm-inlined-types "application/pdf")
(add-to-list 'mm-inline-media-tests '("application/pdf"
				      (lambda (handle)
					(let ((f (make-temp-file "mime-part" nil ".pdf")))
					  (mm-save-part-to-file data f)
					  (find-file f)))
				      identity))

I can display pdf files inline, in a new buffer, using doc-view, so was
thinking along the lines of having also a temp buffer/file for this and
passing it on to odt2txt, but don't know how to do this with an external
program, in this case odt2txt, instead of, as above, with an elisp
function.

Can anyone advise on a workable setup?
-- 
JJ

Re: Display OpenOffice Writer files inline with odt2txt]

[Andreas Schwab]

"JJ" <ding_gnus.org@sumou.com> writes:

> Using the setup:
>
> (add-to-list 'mm-inlined-types "application/vnd.oasis.opendocument.text")
> (add-to-list 'mm-inline-media-tests
> 	     '("application/vnd.oasis.opendocument.text"
> 	       (lambda (handle)
> 		   (mm-inline-render-with-stdin handle nil "odt2txt"))
> 	       identity))
>
> doesn't work, as odt2txt doesn't work with standard input, i.e. `odt2txt
> file.odt' works, but `cat file.odt | odt2txt' just displays odt2txt's
> help which is what gets displayed inline when using the above setup.
>
> I'm not sure how to pass the mime attachment directly to odt2txt and not
> through standard input as mm-inline-render-with-stdin seems to be doing.

Have you tried mm-inline-render-with-file?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Display OpenOffice Writer files inline with odt2txt]

[JJ]

> "Andreas Schwab" <schwab@linux-m68k.org> writes:
>
> Have you tried mm-inline-render-with-file?

I can't do it, if I just substitute mm-inline-render-with-file for
...-render-with-stdin, I get the odt2txt help text displayed inline.

I figured I need to create a temp buffer as a file and pass it to odt2txt
with ...-render-with-file. That's why I mentioned in my original mail the
setup I have for creating temp buffers for pdf.

But I can't figure out how to merge both approaches, create a temp file,
and pass it to odt2txt with ...-render-with-file or whatever, to have it
parsed inline...

Any ideas?
--
JJ

Re: Display OpenOffice Writer files inline with odt2txt]

[Leo]

On 2010-07-15 19:29 +0100, JJ wrote:
> I can't do it, if I just substitute mm-inline-render-with-file for
> ...-render-with-stdin, I get the odt2txt help text displayed inline.

If you get the help text it possibly means you are not using dt2txt
correctly. Anyway you can use mm-save-part-to-file to save to file and
go from there.

Leo

-- 
Any Emacs contains an ad hoc, informally-specified, bug-ridden, slow
implementation of half of Common Lisp.

Re: Display OpenOffice Writer files inline with odt2txt]

[JJ]

On Tue, 20 Jul 2010 06:24:56 +0100, Leo <sdl.web@gmail.com> wrote:
> If you get the help text it possibly means you are not using dt2txt
> correctly. Anyway you can use mm-save-part-to-file to save to file and
> go from there.

Well, the fault is with odt2txt, in that it's not able to work with
standard input. That's how the text gets passed to it. So unlike antiword
for instance, when you:
antiword file.doc
cat file.doc | antiword -

you get the same output, i.e. the file is parsed. However with odt2txt
with:
odt2txt file.odt

the file is parsed. However with:

cat file.odt | odt2txt -

you just get odt2txt help text.

I'm not up to rewriting odt2txt source to enable standard input.

I'll try experimenting with mm-save-part-to-file, so that it could then
perhaps be submitted to odt2txt...
-- 
JJ

Re: Display OpenOffice Writer files inline with odt2txt]

[Dan Christensen]

JJ <ding_gnus.org@sumou.com> writes:

> I'm not up to rewriting odt2txt source to enable standard input.

Save these four lines to a file called odt2txt-stdin in your path, make
it executable, and use it instead:

#!/bin/sh
TMPFILE=`tempfile`
cat > $TMPFILE
exec odt2txt $TMPFILE

Dan

Re: Display OpenOffice Writer files inline with odt2txt]

[JJ]

JJ writes:

> Would anyone know how I can modify maybe mm-inline-renden-with-stdin or
> what-have-you, so
>that multibyte text in the word files would be displayed properly?

So this was easier than I thought indeed, just replacing
mm-with-unibyte-buffer with mm-with-multibyte-buffer works fine... Duh...
-- 
JJ

Re: Display OpenOffice Writer files inline with odt2txt]

[JJ]

Dan Christensen <jdc@uwo.ca> writes:

> Save these four lines to a file called odt2txt-stdin in your path, make
> it executable, and use it instead:

This works great, thanks a lot, now the odt document displays inline
fine.

The only problems I have remaining are with the fact that  when the file
has multibyte text, it winds up weirdly
malformed. I.e. for UTF-8 characters, they end up looking like:

\303\210\303\241

I've inspected mm-inline-render-with-stdin and yes,
it uses unibyte buffer processing to display the file. I've noticed that
mm-inline-render-with-function  enables multibyte stuff.

Would anyone know how I can modify maybe mm-inline-renden-with-stdin or
what-have-you, so
that multibyte text in the word files would be displayed properly?
-- 
JJ