https://bugs.documentfoundation.org/show_bug.cgi?id=155358
V Stuart Foote <vsfo...@libreoffice.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |libreoffice-ux-advise@lists
| |.freedesktop.org,
| |rb.hensc...@t-online.de,
| |vsfo...@libreoffice.org
Status|NEW |UNCONFIRMED
Ever confirmed|1 |0
Keywords| |needsUXEval
--- Comment #5 from V Stuart Foote <vsfo...@libreoffice.org> ---
Not clear this is valid.
When entering a matrix, it is applying the enclosing nodes for left | right
stretchy bracketing that causes the matrix to not respond with partial entries.
Leave the brackets out while building and matrix will render with place holders
for missing elements.
e.g. build or paste just the matrix {}
matrix{
m_1' E # 0 # 0 # 0 # dotsaxis ##
0 # I_1' # 0 # 0 # dotsaxis ##
0 # 0 # m_2 E
}
After the first ## line break the matrix has its n - column count, pre enter
the ## for each row to set the m - row count (they don't render yet). But each
element will render as completed with its closing #. Complete entry of the
matrix elements.
Only then add the brackets.
Of course that is not the way folks write equations--but then LaTex is not any
better.
Placing Formula Editor into the "experimental" and incomplete Visual mode
(Tools -> Options -> Advanced "Enable experimental features") helps a little
with entry.
Point is the sm node logic facilitates layout and presentation--not
standardized mathematics markup.
The entire UI and sm render engine needs rework. Doing it piecemeal for
specific constructs doesn't move it along.
Throwing to UX-advise for consideration of what really should be direction for
the sm module. Status quo does not facilitate efficiency of creating discrete
OLE formulas (ODF Formulas .odf) nor input of in line formulas. Needs some
design attention.
--
You are receiving this mail because:
You are on the CC list for the bug.
