[Prev][Next][Index][Thread]
Re: printing problems with E/L
Peer> Hi,
Peer> as I mentioned in a mail before my wife thinks about using
Peer> executor to run a cad program (By the way executor seems to
Peer> be fast enough to do something like that!).
Yes, we are fast, but still have many compatibility problems.
Peer> Yesterday I checked the printing capabilities. Here are the
Peer> results :-(
Printing is especially difficult because programs are free to
intersperse PostScript code with their QuickDraw calls and getting the
interaction correct is tricky.
Peer> - there is no color
This will not be fixed by the time 2.0 comes out.
Peer> - rotated text is not rotated in the printing
This has worked from some programs in the past. There is a standard
way to do it and we ostensibly support the standard. It could be that
this code broke somehow or it could be that the program in question is
doing something non-standard. I'm logging this to our bug tracking
database so we can look at it eventually.
Peer> - areas filled with a color (e.g. white) will not be filled
Peer> in the printout. The things located under the area become
Peer> visible.
We may be able to special case white. I wrote the original QuickDraw
implementation and the original printing implementation. Since then,
Cotton Seed and Mat have rewritten Executor to support color, but they
left printing alone. When we can all get together we'll see what we
can do.
Peer> - there are NaN's in the generated postscript. The
Peer> postscript generation process seems to have problems with
Peer> some calculations (I stripped the lines containing the NaN's
Peer> and got some output in ghostview)
If you can reproduce NaNs using any program that we are likely to have
(Word, Excel, shareware/demoware/freeware) then we should be able to
fix this fairly easily. I found and fixed one set of NaNs a while
ago.
Peer> - There is another error in the generated Postscript code:
Peer> there are many lines saying 0.000000 0.000000 0.000000
Peer> 0.000000 rectclip which means the clipregion has no
Peer> size. Therefore no drawing is visible If I change the zeros
Peer> to some `reasonable' values some of the lost elements become
Peer> visible.
This may also be a side-effect of the changes to QuickDraw that I
mention above. Again, if we can reproduce this, we have a much better
chance of fixing it.
Peer> - (Umlauts are not printed - this problem is known. But I
Peer> would like to say that it is neccessay for us to have
Peer> umlauts!)
This is very strange. So far I've been on the assumption that you're
using the latest version of Executor/Linux, but I'm pretty sure that
I've fixed this problem a while ago. Umlauts *should* print, although
right now they're next to impossible to generate via the keyboard.
Please check this with 1.99o5 and let me know if it's still broken and
what program you're using it from.
Peer> What are the plans of ardi in respect to printing? I hope
Peer> you will manage to eliminate all these problems! It would be
Peer> too bad if executor would not be usable for real world
Peer> problems because of such problems!
We should be able to eliminate most of the problems you have
described. Full support for color printing won't be there for 2.0,
but hopefully we can at least get white to erase things. Perhaps some
of the problems really are already fixed (I thought I had fixed the
NaNs, rectclips and Umlauts already).
Peer> connection reset by Peer
Peer> P.S I did not get any response to my last mail concerning
Peer> the problems with RagTime, Excel and Word. Did you receive
Peer> my mail? Or am I simply too impatient ;-)
We have been very shorthanded in August and this first week of
September will be slightly worse as Mat is out of the office until
Thursday or Friday. By now I've replied to that letter, although I
don't think I cc'd my reply to the Executor mailing list.
--Cliff
ctm@ardi.com