Hi Jan!
On Sun, 04 Jul 2004, Jan Hudec wrote:
> Package: transfig
> Version: 1:3.2.5-alpha5-1
> Severity: normal
> I have ran across a case, where an image created in transfig fails to
> export to anything. The dimensions are computed incorrectly (as large
> negative numbers). If it's saved as postscript, ghostscript refuses to
> interpret it. If it's saved as encapsulated postscript, an insanely big
> box is shown. If it's saved as metapost source, metapost complains about
> too large numbers. I attach the .fig that shows this problem (it's not
> trivial and unfortunately I don't have time to test it more just now).
On Sun, 25 Dec 2005, Paolo wrote:
> how did you create that .fig? it certainly breaks something since the
> 2 polylines:
>
> 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 3
> 0 0 1.00 60.00 120.00
> -2147482832 -2147482672 -2147482752 -2147482752 -2147482672
> -2147482832
> 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 3
> 0 0 1.00 60.00 120.00
> -2147482832 -2147482672 -2147482752 -2147482752 -2147482672
> -2147482832
>
> have points outside range. Actually, that .fig makes xfig crash with ssegv
> when trying <Ctrl-z> (fit-to-canvas) - so your broken .fig triggers another
> bug in xfig.
>
> I think the conversion utilities are right, as they try to fit those points
> into the page-space, but those numbers just overflow interpreters for
> the corresponding formats (eg gs).
>
> So the point/bug is in: how did you manage to set those huge point
> coordinates? guess the bug is in xfig.
I also think, that this isn't a bug in transfig but in the program,
which created this .fig file.
As Jan didn't tell us how he created this .fig file, I'll close this
bug report now. Feel free to reopen it and reassign it to the
program, which created this broken file.
Tschoeeeee
Roland
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
