Max Alekseyev wrote:
Neither of these corresponds to a bug.
I cannot agree with this statement.
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.
Concerning 1a.dot, when you run dot, it uses fontconfig to resolve
fontname="freefont/FreeSans" to some font on your machine,
as dot needs to be able to compute text sizes. Note, by the way, that
the font found may be nothing like the one you expected.
On output, the -Tps option produces PostScript which will use the
fontname you specified:
/freefont/FreeSans set_font
It is up to the user to ensure that the PostScript machine used to
view the file can resolve that font name.
In 1a.log I see
neato: fontname "freefont/FreeSans" resolved to: "DejaVu Sans, Book"
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
So, the font name was resolved OK but it does not come up in ps when I
view it.
What can be a reason?
See below and my remark just above.
This is potentially a problem with any output format, such as ps, pdf
or svg, that allows certain resources to
be resolved by the rendering platform. This was a real headache for
program committees when the ps or pdf
of submitted papers couldn't be viewed because the fonts relied on by
the author were not available to the
committee members. This also means that some PostScript that can be
viewed fine using ghostview won't work when sent to a printer.
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.
Keep in mind we are discussing a system whose crucial controls are all
string-based, not keyword-based. so that simple typos like
lable="abc | {def | ghi }"
pass through without comment while crippling the user's output. Talk
about lack of warning messages.
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.
As for 2.dot, the output in 2.ps is correct and displays fine using
ghostview. I'm guessing you tried to view it using ghostscript
or some other tool which only renders the lower left corner of the
drawing, which is indeed blank. The drawing is large,
about 5 feet by 7 feet (and actually quite attractive), with
everything in the middle.
I'm not that stupid. ;)
Stupidity doesn't necessarily have anything to do with it. I have done
this and similar things many times.
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.
btw, you are referring to 2.ps from my neato_ps_bug.zip, aren't you?
not the one generated by yourself?
I never generated the graph myself. I just used the content of your zip
file.
Emden
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
