- WebODF - lists.nlnet.nl

WebODF 0.5.1 released, bringing fixes
by Jos van den Oever 21 Jul '14

21 Jul '14

This message comes to you from Friedrich Kossebau: Dear WebODF-interested and enthusiasts, we WebODF developers are happy to declare that: WebODF version 0.5.1 is tagged and out! Less than 3 weeks after the release of WebODF 0.5.0 there is the first update. It brings improvements in the rendering of the numbering of multi-level lists, solves issues during the startup of the Wodo.TextEditor on Safari and more. So go to the Download page (http://webodf.org/download/) and update your deployment of webodf.js or the Wodo.TextEditor. Changes between 0.5.0 and 0.5.1 WebODF Improvements * numbering of multi-level lists is now well supported in rendering, including display of only a subset of the list numbers and continued numbering from previous lists (both `text:continue-numbering` and `text:continue-list`) (https://github.com/kogmbh/WebODF/pull/565) Fixes * Loading of documents without optional <style:list-level-properties> or <style:list-level-label-alignment> no longer fails and stalls * Loading of ODT files with annotations in Internet Explorer 10 (and possibly other versions) no longer fails and stalls Wodo.TextEditor (See also section about WebODF) Fixes * Start-up of editor no longer hangs in some browsers: Two different bugs were fixed which so far broke the start-up with Safari and other browsers using older WebKit versions as well as the default browser on Android 4.0.3 (https://github.com/kogmbh/WebODF/issues/693) * All toolbar elements are now disabled when no document is loaded. (https://github.com/kogmbh/WebODF/issues/709) Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

1 0

ViewerJS 0.5.1 released, bringing rendering improvements
by Friedrich W. H. Kossebau 21 Jul '14

21 Jul '14

Dear WebODF-interested and enthusiasts, following the release of WebODF 0.5.1, now also ViewerJS, the WebODF based Open Source document viewer for webpages, is available in an updated version. It brings all the rendering improvements of WebODF 0.5.1 for files in the OpenDocument Format as well as a newer version of PDF.js for files in PDF format. ViewerJS continues to be the candidate for embedding ODF or PDF files directly in webpages, without any external server dependencies, just done with HTML, CSS and Javascript. You might remember that deployment of ViewerJS is quickly done: 1. download http://viewerjs.org/releases/ViewerJS-latest.zip 2. unzip the file 3, move the folder "ViewerJS" to the toplevel dir of the folder structure served by your webserver (could also be another dir) 4. for a given ODF or PDF file add this line to an html file: <a href="/ViewerJS/#../relative/path/from/ViewerJS/to/some/filename"> (filename needs to have ".pdf", ".odt", ".odp" or ".ods" extension) Now reload that html page in your browser and find the document in the file displayed inside the html page, with toolbars to navigate between pages, control the zoom level or go to presentation mode or fullscreen. Please visit http://viewerjs.org/ to learn more about ViewerJS, and give it a deployment in your webpages. And then spread your knowledge among your peers :) Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

1 0

WebODF 0.5.1 released, bringing fixes
by Friedrich W. H. Kossebau 19 Jul '14

19 Jul '14

Dear WebODF-interested and enthusiasts, we WebODF developers are happy to declare that: WebODF version 0.5.1 is tagged and out! Less than 3 weeks after the release of WebODF 0.5.0 there is the first update. It brings improvements in the rendering of the numbering of multi-level lists, solves issues during the startup of the Wodo.TextEditor on Safari and more. So go to the Download page (http://webodf.org/download/) and update your deployment of webodf.js or the Wodo.TextEditor. Changes between 0.5.0 and 0.5.1 WebODF Improvements * numbering of multi-level lists is now well supported in rendering, including display of only a subset of the list numbers and continued numbering from previous lists (both `text:continue-numbering` and `text:continue-list`) (https://github.com/kogmbh/WebODF/pull/565) Fixes * Loading of documents without optional <style:list-level-properties> or <style:list-level-label-alignment> no longer fails and stalls * Loading of ODT files with annotations in Internet Explorer 10 (and possibly other versions) no longer fails and stalls Wodo.TextEditor (See also section about WebODF) Fixes * Start-up of editor no longer hangs in some browsers: Two different bugs were fixed which so far broke the start-up with Safari and other browsers using older WebKit versions as well as the default browser on Android 4.0.3 (https://github.com/kogmbh/WebODF/issues/693) * All toolbar elements are now disabled when no document is loaded. (https://github.com/kogmbh/WebODF/issues/709) Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

1 0

Sample ODT
by Rubén Sánchez Paredes 09 Jul '14

09 Jul '14

Hi, I'm rubinhozzz from the IRC. I have attached the odt file. Some colleagues told me the plugin is based on a old ODT version, as they get the same errors, well no errors but inconsistences. - No bullets or numerations - No red arrows - Images are a bit moved from their real location. Thanks in advance -- Ruben Sanchez Protonic Holland. tel.: +31 (0) 229 212928 fax.: +31 (0) 229 210930 Factorij 36 / 1689 AL Zwaag

1 0

Switching from Qt4 to Qt5?
by Friedrich W. H. Kossebau 05 May '14

05 May '14

Hi, tl;dr Any showstopper for using Qt5 instead of Qt4 for WebODF tools? The WebODF build system relies on qtjsruntime to run the tests. Now qtjsruntime is currently based on Qt4, which uses a very old version of WebKit. There is the QtWebKit 2.3 project (see http://blogs.kde.org/2012/11/14/introducing-qtwebkit-23) which brings in a newer WebKit version, that is also used by most Linux distributions as standard replacement for the official QtWebKit that is part of the released Qt sources, even the latest 4.8.6 But the self-compiled Qt 4.8.5 on CI does not have that yet (from what I can tell), and people developing on Windows or OSX might also seem to need to do some extra work to get QtWebKit 2.3 installed, so increases the hurdles for them. Problem with such an old WebKit as in normal Qt is that it is buggy and far behind. And we start to add hacks in WebODF code just to workaround bugs there, as discussed in https://github.com/kogmbh/WebODF/pull/550 So moving to Qt5, which uses a more modern version of WebKit (and/or soon Blink, see http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/ ) seems like a good solution for the problems noted above. There is currently on other subproject in WebODF based on Qt4, nativeQtClient, but that has bitrotted and needs some work to be resurrected. And when doing that it makes more sense to use Qt5 as well, because that should enable to reach more platforms thanks to Qt5. So, any reason not to prepare a patch which switches qtjsruntime to Qt5 (and perhaps remove nativeQtClient for now)? Everybody has Qt5 installed on their development enviroment or could do so? Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/

3 3

alfresco share integration.
by Siala Omar 10 Apr '14

10 Apr '14

Dears, I want to integrate webodf to display and edit my odt documents in share. Any help!! Best Regards. -- *Omar SIALA* *Computer Science Engineer * *Tel*: +216 21085753

2 1

Functions/Methods in a class
by Aditya Bhatt 24 Mar '14

24 Mar '14

When writing methods for a class, I generally use the following pattern: [1] ``` /** * APIdox */ function doSomething() { } this.doSomething = doSomething; ``` instead of [2]``` /** * APIdox */ this.doSomething = function() { }; ``` I prefer to do this even if `doSomething` is never used internally in the class. This is because if and when it becomes necessary to use this function within the class, I do not need to change too many lines by switching from [2] to [1]. I am also more comfortable with the C++ pattern in which public functions are expected to be simply callable just like a private function within the class. It would be nice to have a policy for this so we can have a consistent style. Thoughts?

2 1

Highlight a Letter
by Schroeder, Tabea 25 Feb '14

25 Feb '14

Dear webODF Developers, I want to use your library to display odt Data and highlight letters in the text using the keyboard. I tried the "getting started" example, with Documents created by OpenOffice or LibreOffice. Only the Documents created by LibreOffice get displayed, the other cause: "loading dataname.odt". How can I solve this problem and display both types of documents? I tried to highlight a word with the method odf.OdfCanvas.getAnnotationViewManager().highlightAnnotation(); but I don't know which object this method needs. Is this the right Method and how can I use it? I need two types of highlights, can I change the highlight color or the type of highlight? Thanks in advance Tabea Schröder

1 0

Webodf - saving the loaded document without downloading it
by Pawel Cisek 18 Feb '14

18 Feb '14

Dear webODF Developers, I'm using Your javascript library called webodf. I've got 1 question (I've tried to find answer online but i didn't manage to do it). Is it possible to save (loaded from the beginning like for example "welcome.odt") file without downloading it to computer. After clicking button save the changes are saved to the open file instead of downloading new file with changes. I'm looking forward to hearing from You. Pawel Cisek

1 0

coding rules for types
by Jos van den Oever 11 Feb '14

11 Feb '14

Hi all, In our codebase we use some annotations differently. This can be confusing for new developers that are not too familiar with Closure Compiler annotations. So I'm proposing some rules that we'll try to enforce by linting. 1) For the types 'string', 'number', 'boolean' and 'function', the '!' shall not be written explicitly. Rationale: Prepending a '!' to a type means that it is not null. For esp string, number and boolean, it's weird to have the null value. These types occur a lot and making the '!' explicit would mean a lot of '!' in the code. In an Object with string keys, the '!' looks especially silly: Object.<!string,!Object> (Using undefined or null as a key will change it to 'undefined' and 'null' respectively). 2) For the types 'Object', 'Array' and 'Function', the '?' shall be written explicitly. Null pointers can be a problem. The compiler checks the nullness when passing an object but not when accessing a member. Keeping awareness of nullness high is good. 3) Objects will always explicitly have 'string' as the key. So each Object in a type definition starts with 'Object.<string,'. Rationale: Any other type makes no sense, because in JS the key type is always a string anyway. 4) Each non-constructor function must have a @return declaration. What do you think of this proposal? Cheers, Jos

3 3