BUGS
====

The following is a list of known bugs, problems and/or peculiarities 
known to me at the time of release.  Some of the bugs are really
problems that stem from the fact that I simply did not have time to
correct or implement a certain feature.  Therefore, I use the term "bug"
in the most general sense of the word.  Some of the bugs are directly 
related to the implementation of MATLAB running on a specific operating 
system.  Therefore, I separated the bug list into two parts: the first
part (GENERAL) introduces bugs which are common to all operating systems; 
the second part (OS SPECIFIC) introduces bugs that I encountered while 
testing the DFP package with MATLAB running on a specific operating system
only.  In all the OS SPECIFIC cases, the bugs I have observed stem from 
bugs in MATLAB.  If I have confirmation from the Mathworks technical
support staff, that the observed problem is indeed due to the
implementation of MATLAB on that specific OS, then I indicated the 
corresponding bug/problem as such.

   I tested this release of DFP with MATLAB version 4.2c and the Signal
Processing Toolbox version 3.0b running on SunOS, Solaris, Linux, Windows95 
and (DOS6.0+Windows 3.1).   I do not have access to computers running MATLAB 
on other operating systems.  I am certain that there are other DFP bugs
and/or problems which will surface only when one runs the DFP on other OSs.
If you use DFP and observe problems different than listed in this file, 
please inform me about the nature of the problem and about the version of 
MATLAB and OS you have been using.

REMARK: It will be a while before I will have a chance to test DFP with
        MATLAB version 5.0.  Our site has not received this most recent 
        release from Mathworks yet (as of Feb 10, 1997).

GENERAL
=======

G1. The zoom feature on the DISPLAY subplots does not work properly.
    By this remark, I mean that for the Magnitude and Phase/GDelay/Impulse
    plots when using the rubber-box zoom, the zoom effect is not symmetric.
    Also for the pole-zero plot the rubber-box zoom works intermittently.
    If in doubt, use the zoom-by-clicking feature, that works all the time
    and very consistently.

G2. The estimated filter order values for the bandpass and bandstop filters 
    represent only (1/2) times the true filter order.   This is really not
    a bug, but rather I tried to use TMW conventions.   Would it be more
    consistent if I had used the true filter order values?

G3. Unequal stopband attenuation for bandpass filters and unequal passband
    attenuation values for bandstop filters are accommodated by using the
    more restrictive of the two specifications.  Therefore for such IIR 
    filters the true order may be lower than indicated.

G4. There is no filter order estimation routine for non-Kaiser windowed
    FIR filters and Least-Squares FIR filters.  For windowed FIR filters
    the estimated filter order corresponds to the estimated Kaiser-Window
    based FIR filter order and for the least squares method it is copied
    from the Remez field.  Any suggestions?

G5. When the filter code is written to the user specified file, filter
    specifications are also written to the file header to facilitate
    filter file identification.  This information is obtained from the text
    and editable text fields of the TYPE/SPEC window.  However, if one
    changes the filter type without actually carrying through with the
    design, then incorrect filter specifications will be written to
    code file header.  While this does not effect the actual filter
    coefficients, it can be misleading.

G6. To allow resizable figures, DFP first creates all the figures at the
    start and then changes the units of children of figures to "normalized".
    This results in a slight change of the position of certain objects.  
    This phenomenon is mainly due to round-off errors as the pixel positions 
    are translated to normalized screen coordinates.  No effect on DFP, just
    a very minor esthetic annoyance.


OS SPECIFIC
===========

LINUX:

L1. The file dialog boxes that open when one calls the built-in MATLAB
    functions "uigetfile" and "uiputfile" are quite different than what I
    encountered using the Windows, SunOS, Solaris versions of MATLAB.  
    The LINUX version of the dialog boxes are very spartan.  They do not
    allow the user to see the other files in the directory, nor
    do they allow the user to change directories.  If you want to open a
    file in another directory or save a file into another directory than 
    instead of using interactive "uigetfile/uiputfile" features enter
    the desired directory and file name directly into the corresponding
    editable text fields.

L2. For some reason the position of "pop-up" uicontrol objects generated
    by the LINUX version of MATLAB is slightly skewed.  This does not
    affect their usability.  It is only a minor esthetic irritation to the
    eye.   Therefore, I did not bother to adjust their positions in a OS
    specific way.


WINDOWS:

W1. The "uimenu" objects behave in a totally weird way.  As you may
    notice the "uimenu" objects in the [DFP: Display] figure adapt to
    what are currently displayed.  This works fine on other OSs, but 
    not on Windows.  Mathworks technical support confirmed this as a 
    MATLAB bug, so go bug them.  This bug does not affect the DFP in 
    any significant way.  Users may not be able to change certain 
    features of the Phase/Group Delay/Impulse Response plots, display 
    the filter coefficients in a different format, or take a snapshot 
    of a certain plot, if the corresponding "uimenu" object is not 
    visible on screen.  The most commonly used "uimenu" object is the 
    "Magnitude" uimenu, which, fortunately, seems to be unaffected.

W2. One cannot control the "ForeGroundColor" and "BackGroundColor"
    properties of the "uicontrol" objects.  This causes some esthetic
    problems using the [DFP: Properties] figure, but otherwise has no
    effect.  I suspect this bug may also cause additional problems when
    running DFP on a monochrome monitor.  But, I have not tested this.
    This is also a MATLAB/Windows bug confirmed by Mathworks technical
    support staff.

W3. The "uimenu" accelerator keys do not function.  This phenomenon
    results from the disparate way of identifying the accelerator keys
    for the MATLAB/Windows and for the other MATLAB implementations.
    And I have no intention of addressing this issue for the sake of
    Windows.  If Mathworks implements this feature in a truly platform
    independent way, then we should start seeing a consistent behaviour.

W4. If the default UICONTROL font is set to a large font size, then you
    may observe that several text objects that normally should appear on 
    a single line will wrap around and appear as a two line text object.
    On a 17" monitor [MS-Sans Serif]-[Regular]-[6] works fine.  You may
    set the default UICONTROL font through the Options menu option in
    the MATLAB Command Window.

W5. If you happen to be running Windows at a lower resolution than 1024x768
    than DFP scales down all the windows and GUI objects accordingly. When
    the GUI objects become smaller you may observe that object labels
    and/or strings may extend beyond the object boundaries.  If this happens
    to be the case then you may want to adjust UICONTROL font from the
    MATLAB command window.

W6. If you use Windows95 or Windows NT there is another important point you
    should be aware of.  There are two files in the UITOOLS distribution
    that violate the 8+3 file name convention.  In particular, these files
    are INPOLYGON.M and MATQPARSE.M.  Rather then truncating these file 
    names I kept the original names as given by Mathworks.  When you install
    DFP, Windows keeps the long file names in that absurd directory
    structure, but for older programs (such as MATLAB) which is not aware of
    long file name structures, these files appear something like
    "INPOLY~1.M".  The only cure to this problem, is to rename the offending
    files "INPOLYGO.M" and "MATQPARS.M".  If you already had UITOOLS on your
    system or if you are using Windows 3.1.x you should not encounter this
    problem.


    
    Author: Mehmet Zeytinoglu (mzeytin@ee.ryerson.ca)
            Department of Electrical and Computer Engineering
            Ryerson Polytechnic University
            Toronto, Ontario, M5B 2K3 
            CANADA

    Copyright (c) 1997 Mehmet Zeytinoglu

    $Revision: 1.2 $
    $Date: 1997/03/11 13:39:22 $

