Dekel Tsur <[EMAIL PROTECTED]> writes:
| I've looked for your kernel in the 'lyx' cvs module, but the code there is
| incomplete. Is there a working version of your kernel? Is it still the plan
| to use it instead of the current kernel? When?
We jumped the gun a bit when we put the "new kernel" in lyx, there
were too many unresolved issues f.ex. what would LyXText look like.
Before we do _anything_ with LyXParagraph and LyXText I want the table
code and the float code moved out of LyXText. Also LyXText should be
revised so that the class interface will be put on a diet (it is just
too fat).
When this is done we can begin to discuss/implement better/improved
ways of doing storage.
| For the current kernel, I thought of the following changes to the
| way the fonts
| are stored by the LyX paragraph class:
|
| 1. The paragraph stores a vector (FontList) of pairs (position, font),
| sorted by positions, containing the positions in the paragraph in
| which the font
| changes, and the corresponding fonts.
|
| 2. The text vector stores special chars between the font changes.
| This chars are rendered on the screen (for example, a small red
| dot).
Can't this also be handeled by a "next_font_change_at_pos" variable?
(I realy don't like the special chars)
| For example, if the paragraph is "abc def ghi" where def is in bold, then
| the paragrah text vector will contain "abc $def$ ghi",
| and FontList will be {(0,default font),(5,bold),(9,default font)}.
I feel that you two points are ortogonal, we can have one without the
other.
| Here are the advantages of the above suggestion:
|
| 1. Speed. The current rendering code (e.g., LyXText::draw) checks the font for each
| character. This will be eliminated (font change occur only when the special
| char is encountered)
Or the pos in the variale is encountered.
| 2. Improved UI: When you place the cursor on the boundary between two fonts,
| it is currently not always clear which font is going to be used.
| This will be fixed by (2). Furthermore, it will give visual cue when
| changing font attribute that doesn't have a visual effect (like language).
|
| The only disadvantage is that it will give a different UI which will need getting
| used to.
|
| Any comments?
Some more discussion and wait for pending clean-up.
Lgb
