Re: First view of Amaya 3.2

> Some areas that are still causing problems within Amaya 3.2
> (July 3, 2000) from my viewpoint [Windows 95 and display limited
> to 640x480 @ 256 color] are as follows (arranged editor issues first):
> Geometry Manager
> 1] Checking for video size and positioning windows inside the frame
>    requires more work.  Windows that open to right side (such as
>    View Source) are off the right edge when small screen (eg 640x480)
>    are used.  Other examples are 'alternate' view and 'structure'.

I agree the standard values are not well adapted to small screens
but is it reasonable to manage multi-views on small screen when you
know that Windows pops up the view that receives the focus?

> 2] When a window is resized or moved and the geometry manager is 
>    asked to save it, a restart of Amaya loses the 'new' size/position
>    ie. the save has not been done. An example is:
>    Views -- Show Source
>             drag to a new position
>             Special - Preferences - Save geometry
>             selecting special loses display of source :-( oops !!

the formatted view receives the focus, so you source view is hidden 
by the formatted view.

>             saving and then restarting and doing Show Source will 
>             exhibit that the new position hasn't been saved.

This is because the source view is not really a view. It uses the position 
and the dimension of the structure view. So you should change the values
of the structure view.

> Color Selection
> 3] Many color-picker selected colors do not look like the ones
>    displayed in the picker swatches. This is 256 mode related!!

We don't plan to spend time for improving the current strategy.

> Table Display
> 4] Table frames are thin lines which can be covered up by the
>    cell contents. An example of this is 
>    ''
> 5] Div element was used with attribute align="center" on a table
>    but the table not drawn centered. An example of this is
>    ''

I'm not sure it should be

> 6] Tables become confused if stacked more than two levels down.
>    An example is ''
>    where text is printed outside their associated box.

These tables fix constraints which are unsolvable.

> 7] The above example also indicates an inconsistence. The document
>    can be viewed on line but if a copy is taken off line, it requires
>    an extension of HTML (or htm) to be viewed. If the name used is
>    links. without an extension only the source is displayed.

This lets Amaya display the same document in source mode and formatted

> 8] Errors in table math that are editor detectable, should be
>    flagged to user.
> Other Display Problems
> 9]  After scrolling to bottom of document, scrolling up to top
>     overscrolls on many docs.  Examples of this are 
>     '' and
>     ''
>     And scrolling down overscrolls on some documents such as
>     ''
> 10] Images are not floated correctly although this is part of
>     HTML 4 specification.
> 11] Image elements placed directly after a header element closer
>     does not align correctly with margin settings.
> 12] Horizontal rules have a hook on the left edge. Either the rule
>     isn't being drawn to the correct thickness or first char isn't
>     in correct proportion to rest of rule.

That appears with invalid HTML.

> Screen Scroll Control
> 13] The scroll bars can't be pulled to the very bottom or right edge.
>     No information is lost but this is untidy.
> Compose Multi-key function
> 14] Creating a soft hyphen adds a &173; to the document which
>     will not pass some validators.  Should use ­ instead.

Amaya generates the ISO-latin code but no entity.

> Documentation
> 15] Standard shortcut nomenclature should be used in menus.
>     For example Alt + P  instead of Alt p    and
>     Ctrl + Enter  instead of Ctrl Return

Windows is limited in that domain and we need a lot of shortcuts.
If we can use Shift an no-Shift we will have twice shortcuts.


Received on Wednesday, 5 July 2000 12:45:12 UTC