Dear Emden,
I am forwarding my reply to your message to bug # 469416 at Debian Bug Tracking
system.
Please cc to [EMAIL PROTECTED] (instead of [EMAIL PROTECTED]) any further
messages on the topic.
Thanks,
Max
-------- Original Message --------
Emden R. Gansner 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).
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?
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.
The other solution is to have the generated PostScript contain all of
the necessary font glyphs. The output tends to be
messier and much larger, but it is self-contained. This can be done
using the Cairo backend:
dot -Tps:cairo
dot uses Cairo to produce pdf, which is why your pdf output was okay.
Thanks for this information.
I will try it out.
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. ;)
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?
btw, you are referring to 2.ps from my neato_ps_bug.zip, aren't you? not the
one generated by yourself?
Thanks,
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
