Once in a while, i need to write a formatted text document for printing, for example a letter, a job application or, like to day, a table for checking the boats in my local sailing club.
Every time, I optimistically launch KWord, because it is fast and lightweight, and have the features I need -- would it just work...
The table I had to write today a little bit complex, it has some rows with 3 columns, some with 2 and some with one. So I created a table with 3 columns and borders, and started to join the columns in the rows where I needed it, and here the problem starts.
All the rows with joined columns looses the right border, and there seems to be NO way to get that back, which alone makes the document useless, I can't provide a nice looking document this way.
After adding all the rows I wanted, saving screws up the formatting COMPLETELY. Why does kwork reformat the document in the event of saving?? Autosave will cause kword to reformat my document at what feels like random times while working, and I could find *no* way of turning autosave of, setting the interval to the maximal 60 mins also seemed to do nothing.
So, I can change a few things and then save, after that i have to
- Close KWord, because of the reformatting
- Kill any left processes
- Reopen the document
My next experiment will be to create a new document and use a table with only one column for a start -- if it is my lucky day, maybe splitting the rows will leave me with visible borders...
In a positive spirit: Is there anything I can do to help with KWord development? Please let me know, I believe that would just the key parts of koffice work, we would have such a nice desktop.
Comments
koffice development
Hi anders!
You can help a lot with kword development as it's basicly only David Faure who works on it... You can pick any app in koffice as they're all pretty much one man shows (well except kexi which has three or four people working on it)!
For specific tasks just take a look at b.k.o
tables
my kword experiences
i tried to understand the kword table system a couple of years ago (maybe some people still remember my attempts), and i had to give up, because it was just too difficult. There were two things i never understood fully:
(this is the situation two years ago, but afaik there has been no frame/table system redesign since then)
- the coordinate transformation system. There are a couple of coordinate systems, and especially with inline frames it got impossible for me to understand. I think there is some baggage here, and i don't think it is really possible to support arbitrarily nested frames (but i could be wrong).
- the concepts behind a table as opposed to a frame. You would think that a table is just a bunch of frames connected, but thats not always the case. the concept 'frameset' suddenly gets a different meaning. Or: i don't understand what frameset means :)
i started to get into frames because my html import filter, but i eventually gave up on kword because lack of time, lack of clues and lack of co-developers (there was David Faure who did a lot of effort to help me understand, and thomas zander also helped me, but i don't think frames/tables were David's priority, and when i proposed a redesign i got no reaction at all, maybe my redesign had problems and was not feasible or too intrusive, but there was no discussion)
i hope you will get the courage to start hacking kword frames, because there is a great opportunity for kword there, if the painting/selection/layouting system worked well (no added features, just work well) kword would be really powerful. its not an easy job but i really think its worth it
tables
Hi kervel, I'm glad to hear from you
Good thing Jesper pointed me to this page, I would have missed it otherwise (what's wrong with the koffice mailing-lists? :)
Now would be a great time for the redesign of inline frames that you had in mind.
One thing about framesets. I don't think we can get around having one frameset per cell. This is simply because it's the frameset which contains the text - not the frames. Think of two connected frames, there it's quite obvious that the text is stored in the frameset, not in the frames. Of course with table cells there's only one frame per cell, but to reuse the same text drawing code it still sounds easier to use one text frameset per cell.
The arguable design idea was to make the table itself a frameset...