Emden R. Gansner wrote:
If no error/warning is produced by an application and the result does
not look as expected, a user has no idea of what went wrong.
Therefore, this is a buggy behavior even if there exists a simple
fix/workaround (of which the user is unaware).
Well, if you are submitting a bug report about this, then you need to
submit one for dvips, latex, tcl, the C compiler, javac,
and anything other software system that allows you to create software
that's meant to run in another environment and relies
on that environment having additional, separately supplied resources.
Relying on the additional, separately supplied resources is not harmful.
But silently ignoring the absence of *necessary* resource is, especially when
such behavior produces an incorrect result.
But I should be issued at least a warning that some font cannot be
found or something like that.
I do not see any such warnings. Everything looks like perfectly
working while it does not.
At the time dot is run, there is no way to know whether or not the font
will be available when someone renders
the postscript file. The best we could do is emit a warning whenever we
generate postscript containing a non-standard postscript font name,
but then what do we do about svg where there are only 3 standard font
names? Any real-life dot file being converted
into svg is going to contain a non-standard font name, so we would end
up always writing annoying and meaningless warning messages.
This can be controlled by a special option and be off by default.
There are cases (like this one) when such warnings are truly important.
There is a complementary problem/complication. Graphviz uses fontconfig
to resolve your font name. It always returns some font, but
we have no way of knowing if it found the font you wanted or anything
close to it. You could, say, supply a valid font name for one of the
extra fonts provided with ghostscript, but unless everything was set up
correctly for fontconfig, it might use something totally different.
In this case, you can't win. If you use -Tps:cairo, the text wouldn't
look the way you wanted. If you use -Tps, the sizes would be
incorrect.
I've got it. But I need to understand a reason of the current behavior.
It is possible that graphviz's output is perfectly valid and it has nothing to
with this bugreport, but in this case something wrong is with ghostscript (or
its debian installation) and this bugreport needs to be moved over to it.
I scrolled 2.ps in gv (ghostview with X11 interface) interbut it shows
absolutely nothing here. The picture (which is quite large indeed) is
shown empty. And no any errors or warnings again.
Moreover, Gnome Ghostview (ggv) simply says that 2.ps is not a valid
PostScript file. And I'm really confused by this claim.
What can be a reason for that? Why do you see the content of 2.ps
while I don't?
When I run ggv 2.8 on the file, it takes a while but displays fine, with
no warnings.
Similarly, gv 3.5.8 also displays your 2.ps fine. I haven't tried evince.
I have no idea why my versions of gv and ggv work on your file, and
yours don't.
Since they all use Ghostscript in one way or another, let's check possible
differences
between our installations.
My Ghostscript's version is:
GPL Ghostscript 8.61 (2007-11-21)
and it processes 2.ps as follows:
$ gs -dNOPAUSE -sDEVICE=png256 -sOutputFile=temp.png -dBATCH 2.ps
GPL Ghostscript 8.61 (2007-11-21)
Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Loading NimbusRomNo9L-Regu font from
/var/lib/defoma/gs.d/dirs/fonts/n021003l.pfb... 2747096 1312855 2226936 926661
2 done.
Loading NimbusRomNo9L-ReguItal font from
/var/lib/defoma/gs.d/dirs/fonts/n021023l.pfb... 2884336 1450466 2347512 1044651
2 done.
Loading NimbusRomNo9L-Medi font from
/var/lib/defoma/gs.d/dirs/fonts/n021004l.pfb... 3008052 1589335 2347512 1046791
2 done.
Loading NimbusRomNo9L-MediItal font from
/var/lib/defoma/gs.d/dirs/fonts/n021024l.pfb... 3125196 1710964 2347512 1049059
2 done.
Loading NimbusSanL-Regu font from
/var/lib/defoma/gs.d/dirs/fonts/n019003l.pfb... 3222244 1826571 2347512 1051495
2 done.
Loading NimbusSanL-ReguItal font from
/var/lib/defoma/gs.d/dirs/fonts/n019023l.pfb... 3319292 1927030 2347512 1053635
2 done.
Loading NimbusSanL-Bold font from
/var/lib/defoma/gs.d/dirs/fonts/n019004l.pfb... 3416340 2029516 2347512 1055885
2 done.
Loading NimbusSanL-BoldItal font from
/var/lib/defoma/gs.d/dirs/fonts/n019024l.pfb... 3493292 2127494 2347512 1058025
2 done.
Loading NimbusMonL-Regu font from
/var/lib/defoma/gs.d/dirs/fonts/n022003l.pfb... 3630532 2258983 2347512 1060165
2 done.
Loading NimbusMonL-ReguObli font from
/var/lib/defoma/gs.d/dirs/fonts/n022023l.pfb... 3667292 1995719 2367608 681887
2 done.
Loading NimbusMonL-Bold font from
/var/lib/defoma/gs.d/dirs/fonts/n022004l.pfb... 3764340 2127772 2367608 684027
2 done.
Loading NimbusMonL-BoldObli font from
/var/lib/defoma/gs.d/dirs/fonts/n022024l.pfb... 3881484 2253263 2367608 686167
2 done.
The resulting file temp.png is of size 2908 bytes and contains a white
rectangle (of size 612x792).
Could you please check what happens in your system?
Regards,
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
