November 2013 - WebODF - lists.nlnet.nl

FW: Open Document Editors Devroom at FOSDEM 2014, 1 February 2014, Brussels
by Friedrich W. H. Kossebau 26 Nov '13

26 Nov '13

Hi, Call for participation is out, talks about any open document editors or the ODF format welcome, deadline December 22, read in detail below. >From http://mail-archives.apache.org/mod_mbox/openoffice-dev/201311.mbox/<5294F751.4000903(a)apache.org> : --- 8< --- (feel free to forward to other lists and other projects; if you have questions, of course you can ask them on the OpenOffice dev list too) Open Document Editors Devroom at FOSDEM 2014, 1 February 2014, Brussels Open document editors are coming again to FOSDEM with a shared devroom which gives every project in this area a chance to present ODF related developments and innovations. The devroom is organized by Apache OpenOffice and LibreOffice. We invite submission of talks for the Open Document Editors devroom, to be held on Saturday, February 1st, from 10AM to 6PM. Length of talks should be limited to 20 minutes, as we would like to have questions after each presentation, and to fit as many presenters as possible in the schedule. Exceptions must be explicitly requested and justified. Technical talks (code, extensions, localization, QA, tools and significant adoption related cases) about open document editors or the ODF format are welcome. Submissions must be done using the Pentabarf system: https://penta.fosdem.org/submission/FOSDEM14 While filing your proposal, please add a few lines about yourself (although your profile might already be stored at Pentabarf) and specify what product or topic (Apache OpenOffice, LibreOffice, both, other editor, ODF in general...) your talk is about. The deadline is Sunday, December 22, 2013. Accepted speakers will be notified by January 5, 2014. You can send any questions to the devroom mailing list: office-devroom(a)lists.fosdem.org --- 8< --- Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

1 0

Re: [WebODF] getting started help
by Joshua Kramer 25 Nov '13

25 Nov '13

Hi, I'm replying to news75 and Michiel. I ran into the same problem as news75. Here's the problem: if I do, odfcanvas.load("questions.odt") then I get a "Not well formed" error when it tries to load. If I do odfcanvas.load("file:///home/josh/Documents/questions.odt") then I get a domain restriction error. These errors appear in the Javascript console of Firefox when I have it enabled. Chromium behaves in the same way. Any ideas? Thanks! -JK

2 2

Where can I get the code for the demo site?
by Joshua Kramer 23 Nov '13

23 Nov '13

Hello, Is the code that runs the demo site publicly available? http://www.webodf.org/demo/ci/webodf-0.4.2-1305-g54e8ab4/editor/localeditor… If so, where can I get it? Thanks, -JK

2 1

webviewers.org working to standardize interaction between viewers/editors like WebODF and webapps.
by Caleb James DeLisle 18 Nov '13

18 Nov '13

Hi, I noticed http://viewerjs.org/ which seems to be tied in with the WebODF project (correct me if I'm talking to the wrong people) and I wanted to share a similar project that I and others have been working on as part of the Resilience research project. Perhaps we can collaborate. WebViewers is similar to viewerjs.org except that we concentrated on standardizing the format of a WebViewer so that they can be interchangeably plugged into any supported web application and the application's WebViewers subsystem will automatically begin displaying edit/view buttons in the user interface depending on the viewers which are available. The WebViewers protocol should be well described on http://webviewers.org and if anyone has any questions or if anything is omitted, please do let me know. Also any opinions about what is desirable or might be missing are most welcome. Thanks, Caleb

2 1

getting started help
by news75＠libero.it 16 Nov '13

16 Nov '13

hello guys, I'm a new webodf user and I'm trying to starting from the getting started example on webodf home page but I have some problems... I have downloaded the webodf.js file at http://webodf. org/demo/demobrowser/webodf.js and I have done a html page how listed in the getting started example and I have done a very simple odt page. The problem is that when I load the page in my firefox 25.0 on fedora 19 I get a page that say: "loading myfile.odt" after that nothing heppen, no odt pages are loaded... any suggestions !? g.

