Re: XyWrite Development

[Carter Campbell campbelc@xxxxxxxx]

April 6, 1995

Dear Mr. Frank;

I am extremely glad to hear that you are not going to be dropping
development on the DOS version of XyWrite and if I have
misunderstood some of the statements you have posted in this
list, I hope you will accept my sincere apology.

However, I am certain you can imagine my dismay at reading your
posting of Sunday, March 26, 1995; 19:56, stating ". . .there are
no longer enough customers for DOS products to support the cost
of continued development. . ." (Since Annie has beaten me to the
quote, I won't bother reposting it in its entirety; Thanks Annie.
:-) ). When
I read this, especially in light of the ongoing discussions at
the time, I felt as if a close and dear friend had been diagnosed
as terminal (the condition, not the hardware). If I have somehow
misconstrued the meaning of the above post, again, I apologize.

     KF>In fact we recently released another interim
     KF>upgrade of DOS,. . .

Which version would this be? I recently upgraded to Version
4.016.
Is there a maintenance release after this? If so, what are the
updates/bug fixes that have been implemented?

     KF>I acknowledge that there are some problems with
     KF>Orbis, and we have re-written that module and
     KF>will shortly be begin a Beta test.

Excellent! Please let me know when this is up and running. I
have a definite need for this utility.

     KF>I do not think Xy4 is fragile; if there are
     KF>particular problems all I can ask you to do is
     KF>let us know what they are so we can look into
     KF>them.

Most definitely, I will. I have tried to do so in the past, but
nothing I sent was ever acknowledged and I was never informed
about the current state of the product. This lead me to believe
that nothing was being done and that there were no fixes in the
works.
Because of this, I stopped sending in my findings. Now, with
this list, information could be disseminated easily, so I will
begin again.

As for the bugs themselves, I have experienced similar troubles
to those that Harmon has been finding. For example, I have had
the following troubles:

* There seems to be a problem with snaking columns and page breaks.
 When I try to force a page break in the middle of a snaking column,
 either by moving the position of the column or by putting the page
 break in the middle of the column, the programme (editor.exe) locks
 up. This happens when I am in graphics view. Before the programme
 locks up, the screen is painted with four wide, blank stripes and
 then the computer hangs.

* The clock display at the top of the screen (on the command line)
 sometimes freezes and won't update unless a command is used from the
 command line, or  or  is pressed with an empty command
 line. This is very minor, but can be annoying.

* If I am editing a file in graphics view, after a random period of
 time, the programme will not update the screen any more. By this I
 mean that it will not show when I have deleted, inserted, or
 modified the text in any way. If I cause the screen to refresh by
 paging down or up, then the modification becomes evident. Switching
 views has no effect, the screen must be updated in graphic view.

* Sometimes, again at random intervals, the screen blows up and I have
 to switch between view modes for a while (for a random amount of
 time) before the screen comes back to something I can read. When I
 finally do get my screen refreshed and working, the command line
 looks as follows:

         ≪MDRV≫≪RM255≫C:\..\XY4≪MDNM≫

 This happens in every view mode the system can produce.

* The DIR command still cannot display directory listings using the
 parent directory (..\) in the path. If I want to display a
 directory that is three parent directories up and one child
 directory down (i.e. ..\..\xy4), I am given a screen full of
 garbage. The only way to display a directory that is more than one
 parent up is to type in the directory's absolute path.

For me, I use the graphics mode quite a bit, so some of the
difficulties I face are located there.

     Our hands are somewhat tied on the graphics
     filters since they come from Inset, and we have
     little control over them. If there is a
     particular deficiency, we will be happy to take it
     up with Inset.

Yes, first and foremost, there is no provision for GIF graphics.
You have based your graphics inclusion on TIFF, which seems to
have as many variations on the "standard" as colours in a
rainbow. I find that the most common graphics format is the GIF
standard and, because of that, I thought it might be a good idea
to shift your base graphics format to that.

If that is really not an option, it would be nice to be able to
include graphics that are at least grey-scale and not just black
and white. There are third party filters out there, such as Graphics
Display System (GDS), but they do not convert the image to a flat
black and white picture.

In any case, thank you for your reassurance and attention on this
matter.

   Carter Campbell
   campbelc@xxxxxxxx
   carterc@xxxxxxxx