Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000693graphvizDotpublic2007-03-22 08:062011-04-28 04:03
ReporterRolf Schroedter 
Assigned Toerg 
PlatformOSx86-Windows-WinXP, SP2OS Version
Summary0000693: Graphviz, MiKTeX's epstopdf, and UNIX textfiles

I'm using Doxygen 1.5.1-p1 with MiKTeX 2.5 and Graphviz 2.12
under WindowsXP.

I noticed a really strange problem and I'm not sure whether it's Graphviz, MiKTeX (epstopdf) or a combination of both.
Here are the dry facts:
- With Graphviz 2.0 doxygen(epstopdf) runs fine without errors.
- With Graphviz 2.12 doxygen(epstopdf) crashes creating errors "/unknown in omments" foreach eps-file.

So far, I would would say that Graphviz 2.12 is wrong.

But the strange thing is that if the Graphviz 2.12 EPS-files are converted to DOS-style textfiles (unix2dos),
epstopdf is able to process them without any error.

I have post this problem also to the Doxygen & MiKTex folks...

Regards, Rolf.

To illustrate the problem, I'm attaching two files created by graphwiz 2.0/2.12 respectively.
Session log:
tmp $ which epstopdf
tmp $ epstopdf graphviz20.eps
tmp $ epstopdf graphviz212.eps
Error: /undefined in omments
Operand stack:

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-
- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- fa
lse 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3
%oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringva
l-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
   --dict:1123/1686(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
Current allocation mode is local
Last OS error: No such file or directory
MiKTeX GPL Ghostscript 8.54: Unrecoverable error, exit code 1
tmp $
tmp $ unix2dos graphviz212.eps
graphviz212.eps: done.
tmp $ epstopdf graphviz212.eps
tmp $

The 2.0 output is \<A HREF=""\>here\</A\>.
Additional Information

[erg] The only significant changes in the 2.12 graphviz output are:

  - we moved the BoundingBox info to the end
  - we removed unnecessary assignments to the Latin-1 encoding vector
  - we always use the Latin-1 encoding (it extends ascii)
  - we output PDF anchor information twice (which should be a harmless bug)

Since unix2dos fixes the problem, another question to ask is, What is the difference between the
versions of before and after unix2dos is run on it? Presumably that might help give
a better idea what is now upsetting epstopdf.

Another test, though I don't think this should affect anything, would be to remove the redundant PDF markings.
That is, get rid of one set of the lines
[ /Rect [ 273 0 337 20 ]
  /Border [ 0 0 0 ]
  /Action << /Subtype /URI /URI ($leon__idle_8h.html) >>
  /Subtype /Link
/ANN pdfmark

and then try running epstopdf.

[erg] I believe this is now fixed, though I still can't explain why the
2.0 output works and the 2.12 doesn't. Basically, when dot gets a -o
option, it was opening the file with fopen ("wb"), i.e., in binary mode.
This meant newline characters were not changed into
carriage-return-newline. Apparently, some epstopdf on windows expect the
latter. The code now opens the file in text mode.

[erg] It has been verified that MiKTeX EPS-to-PDF Converter 2.5.2574 (MiKTeX 2.5), for one, only accepts \r\n terminated lines. Given that the graphviz code
hasn't changed for a long time, I believe this is an error introduced into
TagsNo tags attached.
STATUS-COMMENTFixed (6 Sep 2007)
VERSION     2.12
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => erg

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker