Just thought I'd add that shortly after sending that last message,
upstream forwarded me the patch (as I requested in the bug report). It
was identical to the one I already posted, with the exception of also
changing the CVS header at the top of the file (which I explicitly
removed from my diff).
Francis Russell wrote:
> So, this bug has been acknowledged and apparently fixed upstream:
>
> http://www.graphviz.org/bugs/b1902.html
> http://www.graphviz.org/bugs/b1903.html
>
> I've attached a diff I made of the changes to lib/common/output.c from
> upstream CVS. I believe the fix only touche
So, this bug has been acknowledged and apparently fixed upstream:
http://www.graphviz.org/bugs/b1902.html
http://www.graphviz.org/bugs/b1903.html
I've attached a diff I made of the changes to lib/common/output.c from
upstream CVS. I believe the fix only touches this file although CVS
makes this r
David Claughton wrote:
> The odd thing is, the only time the problem manifests itself is when the
> file is output in dot format (i.e. without a -T switch). When a
> -T option is passed the output always seems to look OK.
My own investigation into the graphviz source seems to indicate that
lib/c
Francis Russell wrote:
> monotone-viz uses dot to lay out its graphs. Specifically, it passes the '-q
> -y -s72' options to dot, but it's
> only the '-y' option that's broken. I intercepted the input of dot and
> created the attached test file
> dot-in.dot. Running though 'dot -y' creates a dot
Package: graphviz
Version: 2.26.3-2
Severity: normal
I believe this problem started with the recent migration of graphviz into
testing. It is a problem with dot,
but I mention monotone-viz as it is particularly effected by it.
monotone-viz uses dot to lay out its graphs. Specifically, it passes
6 matches
Mail list logo
