Hello, I have one question.
I really like Asymptote and already used it several times to create figures for some papers.
One of the great advantages of it -- is the possibility to use TeX formatted formulas for labels.
But I have a problem with EPS files produced by Asymptote:
- if I include some TeX formula into the figure a lot of EPS and DVI viewers do not show the picture at all. These includes gsview32, yap on windows, okular, kdvi on Linux. The only program that able to show at least something (usually with terrible artifacts) is kghostview.
PDF file produced after one uses ps2pdf of dvipdf is ok.
As far as I understand this problem is not very important -- most of people incorporate their asymptote code into TEX file and interested in resulting PDF files.
I have a complication with this -- my collaborators are pretty "inert" in a sense of switching to "new technologies" and they don't like my "wrong" EPS pictures.
For now I'm using eps2eps to create previewable EPS files but the fonts in the result are really ugly.
Maybe someone can help me with my problem or at least give me some hint?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You forgot to post your example! Without seeing the asy file and the eps output., there's of course nothing we can do to help.
The eps output is probably best posted on a web site somewhere.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you must have some special problem, because with MikTeX 2.5, 2.6, 2.7 I have always been able to use asymptote to generate eps files with math formulas etc which I could view with gsview32 and yap. Fonts are included and show up perfectly, both in eps pictures generated by asymptote and in latex files which include pictures made by asymptote and included with the \includegraphics{} command. I think you should describe better your situation through some minimal example.
Maurizio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We had another similar report recently, and this time we received an eps file. :-)
The problem in that case (and from your description likely in your case as well) is that dvips was mistakingly configured to insert lines like this, even when no paper type is specified:
%%BeginPaperSize: Letter
/setpagedevice where
{ pop << /PageSize [612 792] >> setpagedevice }
{ /letter where { pop letter } if }
ifelse
%%EndPaperSize
The latest svn version works around this dvips configuration error (see the dvips info page) by enforcing a null paper size.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even with the latest svn version I notice that the dvips configuration in texlive 2008 is broken. The commented lines below show the (weak) explanation for this change as found in /usr/local/texlive/2008/texmf-config/dvips/config/config.ps
% In the past, the a4size and letterSize definitions did not set the
% page size, but we want to set it if we can so that ps2pdf can work
% properly. Here, a4 and a4size, and letter and letterSize, are
% identical, and we prefer the a4/letter names -- texconfig uses them.
Clearly forcing a page size on every application using dvips was the wrong solution.
Unfortunately, with texlive2008 out now the damage is already done so we are going to have to implement some kind of work around; perhaps even filtering the faulty dvips output. Even -t unknown doesn't work. Using -t nullsize works as long as nullsize isn't a predefine size configuration file but that generates a warning message, which we would have to discard.
It appears that the author of the above 4 commented lines didn't read the info page:
If your printers are configured to use A4 paper by default, the
configuration file (probably the global `config.ps' in this case)
should include this as the first `@' command:
@ A4size 210mm 297mm
@+ %%PaperSize: A4
so that `A4size' is used as the default, and not `A4' itself; thus, no
PostScript `a4' command is added to the output file, unless the user
explicitly says to use paper size `a4'. That is, by default, no paper
size PostScript command should be put in the output, but Dvips will
still know that the paper size is A4 because `A4size' is the first (and
therefore default) size in the configuration file.
Executing the `letter' or `a4' or other PostScript operators cause
the document to be nonconforming and can cause it not to print on
certain printers, so the default paper size should not execute such an
operator if at all possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The latest svn revision (3942) works around broken dvips configurations by
implementing a new dvips papersize called nopapersize (that works the way
a4size is supposed to, according to the info page). Please confirm is that solves your EPS viewing problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Followup: we have received confirmation from a user that the latest svn version does indeed solve the problem reported in this thread. This workaround will appear in tonight's release of version 1.61.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just changed nopapersize.ps to use letterSize/a4size to work with the current
MiKTeX version of dvips, which does not appear to support the DVIPSRC environment
variable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I have one question.
I really like Asymptote and already used it several times to create figures for some papers.
One of the great advantages of it -- is the possibility to use TeX formatted formulas for labels.
But I have a problem with EPS files produced by Asymptote:
- if I include some TeX formula into the figure a lot of EPS and DVI viewers do not show the picture at all. These includes gsview32, yap on windows, okular, kdvi on Linux. The only program that able to show at least something (usually with terrible artifacts) is kghostview.
PDF file produced after one uses ps2pdf of dvipdf is ok.
As far as I understand this problem is not very important -- most of people incorporate their asymptote code into TEX file and interested in resulting PDF files.
I have a complication with this -- my collaborators are pretty "inert" in a sense of switching to "new technologies" and they don't like my "wrong" EPS pictures.
For now I'm using eps2eps to create previewable EPS files but the fonts in the result are really ugly.
Maybe someone can help me with my problem or at least give me some hint?
You forgot to post your example! Without seeing the asy file and the eps output., there's of course nothing we can do to help.
The eps output is probably best posted on a web site somewhere.
I think you must have some special problem, because with MikTeX 2.5, 2.6, 2.7 I have always been able to use asymptote to generate eps files with math formulas etc which I could view with gsview32 and yap. Fonts are included and show up perfectly, both in eps pictures generated by asymptote and in latex files which include pictures made by asymptote and included with the \includegraphics{} command. I think you should describe better your situation through some minimal example.
Maurizio
We had another similar report recently, and this time we received an eps file. :-)
The problem in that case (and from your description likely in your case as well) is that dvips was mistakingly configured to insert lines like this, even when no paper type is specified:
%%BeginPaperSize: Letter
/setpagedevice where
{ pop << /PageSize [612 792] >> setpagedevice }
{ /letter where { pop letter } if }
ifelse
%%EndPaperSize
The latest svn version works around this dvips configuration error (see the dvips info page) by enforcing a null paper size.
Even with the latest svn version I notice that the dvips configuration in texlive 2008 is broken. The commented lines below show the (weak) explanation for this change as found in /usr/local/texlive/2008/texmf-config/dvips/config/config.ps
% In the past, the a4size and letterSize definitions did not set the
% page size, but we want to set it if we can so that ps2pdf can work
% properly. Here, a4 and a4size, and letter and letterSize, are
% identical, and we prefer the a4/letter names -- texconfig uses them.
Clearly forcing a page size on every application using dvips was the wrong solution.
Unfortunately, with texlive2008 out now the damage is already done so we are going to have to implement some kind of work around; perhaps even filtering the faulty dvips output. Even -t unknown doesn't work. Using -t nullsize works as long as nullsize isn't a predefine size configuration file but that generates a warning message, which we would have to discard.
It appears that the author of the above 4 commented lines didn't read the info page:
If your printers are configured to use A4 paper by default, the
configuration file (probably the global `config.ps' in this case)
should include this as the first `@' command:
@ A4size 210mm 297mm
@+ %%PaperSize: A4
so that `A4size' is used as the default, and not `A4' itself; thus, no
PostScript `a4' command is added to the output file, unless the user
explicitly says to use paper size `a4'. That is, by default, no paper
size PostScript command should be put in the output, but Dvips will
still know that the paper size is A4 because `A4size' is the first (and
therefore default) size in the configuration file.
Executing the `letter' or `a4' or other PostScript operators cause
the document to be nonconforming and can cause it not to print on
certain printers, so the default paper size should not execute such an
operator if at all possible.
The latest svn revision (3942) works around broken dvips configurations by
implementing a new dvips papersize called nopapersize (that works the way
a4size is supposed to, according to the info page). Please confirm is that solves your EPS viewing problem.
Followup: we have received confirmation from a user that the latest svn version does indeed solve the problem reported in this thread. This workaround will appear in tonight's release of version 1.61.
I just changed nopapersize.ps to use letterSize/a4size to work with the current
MiKTeX version of dvips, which does not appear to support the DVIPSRC environment
variable.
I just tracked down the source of the dvips misconfiguration in TeXLive:
http://www.tug.org/pipermail/tex-live/2007-June/013932.html
Since I know the author of that post I have emailed him about this. In the meantime, we have a workaround.