October 2013 - WebODF - lists.nlnet.nl

Advancing WebODF paste support
by Philip Peitsch 01 Nov '13

01 Nov '13

Hi everyone, I'm starting to work towards improving the paste support in webodf so that it can do more than just paste plain text in a single line. The first step here is obviously designing what might work. I've put some documents together on this and have them sitting out in a branch (insert-fragment in my repo if anyone is interested). Here is where I'm at so far: Both of these are available in the branch as well at - https://gitorious.org/webodf/peitschie-webodf/source/insert-fragment:webodf… - https://gitorious.org/webodf/peitschie-webodf/source/insert-fragment:webodf… Copy & paste behaviour and support ================================== Overview -------- Paste support is extremely important to get right for an editor. Users have an expectation that data can be replicated with a high degree of accuracy when copied and pasted. This includes things such as pasting images, styled text (e.g., bold, underline), paragraph breaks, lists etc. This README does not cover details about how data is written or retrieved from the clipboard. For that information, please see README_clipboard.txt. Desired paste support --------------------- * Plain text with paragraphs, tabs, spaces * HTML text with direct formatting * HTML tables * HTML table rows & columns * Images (standalone) * Images within mixed HTML fragments (e.g., HTML fragment with paragraphs & images etc.) * Lists (bulleted & numbered) Requirements ------------ 1. Paste should be able to be undone/redone safely 2. Extra "formatting" steps should be able to be undone without removing the pasted content. E.g., automatically converting to a list or table (optional advanced feature) 3. Want to avoid duplicating logic in other operations (e.g., paragraph splitting & merging behaviours, image insertion, style addition, adding new list items etc.) 4. Any new operations must be able to be OT'ed easily Design ------ There are effectively two opposing approaches that can be taken to handle pasting of new data: 1. Create a complex operation (e.g., OpPasteData) that is responsible for determining how to insert a fragment into the document 2. Create a paste handler that attempts to break the paste fragment into a series of smaller operations Option 1 - Pro: Easily integrates with existing undo/redo manager - Con: OpPasteData likely to contain a lot of duplication of existing ops however - Pro: Less operations generated (less on-the-wire traffic) Option 2 - Pro: Better re-use of existing operations - Pro: Less complex operations required - Con: Need significant re-work of undo operation grouping to allow paste to be undone/redone OT adaption of a paste command is relatively straightforward for both options, as both largely generate insert-only operations. This means that usually the start position just needs to be shifted around to cope with added or removed characters. Based on the pro's and con's, Option 2 is the best approach for paste handling. The key argument for this is that it makes better use of existing operations (requirement#3). The existing undo manager grouping logic is not very extensible, and should be reworked anyways. Example paste steps ------------------- 1. Extract data from clipboard. Order of preference is - Custom webodf fragment ("application/vnd.webodf") - LO/MSWord fragment (??) - RTF fragment (??) - HTML ("text/html") - Plain text ("text/plain") 2. Convert data into webodf fragment (and associated styles) using appropriate import filter 3. Split the fragment up into separate paragraphs 4. Start a new transaction/undo group (this is a new feature...) 5. Add any new named styles (Op???) 6. Add any new auto styles (Op???) 7. For each paragraph - start a new paragraph at the current position (OpSplitParagraph) - insert the new paragraph (OpInsertFragment) 8. After all paragraphs have been inserted, remove the FIRST created split to merge the first inserted paragraph with it's previous sibling (allows the paragraphs to merge with the correct paragraph merge logic) 9. Finish transaction/undo group (Actually, this probably happens on the next edit op start) 10. Auto-convert things to lists, links, etc. (optional). This should be in a new transaction/undo group Questions --------- * Should pasting multiple paragraphs into a list should result in a new list item per paragraph? * Should links be automatically converted? Anyone have thoughts, concerns, feedback or cookies (I'm a little hungry after all this research…)? Cheers, Philip

2 2

Editor Menu Bar Idea
by Ryan Callaghan 29 Oct '13

29 Oct '13

My team is evaluating WebODF / the editor for use as part of an internal tool. In doing this one of the things that has come up that seems like it would be beneficial is to provide a hook to replace the menu bar with a custom one. For us we would nee the save button to save to a server, possibly generate a PDF, and we would likely want to remove several of the default buttons. The idea would be when constructing the editor a optional javascipt file name could be passed down as an argument - this would define the menu bar rather than using the default (there are likely other ways to do this as well). This would allow individuals to leverage the components already within the WebODF editor menu bar, be able to tweak it generically, and not have to rebuild webodf for minor adjustments. A setup like this seems like it would make the API usable with a broader audience without having to add in a significant amount of configuration options. Thoughts? Thanks, Ryan

2 1

using jsdom instead of xmldom
by Jos van den Oever 29 Oct '13

29 Oct '13

Hi all, Our tests in Node.JS do not run the DOM related tests. I looked into using JSDom instead of XmlDom. JSDom is a more complete implementation with e.g. a window object. The patch to use JSDom instead of XmlDom is attached. However, I could not run any additional tests because e.g. createTreeWalker is not implemented in JSDom. So this patch is mainly for future reference when JSDom aquires more of the DOM features that we need. https://npmjs.org/package/jsdom Cheers, Jos

1 0

Pending pull requests - October
by Philip Peitsch 13 Oct '13

13 Oct '13

Hi all, I wanted to check when pull request #24 (direct cursor styling - https://github.com/kogmbh/WebODF/pull/24) was going to get it's next review? This is now close to three weeks old, and has been waiting for the second round of reviewing for over two of those weeks. Cheers, Philip

1 0

SelectionMover and standardising lingo
by Philip Peitsch 09 Oct '13

09 Oct '13

Hi all, Just quickly brain-dumping some recommendations for how to improve the clarity and reduce terminology confusion within SelectionMover. Some commonly repeated terms that appear badly overloaded in SelectionMover are steps, positions and points. Add to this, the functions available are also extremely confusing both in terms of their names, and the internal code (there is a patch coming today to help with the code side). So, new terms of reference I'm standardising on are: Points ====== Raw DOM positions. This is any valid node & offset pair. Related functions ----------------- SelectionMover.StepCounter.countStepsToPosition - converts the distance between two Points into to it's (roughly) equivalent number of Steps Positions ========= A set of positions as returned by the position iterator. This is a subset of points as these can be filtered at the node level via a NodeFilter. Related functions ----------------- SelectionMover.StepCounter.countForwardSteps SelectionMover.StepCounter.countBackwardSteps - converts the number of Steps into it's equivalent number of Positions SelectionMover.movePointForward SelectionMover.movePointBackward - Move the cursor the requested number of Positions in forward or backwards Steps ===== A filtered subset of positions as returned by the position iterator. This is controlled using a PositionFilter. Related functions ----------------- SelectionMover.StepCounter.countStepsToPosition - converts the distance between two Points into to it's (roughly) equivalent number of Steps SelectionMover.StepCounter.isPositionWalkable - returns true if the supplied iterator is a valid Step SelectionMover.StepCounter.convertForwardStepsBetweenFilters SelectionMover.StepCounter.convertBackwardStepsBetweenFilters - translates between one filtered set of Steps to a different filtered set of Steps. IMPORTANT: this function will only work filter1 only accepts a subset of filter2. countStepsToLineBoundary - convert the distance between the cursor and nearest line boundary into Steps countLinesSteps - convert the distance between the cursor and the same horizontal position X lines up/down into Steps My recommendations (I'm assuming you want to hear these :) ) 1. Standardise SelectionMover on Points and Steps only. Any attempts to move a cursor to a Position that is not also a Step is likely a bug. The only place where we deliberately move in non-Step increments is when trying to put the cursor back into a filtered Step. This same effect could be achieved by calling moveForwardStep(0, filter). 2. Remove or rewrite convert(Forward|Backward)StepsBetweenFilters. The current implementation will not work for arbitrary filter pairs. These should likely be re-written to return the number of filter1-steps when travelling filter2-steps in distance. I would also suggest this takes the same approach as countStepsToPosition and round the cursor back to the Point of the last filter2-step that is smaller-than or equal-to the current cursor Point. Cheers, Philip

3 3