Ross Johnson wrote:
Marc Schwartz wrote:
I was under the impression that the image preview in 2.0.2 could be
generated even if no third party tools such as Ghostscript,
ImageMagick (convert) or similar were present on the system. That
OO.org provides its own image preview, though in this case, only the
bitmapped preview would be generated.
If the aforementioned tools were available a vector based EMF preview
image would be generated.
Does your correspondent's Linux have pstoedit, convert or gs installed?
I ran OOo 2.0.2 Writer via "strace -f" on my FC3 and looked at the trace
output after inserting an EPS image (which shows as a bitmap in writer).
As you've said here and previously, it first tried pstoedit, which isn't
on my system. It then tried "convert', which I do have, with the
commandline:
/usr/bin/convert -density 300x300 eps:- png:-
I then moved convert aside and reran the strace. This time it used gs to
do the conversion (to PNG).
Moving gs aside finally exhausts Writer's attempts to display a
bitmapped image. It gave up and displayed the generic frame as you
describe.
Ross
Hi Ross,
Thanks for the follow up.
I am having my correspondent check his installation. He has indicated
that he has GS and ImageMagick installed, so perhaps there is an
installation or $PATH issue. I will await his reply for next steps.
Thanks for your feedback on strace. I did the same thing here and can
confirm the behavior. Note again that this is now from FC5.
Here is some output from my first checking on 'pstoedit' and then from
checking for 'eps' output from strace:
$ strace -f oowriter 2>&1 | grep pstoedit
[pid 3183] access("/usr/lib/openoffice.org2.0/program/pstoedit",
F_OK) = -1 ENOENT (No such file or directory)
[pid 3183] access("/usr/kerberos/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/usr/local/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/usr/bin/pstoedit", F_OK) = -1 ENOENT (No such
file or directory)
[pid 3183] access("/bin/pstoedit", F_OK) = -1 ENOENT (No such file or
directory)
[pid 3183] access("/usr/X11R6/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/home/marcs/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/home/marcs/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3723] execve("pstoedit", ["pstoedit", "-f", "emf", "-",
"/tmp/svm4c.tmp"], [/* 46 vars */]) = -1 ENOENT (No such file or directory)
[pid 3183] access("/usr/lib/openoffice.org2.0/program/pstoedit",
F_OK) = -1 ENOENT (No such file or directory)
[pid 3183] access("/usr/kerberos/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/usr/local/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/usr/bin/pstoedit", F_OK) = -1 ENOENT (No such
file or directory)
[pid 3183] access("/bin/pstoedit", F_OK) = -1 ENOENT (No such file or
directory)
[pid 3183] access("/usr/X11R6/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/home/marcs/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3183] access("/home/marcs/bin/pstoedit", F_OK) = -1 ENOENT (No
such file or directory)
[pid 3741] execve("pstoedit", ["pstoedit", "-f", "emf", "-",
"/tmp/svm4d.tmp"], [/* 46 vars */]) = -1 ENOENT (No such file or directory)
So the above would suggest that the EMF based preview is only generated
when pstoedit is present. pstoedit is not present on my system, so this
of course fails and it goes on to try convert.
It is interesting to see just where it is looking for pstoedit,
including within the openoffice.org2.0 tree. Perhaps a hint of things to
come?
One key point of note, which is that according to the pstoedit web site:
http://www.pstoedit.net/
the emf/wmf formats are Windows only, which makes sense since the only
Linux based approach to generating such file formats is to use libemf,
which past experience has shown generates poor quality images.
Note also that GS is required to run pstoedit:
"You need a C++ compiler to compile and GhostScript to run pstoedit.
pstoedit should run on all Un*x like systems (including cygwin) and has
also been ported to OS/2, Windows 9x/NT/2K/XP, and RiscOS."
Nest step:
$ strace -f oowriter 2>&1 | grep eps
[pid 2814] lstat64("/home/marcs/test2.eps", {st_mode=S_IFREG|0664,
st_size=5949, ...}) = 0
[pid 2814] lstat64("/home/marcs/test3.eps", {st_mode=S_IFREG|0664,
st_size=3577, ...}) = 0
[pid 2814] lstat64("/home/marcs/eps", <unfinished ...>
[pid 2814] open("/home/marcs/eps", O_RDONLY|O_LARGEFILE <unfinished ...>
[pid 2791] access("/home/marcs/.local/share/mime/image/x-eps.xml",
F_OK) = -1 ENOENT (No such file or directory)
[pid 2791] access("/usr/local/share/mime/image/x-eps.xml", F_OK) = -1
ENOENT (No such file or directory)
[pid 2791] access("/usr/share/mime/image/x-eps.xml", F_OK) = 0
[pid 2791] stat64("/usr/share/mime/image/x-eps.xml",
{st_mode=S_IFREG|0644, st_size=589, ...}) = 0
[pid 2791] open("/usr/share/mime/image/x-eps.xml", O_RDONLY) = 37
[pid 2791] stat64("/home/marcs/test2.eps", {st_mode=S_IFREG|0664,
st_size=5949, ...}) = 0
[pid 2791] open("/home/marcs/test2.eps", O_RDONLY|O_LARGEFILE) = 37
[pid 2791] access("/home/marcs/test2.eps", F_OK) = 0
[pid 2791] lstat64("/home/marcs/test2.eps", {st_mode=S_IFREG|0664,
st_size=5949, ...}) = 0
[pid 2791] stat64("/home/marcs/test2.eps", {st_mode=S_IFREG|0664,
st_size=5949, ...}) = 0
[pid 2791] open("/home/marcs/test2.eps", O_RDONLY) = 37
[pid 2826] execve("/usr/bin/convert", ["/usr/bin/convert",
"-density", "300x300", "eps:-", "png:-"], [/* 46 vars */] <unfinished ...>
[pid 2826] stat64("eps:-", 0xbf870630) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf870630) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] stat64("eps:-", 0xbf86c550) = -1 ENOENT (No such file or
directory)
[pid 2826] open("./gs_epsf.ps", O_RDONLY) = -1 ENOENT (No such file
or directory)
[pid 2826] open("/usr/share/ghostscript/8.15/lib/gs_epsf.ps",
O_RDONLY) = 4
[pid 2791] stat64("/home/marcs/test2.eps", {st_mode=S_IFREG|0664,
st_size=5949, ...}) = 0
[pid 2791] open("/home/marcs/test2.eps", O_RDONLY) = 35
[pid 3101] execve("/usr/bin/convert", ["/usr/bin/convert",
"-density", "300x300", "eps:-", "png:-"], [/* 46 vars */]) = 0
[pid 3101] stat64("eps:-", 0xbfee7f80) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee7f80) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] stat64("eps:-", 0xbfee3ea0) = -1 ENOENT (No such file or
directory)
[pid 3101] open("./gs_epsf.ps", O_RDONLY) = -1 ENOENT (No such file
or directory)
[pid 3101] open("/usr/share/ghostscript/8.15/lib/gs_epsf.ps",
O_RDONLY) = 4
Here, ImageMagick's convert is present, so that is used to generate a
PNG based preview with a 300 dpi resolution. This in turn appears to
then call GS for final work.
It may be that the resolution of the preview image when using convert at
300 dpi is better than when using GS alone, which may be why we believe
that we are seeing better quality preview images. These in turn then
look somewhat better when exporting to PDF as per our prior discussion.
So it would seem (perhaps pending confirmation from someone at OO.org),
that the preview generating process is indeed dependent upon third party
apps even for the bitmapped preview.
I suppose that this is better than nothing, but it would be great at
some point if at least a basic preview generating capability was
embedded in OO.org. Each of the above programs is GPL and perhaps there
is an appropriate subset of functionality that can be distributed to
facilitate the previews without substantially increasing the size of the
OO.org distribution.
Thanks again Ross.
Regards,
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
