Discussion:
Coauthors that use Scientific Word
Matt Cole
2014-10-20 15:12:19 UTC
Permalink
Hello all,

I have WinEdt 7.1-64 bit and Windows 8

I have a couple potentially related questions (that are hopefully not off
topic for this board):

1. I have several co-authors that are insistent on using S.W. So far we
have been able to get along (I need to have a couple files in my directory
like tcilatex.tex and I generally comment out figures when they are working
on the version). The one thing that I can't seem to fix but find incredibly
annoying is that SW has a very narrow word-wrap mechanism using hard
returns and sometimes % symbols at the end of the line. Is there someway
WinEdt can easily "fix" this after I open a document that has been
"infected" by SW?

2. Any other advice from people who have had to work with people using SW
would also be appreciated.

3. My typical compiling method is to go a DVI and then later convert to a
PDF. For some reason my figures look good in the DVI, but then are shifted
down into the text when I convert to a PDF. I've found a work around and it
seems to be fine if I go DVI->PS, then PS->PDF. This wasn't an issue in the
past (even with people who use SW), so maybe I need to upgrade my WinEdt?

Thank you for any help!

Best,
-Matt
WinEdt Team
2014-10-21 16:12:55 UTC
Permalink
Matt,
Post by Matt Cole
I have a couple potentially related questions (that are hopefully
1. I have several co-authors that are insistent on using S.W. So
far we have been able to get along (I need to have a couple files
in my directory like tcilatex.tex and I generally comment out
figures when they are working on the version). The one thing that I
can't seem to fix but find incredibly annoying is that SW has a
very narrow word-wrap mechanism using hard returns and sometimes %
symbols at the end of the line. Is there someway WinEdt can easily
"fix" this after I open a document that has been "infected" by SW?
There is no easy fix for this. One would have to analyze the source
produced by SW and see which comments can be safely removed and
which portions can be safely reformatted (in soft or hard wrapping
mode). Then one could either write a pre-processor that pretty-fies
SW source (or perhaps a WinEdt macro that does the same). I never
used SW and since this is not particular to WinEdt it is up to TeX/
SW community to provide such accessory (or even better have SW
produce a TeX source that is suitable for human editing)...
Post by Matt Cole
3. My typical compiling method is to go a DVI and then later
convert to a PDF. For some reason my figures look good in the DVI,
but then are shifted down into the text when I convert to a PDF.
I've found a work around and it seems to be fine if I go DVI->PS,
then PS->PDF. This wasn't an issue in the past (even with people
who use SW), so maybe I need to upgrade my WinEdt?
Upgrading WinEdt will not change anything since WinEdt simply
executes dvipdfmx.exe accessory that comes with your TeX system.
Many users complained directly to me about the misaligned images in
pdf file produced this way. Unfortunately WinEdt has nothing to do
with this and I am not aware of any solution other than abandoning
dvi->pdf conversion...

This is what I advise users that encounter this problem. Some heed
the advice, many settle for dvi->ps->pdf, and others wait for a
solution from somewhere:-)
Post by Matt Cole
When I attempt dvi→pdf from the WinEdt menu bar the resulting pdf
file is corrupted, but in a strange way. See the attached pdf file.
dvipdfm.exe converter is a part of MiKTeX. You can execute it from
WinEdt or from command prompt and the result will be the same: this
converter cannot always properly convert eps graphics and in your
case it fails quite miserably. Nothing WinEdt can do about this I
am afraid.
At first look it seems the same as the dvi file but take a look,
please, at figure 2 on page 4, figure 4 on page 5, figures 5 and 6
on page 6. Each is down-shifted with respect to the accompanying
figure caption. (Oddly, this did not happen for figures 1 or 3.) I
am using Adobe Acrobat Pro (11.0.08) which is the latest version.
Inasmuch as the dvi file is correct I don’t think I can be misusing
a latex command for the placement of the figures.
No the problem is that you are using obsolete (non-pdf compatible
eps graphics) and that's why you need to create dvi file and then
convert it to pdf using dvipdfm.exe accessory. This converter has
limited capability of handling graphics or postscript specials
which have to be converted to pdf using Ghostscript that comes with
MiKTeX.
The original figures are all in eps format.
This is the source of the problem. If your final aim is to create
pdf documents then you should create png or pdf graphics (instead
of eps) and then use PDFLaTeX to compile a document. There are
(free) programs that can convert eps to pdf or png if your software
can only generate eps graphics.
When I try to print to pdf from the YAP previewer I get the message
: “METAFONT mode mismatch.” whatever that means. It also says,
under the “Data” box: “1200X600”, whatever that means.
That's interesting but YAP is a part of MiKTeX and this is not the
right place to report YAP-related problems. FYI YAP, too, has a
limited ability of handling eps graphics and postscript.
I also have CutePDF Writer on my PC, which is a kind of competitor
to Adobe. When I print to pdf from YAP with it the figures are
located in the correct positions, but the overall quality of the
document is so poor as to be nearly illegible.
dvi format is obsolete and you would be much better off if you heed
my advice and create pdf directly (but first you will have to
convert your eps figures to png or pdf).
I would much prefer to be able to print to pdf from within WInEdt,
using Adobe Acrobat Pro, but it looks to me like there is a problem
in the “handshake” between the two programs, WinEdt and Acrobat
Pro.
There is no handshake between WinEdt and the pdf viewer of your
choice (there never was any).
You cannot print pdf files from WinEdt. Any respectable pdf viewer
can print them for you but first you have to create pdf file that
is not corrupted by your conversion method.
If you could possibly help me solve this problem I would be ever so
grateful. For a couple of decades, now, I have been very happy with
the WinEdt/YAP/Adobe tandem and I would like it to continue.
YAP is not really supported any more. If you insist on using
obsolete eps graphics try alternative: dvi->ps and then ps->pdf.
This is usually more reliable conversion than dvi->pdf (although
still not a very efficient way to go).
I should say, the problems started when I got a new PC a couple of
months ago. But I am using the same Windows 7 operating system that
I used on my previous computer, with which I had no such problems.
Perhaps you have a different version of MiKTeX or Ghostscript on
the new computer (WinEdt is irrelevant to any of this).
Most users these days create pdf files directly (eg. via PDFTeXify)
and use SumatraPDF as a working pdf viewer because it supports
forward and inverse search based on synctex technology (way better
than YAP's). Converting graphics to png or pdf (once and forever)
also makes compilation faster. Otherwise they have to be converted
every time you run dvi->pdf and as you observed this converter
(dvipdfmx.exe) cannot properly handle your graphics anyway...
Thank you for any help!
Well perhaps not what you wanted to hear but this is how things
stand at the moment. I am not sure if there is any work going on of
dvipdf converter or if any fixes are planned for the future...

Best regards,

alex

Loading...