Over the weekend I hacked a quick integration of the Nimbudocs Editor with Plone 4.3 in order to demonstrate the collaboration modus of Nimbudocs Editor.
To make it short:
- an editor can enable the collaboration mode for the current Plone document opened in Nimbudocs Editor
- other editors (with edit permission on the document) can join the editing session
- the primary editor of the document can give control to other participants
- all changes are directly reflected to other participants (like Google Docs or Etherpad)
Be aware: Android related rant following
This is kind of a rant followup to a year-old posting of mine about using Samsung Android on a Galaxy Tab.
Some months ago I bought a Cloudnet CR 9/S Android stick - one of the fastest Android stick you could find at the time with a fast quad-core CPU running the lasted Android 4.2 version.
I bought it because I was looking for a small hardware solution for running some presentation videos at the our booth during the DMS Expo fair some weeks ago in Stuttgart.
This buy was a major disaster.
To make it short:
- Android market app crashed continuously - hard to update installed software.
- I could enter the password of our home wifi network using an attached USB keyboard but the RETURN key could not be used for blicking the CONNECT button and confirming the dialog. I had to attach an USB mouse for clicking on CONNECT - how stupid is that?
- The stick/Android did not recognize a brand new 1080p-capable display connected through HDMI (working with all other computers - even with my Raspberry PI).
- I had to download five or six different Android video player to get a 30 fps video running at the full frame rate. Even apps like VLC did not work properly - even with hardware acceleration enabled.
- Android software remains a pile of unpolished alien software shit. In various applications you could see buttons where the english text fits into the predefined button size but longer german texts like "ZULASSEN" became wrapped into two lines "ZULASSE-N" - sorry, but this an absolutely non acceptable behavior of a user interface in 2013.
That's why I still love my iOS hardware - working and shiny - independent of the "closed" Apple eco-system.
User experience is what counts and Android feels as user-unfriendly in version 4.2 as it was years ago.
The Produce & Publish platform got a new experimental editor: Nimbudocs Editor
Nimbudocs is a HTML5+JS driven WYSIWYG editor that runs on all modern browsers.
It is the first editor that provides real WYSIWYG to the end-user.
Its primary purpose is to provide exactly the same layout to the document author as in the generated PDF document.
Nimbudocs Editor is not designed to be used as default editor for content as part of a CMS system.
The main focus is on providing a real WYSIWYG feeling to the author.
Some features of the Nibudocs editor
- full WYSIWYG
- edit wide tables in landscape mode
- PDF generation directly from the browser
- collaboration support
- individual parts of the document can be made editable or non-editable (using CSS)
- Web-to-Print applications
- businesscard generator
Here are some demos
Please note that Nimbudocs Editor is not a final product so far. We are early-adaptors of this new technology.
Produce & Publish Website (deutsch) relaunched
Im Rahmen der Vorbereitung zur Teilnahme an der diesjährigen DMS Expo haben wir auch endlich die deutsche Version der Produce & Publish Website komplett neu realisiert. Die neue Website strukturiert alle Informationen über Produce & Publish wesentlich besser und bringt die Funktionalitäten von Produce & Publish auf den Punkt. Neben einer besserung Gliederung der Website haben wir auch Wert auf eine ausführliche Darstellung der verschiedenen Kompontenten und Konvertierungsoptionen gelegt. Eine umfangreiche Sektion mit Referenzen und herunterladbaren Beispieldokumenten runden den Relauch der Website ab.
Im Anschluß an die DMS Expo werden wird im Laufe des Jahres dann auch den Relaunch der englischen Version der Produce & Publish Website in Angriff nehmen.
Produce & Publish Plone Client Connector extended with DOCX import
A recent discussion with a customer brought me to the point rewriting the existing DOCX import into Plone (as it exists in the "old" Produce & Publish Authoring Environment) from scratch. The new functionality provides basically the following:
- an import form that can be called in the context of a Plone folder object
- the import form allows you to upload a Word DOCX document
- the conversion process in the background will send the file to the Produce & Publish Server where is it converted to XHTML using unoconv
- the generated XHTML document is split into the contents and styles
- the html-ish context is stored as Plone Document, the style sheets are stored as Plone files, images are stored as Plone images
- a dedicated view will render the html-ish context together with the extracted styles from the DOCX document
The conversion result actually looks reasonably well.
A nice side-effect: the names of DOCX styles(?) ("Formatvorlage" in German) are preserved as CSS class in the HTML. So when the original DOCX document contains a paragraph marked as "address" we will have <p class="address"> in the HTML. This makes it easy to apply global styles to common CSS classes as used for example as part of a company-wide DOCX template.
Produce & Publish (Plone Client Connector and Server Component) now supports the generation of PDF using Phantom.js as low-cost (free) alternative to commercial high-quality converters like PrinceXML, PDFreactor or Antennahouse Formatter V6. The quality should be good enough for most cases. The interesting part is that the look & feel of the PDF can be influenced using CSS.
Here is a quick walk-through on using the newest Produce & Publish Plone Client Connector together with the reimplementation of the Produce & Publish Server with Plone 4.3 and Phantom.js
Installation of the Produce & Publish Server
git clone https://bitbucket.org/ajung/pp.server
bin/buildout -c complete.cfg
The buildout above already installs and configures Phantom.js automatically.
Installation of Plone 4.3 with the decent Produce & Publish Plone Connector
git clone https://bitbucket.org/ajung/pp.client-plone
After starting Plone and creating a new Plone site you can for example create a PDF version of the front-page by adding @@asPDF to the URL of the related object.
Alternatively you can add pp.client-plone to the eggs section of your buildout configuration and re-run buildout afterwards. By default the Plone Client Connector will use PrinceXML (demo version )as converter (which is installed automatically with the pp.server buildout above. You can switch to PhantomJS by setting the environment variable
in the shell or through buildout (check the zope2instance recipe documentation).
The Produce & Publish Plone Client Connector has basically the same functionality of its older implementation as documented in the Produce & Publish docs.
All this is currently work-in-progress and their might be issues. However the core functionality has been stable for years and will now move a bit to a more modern architecture without throwing all code away. There are several known issues. Most important: all images in Plone are always exported in their original size. Image scaling is either subject to the PDF converter (e.g. by using related width/height on the CSS media=print level) or by applying a scaling transformation as part of the conversion workflows. Please read the code in this case if you want to step forward.
To be clear: all these components are open-source. There is nothing kept back in private. You get what you pay for also applies here regarding the PDF quality. For high-end quality you will need to use converters like PrinceXML or PDFreactor and pay for it. If you don't need features like CMYK support, PDF bookmarks and encryption etc. then you could be very happy with PhantomJS - at least PhantomJS offers a much better quality that you got so far from other tools like Apache-FOP, Reportlab, PISA, htmldoc.
Feedback appreciated, pull requests appreciated. Everything is on Bitbucket. Feel free to contribute...
Our premier Plone-based PDF solution - worth 1500€ - from now on for free!
I am pleased to announce that our Produce & Publish Authoring Environment for Plone is now released as open-source. The Authoring Environment has been the only commercial component of Produce & Publish until today. With the ongoing work on the next generation of Produce & Publish I decided to make this remaining component available to the public in addition to all other components of the Produce & Publish stack that already existed in the past as open-source release. The Authoring Environment was formerly priced with 1500 €.
So now the complete update-to-date Produce & Publish stack is available for free and as open-source:
- Produce & Publish Authoring Environment (zopyx.authoring)
- Produce & Publish Plone Client Connector (zopyx.smartprintng.plone)
- Produce & Publish Python Client (zopyx.smartprintng.python)
- Low-level converter bindings (zopyx.convert2)
Progress report from EuroPython 2013 in Florence
I spend several hours this week during the EuroPython 2013 conference in Florence bringing the Produce & Publish implementation forward.
- The Produce & Publish server should be now in a stable state support both synchronous and asynchronous conversions.
- Instead of using supervisord for controlling all processes I switched to Circus which fells more approachable and extensible.
- The pp.server buildout now supports the automatic installation of all external converters (demo versions only!)
- Support for PDF generation using PhantomJS has been added. This gives you decent PDF generation for free (including support for most CSS Paged Media extensions). PDF generation through PhantomJS should be good enough for sites that just need some kind of "good" PDF export. The feature list of PhantomJS and the quality is however clearly below the featured PrinceXML and PDFreactor converters.
- The Python client bindings for Produce & Publish have also stabilized and support both synchronous and asynchronous conversion operations.
This is another update on the current implementation progress of the complete Produce & Publish infrastructure.
Significant progress has been made on the reimplementation of the Produce & Publish Server. The Produce & Publish server provides some web service API methods that all arbitrary application to convert their content to PDF through a central conversion server. The PDF generation is (as in the past) based on one of the following PDF converters:
- PrinceXML 8
- PDFreactor 6
- Anntennahouse Formatter V 6
- all conversions are based on HTML/XML as input
- styling is accomplished through CSS3
This is a personal followup on several discussions I had in personal lately with other Plone integrators and big Plone users in addition to Steve's and Eric's latest blog posts on the future of Plone (5):
Most of us are in weird situation because we have multiple and different roles in the #Plone world: either as integrators, as contributors, as Plone users.
So where is my current problem?
Steve numbers clearly show a growing number of contributors. On the other hand there is the overall feeling that Plone turned into a legacy technology that will be around for many years but the overall impression is that the overall adoption of Plone is stagnating. This impression is of course subjective and based on personal experience and talks with customers. In addition many so-called Plone companies are currently making a shift by no longer focusing on Plone but also providing services in other areas and focusing on solution and services to customers and addressing their needs instead of advertising themselves as "Plone company". The concept of the "Plone company" is going to fail for most Plone shops. Customers are looking for solutions and as integrators we have to have various solution options - Plone will be one out of many others. The decade of the CMS systems is over. CMS turned into commodity software. They were something new and cool in the first decade of the millennium but nowadays web technology moved and the technology and requirements are more diverse than ever. So content management is now only a small fraction of "the web" as it was some years ago. I think the trend of stagnation and more slowly adoption is also true for other content management systems.
Going back of the level of adoption of Plone. The level of adoption of an enterprise-level software is possibly depending on factors like
- user experience
- to a certain degree: underlaying technology
- Webdav support of Plone under Windows is fragile and not usable for enterprise-level usage. Many weird workaround exists for getting rid of webdav locking problems.
- Customer received a Plone 4.2 buildout with a policy and theme package. Everything was working...the customer himself installed a few add-ons on its own...suddenly the complaint that TinyMCE would no longer work...even after debugging for some hours I could not find the real problem...perhaps not a core-issue but some weird interaction of Plone with some of the add-ons. Bad user experience, pissed integrator experience.
- OOTB installation of add-ons must work. E.g. a simple functionality like video support in Plone has to work without issues by installing collective.flowplayer (4.0). As an integrator I can handle issues and properly fix them. End users just become frustrated.
- Upgrade story: upgrades in Plone 4.x became an unpredictable pita. With 4.x update we had to update various add-ons basically because of changed imports. So some add-on in some version was only running with one particular Plone 4.x version. Having to support multiple Plone 4.x versions ended up with try..except cascades or different release branches....not nice.
- Migration story: I upgraded a Plone 4.0 site to Plone 4.2 based on my own Produce & Publish framework. Suddenly some image URLs (using plone.app.imaging) could no longer be resolved directly through restrictedTraverse() for whatever reason. In addition: Plone started to store image URLs (as edited through TinyMCE) suddenly with the full host and port which became a major pita in the context of virtual hosting and in particular in the context of having image URLs starting with https:// accessed through the public website served over http:// (IE security restrictions caused the images to appear broken). All these issues caused major user pain and trouble on our site. In the end the migration took full six working days (two days scheduled and paid, four unpaid working days on the integrator side).