2 1

Proposal for solution of current memberdata needs
by Friedrich W. H. Kossebau 06 Nov '13

06 Nov '13

Hi, current situation: there are two operations (one existing, one hypothetical) which create/modify datastructures with the element <dc:creator>: * OpAddAnnotation * OpSetMetadata (would update e.g. <office:meta><dc:creator/></office:meta>) (Ignoring <office:meta><meta:initial-creator/></office:meta> here for now, creating new documents from templates is a separate problem, not thought in detail about that yet) Issue is that ideally the opspec has all data needed for execution and does not need to query for/lookup anything. Also ops currently cannot access the membermodel, as they only see the ops.OdtDocument object, but not the ops.Session one. OpAddAnnotation ATM breaks that concept, as it relies on the execution method (or rather AnnotationViewManager) to set the proper content for <dc;creator>. <dc:creator> would be passed by OpAddAnnotation by the same member, so just the member would need to know what data it should set in, usally the fullname of the member. In the possible case of the change of the fullname it would be a nice feature to have the <dc:creator> of (at least) all annotations created in the current session be updated. That would need a new method OpUpdateAnnotation, but that still would/could be initiated by the member whose fullname changed. Now with OwnCloud we have the case that any member which leaves the session has to do a save, and for that it would need to set the doc's metadata <office:meta><dc:creator/></office:meta> up-to-date about the person which did the last modification WRT the saved state, following the ODF spec §4.3.2.7 <dc:creator>, which defines that <dc:creator> "specifies the name of the person who last modified a document". Meaning, any member's client needs to be able to know the fullname of any other member in case. Ideally the server/host is the one single source for all data about members, so clients could not play evil to each other and pretend members to be someone else, by passing e.g. faked fullname and avatar ids. Demand: So, how to enable clients/members to create opspecs with member detail of other members, more specific, use the fullname to set for <dc:creator>? Proposal: Member metadata is added to the extended ODF model, as session-only data like cursors are, instead of being maintained in a separate pool. There would be new ops: OpAddMember, OpUpdateMember and OpRemoveMember. The hosting system (in owncloud case the server, in local mode the local system) would create and insert these ops into the op stack: * OpAddMember to tell about a new member and the metadata (fullname, avatar, color, editing rights, session_enter_time, idling/afk/pending connection..., etc) Would be inserted during the successful enterSession call by a client * OpUpdateMember to tell about any change with a member's metadata would be inserted by the host on any change of the metadata. * OpRemoveMember to tell that a member has left the session. Would be inserted by the host if the client calls leaveSession or is kicked out. The current memberdata (fullname, color, etc) itself should be kept around at clients, for the case that it is needed for some rendering of session data. No idea if that would also work with Peer2Peer, is ignored for this solution as it's not a target currently. The OpAddMember op for a new member should be part of the opstack before the client queries the genesis doc and the current op stack. That should be expected, due to adding that during the enterSession query from the client, so before any genesis doc & opstack fetching. Any client should only start to create own operations once it has received and replayed the OpAddMember of its own member (because only then it has got the full details about himself, like the fullname). For the transition period the existing MemberModel could be just a wrapper to the member model which should be part of ops.OdtDocument, and later could be merged into the normal ops.OdtDocument API. What do you think? Are there any holes in the concept? Too complicated? Or simply brilliant? Alternative ideas? Cheers Friedrich PS: As reminder, as sketched now and then some future support for chatting might be done in a similar way, by extending the odf model and doing the messages as operations. -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

2 4

How to make a browser spelling check enabled in webodf editor?
by hj 04 Nov '13

04 Nov '13

The browser spelling check does not work in webodf editor. I think the spelling check is very important feature. Any body knows this feature is planned for future milestone? Or any body has an idea how to enable the spelling check in wegodf editor? Thanks

2 1

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