[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