Chronological Thread 

< Chronological >      < Thread >

---

Henri Lesourd wrote:

Luca wrote:

Last time it happened to me (around December 2005) Henri suggested that it was a problem related to the pdf dialect produced by gnuplot on a Mac.

It seems that TeXmacs has problem with recent / a little bit
non standard versions of Pdf files.

Now I have an eps file produced on a Linux box by Xfig.

It seems that this eps file is not correct / not correctly
understood by TeXmacs. The solution to your problem is
to clean it by means of the 'eps2eps' command, for example :
<<
/home/henri>eps2eps box.eps box2.eps
/home/henri>_
>>

And then, use 'box2.eps' instead of 'box.eps' in your .tm file.


But this remains a workaround around the current bug. There are two
possible reasons to this bug :

a) The eps dialect generated by Xfig is not completely clean (which
is possible, if your version of Xfig is recent) ;

b) The eps dialect generated by Xfig is more recent than the one
understood by TeXmacs (which is the most probable given the
current informations) ;

So summarizing I think it is a very malicious bug,

Yes, it is really annoying, because we somehow depend on what
other software do, and must probably update TeXmacs to have
it understand more recent dialects of eps, pdf, etc.

It make me feel insecure whenever I have to write something serious that
1) I won't be able to print it
2) I won't be able to export and send my work to other people that don't use Texmacs.

You can (and should) **check** that the exported .pdf or .ps
file can be correctly viewed in Ghostview.

Don't trust the computer ! This is a general part of the knowhow
of computer users that is not likely to cease being useful in a
foreseeable future... (of course, it doesn't change the fact that
software with less bugs is better ;-).

This is not exactly the feeling one should have when using a WYSIWYG editor isn' t it?

No. The fact is that we rely (perhaps a little bit too much ?) on
TeXmacs users have some skills in hacking and using UNIX commands.

On the other hand, it is important to observe that in most of other
WYSIWYG editors, which rely either on binary formats, or on unreadable
XML dialects (in this latter case, the situation remains crappy, but
not completely hopeless), when one file is corrupted, you loose all
your content, with really, very few hopes of recovering your work.

If you use TeXmacs, when such problems occur, there is always a
way to recover most of your work by hacking a little bit the markup,
whether it is from inside TeXmacs, or from inside emacs, for the
more severe cases.

Proposed Solutions and work around:
1) find out the bug. (I am sorry but I am not skilled enough to do this)

We will have to solve it, for sure.

2) Using the graphic package of Texmacs (This is not my case as for me the package is unusable do to slowness and unresposivness of the cursor inside the graphic environement. I had already commented on this issue on a previous message on the list)

It depends if the root cause of the slowness is your computer or if it is
because you tried the graphics package in a time when speed problems were
not well solved (I remember that it took some struggle to find a way to improve
this sufficiently well). The TeXmacs version you are using is a very recent
one, perhaps should you try the graphics package again, just to see if, perhaps,
it would work correctly now...

3) getting a way to check if the figure will appear in the final output and warn.
The manual way is the one I used that is export to pdf each time you include graphic to check...
(At least one could save a lot of time switching immediatly to latex)

This is very easy : do File->Export, and then look at your file
with Ghostview or Acrobat reader.

But I understand that with a big file, this is not practical : you
would have to remove bit after bit, till you discover which part
of the document is the offending one (this is indeed the general
method one can use to diagnose bugs in TeXmacs files).

Hope this helps and thank you for the effort to improve Texmacs.

Anyway, thank you for having took care of sending this
mail, it will appropriately remind us that perfection
is not yet reached, and that in order to start the long,
long way which allows to reach it, we could start (why
not ?), by solving this bug :-)...


Best, Henri

Hi Henri, just 2 comments:
1) regarding the graphics package
I just tested yesterdays the graphic package to see if I could reproduce the little plot I made in Xfig directly inside texmacs.
But I still have the slowness problem.
It is slow when I start to move the mouse, if I move it at constant speed then the cursor starts to follow after a while.
So it is very difficult to place it in a precise way.
If there is some test you want me to do to track where the slowness come from I am very happy to help.
2) Problem with figures:
Would it be possible to implement as a default some class of filter through programs like eps2eps in order to "purify" and "certify" images before inserting them into a Texmacs document?
I.e. I would like to link figure.eps
The purified image
could be produced through (as you suggests) eps2eps figure.eps figure_t.eps
The obtained image could have a slightly different name.... i.e. figure.eps --> figure_t.eps (so we prevent accidental damage of the original figure).
The obtained file i.e. figure_t.eps is the image that is linked in the Texmacs document.
In case the purification fails there could be a warning in the status bar saying that the image is linked in an insecure way (the original image is linked) and that this could create problems when printing.

In this way one could only include "certified" graphics inside Texmacs in a secure way and include all others with warnings...
What do you think about this?
THank you again and
REgards Luca

---

• Bug in the conversion, Luca, 06/14/2006
  • Re: [TeXmacs] Bug in the conversion, Henri Lesourd, 06/14/2006
    • Re: [TeXmacs] Bug in the conversion, Luca, 06/15/2006
      • Re: [TeXmacs] Bug in the conversion, Henri Lesourd, 06/17/2006

---

Archive powered by MHonArc 2.6.19.