Our SmartPrintNG solution for Plone is now available since about 18 months and it introduced support for generating first-class office documents (PDF, RTF, OOXML, ODT) from Plone content. There are no other comparable solutions available in the Zope world when you compare them based on functionality and quality.
Good things are often not good enough!
It is time to step forward bringing SmartPrintNG into the web-to-print world.
SmartPrintNG is dead - long live SmartPrintNG
Over the last months the complete SmartPrintNG code base has been rewritten from scratch based on a complete new architecture where the Plone integration will only be a small layer on top of the zopyx.smartprintng.core and zopyx.convert2 modules. Based on the new architecture we can integrate web-to-print functionality into almost any Python- and Zope-based application. The new flexiblilty can now be used to generate complex and layout-oriented PDF for e.g. business cards, flyers, books etc. A custom web-2-print solution does not depend on any specific data source - it can be a CMS like Plone or a database - the only requirement is that the data must be accessible through Python.
Some key features of SmartPrintNG web-2-print solutions:
- generates PDF, RTF, ODT, OOXML, WML
- separation of content, templates and styles
- easy installation
- can be installed either locally or on a central server
- client-server architecture
- support for counters (e.g. for page counters).
- supports most common paper formats (A4-A0, Legal, Letter)
- language-specific hyphenation support
- multi-column support
- user-configurable margins
- highly-extensible and configurable
- cheaper than comparable commercial solutions
What's coming up?
- The SmartPrintNG server - the central web-2-print working horse - available as product or hosted service.
All SmartPrintNG related core packages will remain free and will be maintained in the well-known repositories on svn.zope.org and svn.plone.org. Further support, customizations, hosted services etc. will be available on a paid basis.
For further questions and assistance, contact us.
The 9th Zope conference organized by the Deutschsprachige Zope User Group is over.
Time to try out Typo 3 in order to figure out how the Plone competitor(s) actually work. It's good to know the "enemy" in order to fight it properly.
It's Sunday afternoon...time for some fun: let's try out Typo3. Step one: Installation. For MacOSX you can download a pre-packaged 166MB archive from here. The installer just works fine and after some minutes a web-browser starts up with the installer UI. After clicking through the ten-step installation process I got the admin login...not bad so far. Step two: after login into the Typo 3 backend you will see a clean tree on the left with various options in one place (compared to various actions scattered around the Plone UI (which makes more sense to me)). With Typo 3 backend I tried to perform a simple task like adding a simple page. The main tree shows me three options: Page, View, List. Click on each options opens a secondary tree with obviously represents a default tree structure...hmmm...what's the difference between the three? no idea :-) Some how I got into the edit more for a page. Typo 3 seems to support out-of-the-box a page composition model (similar to CMFContentPanels or Collage). A standard page can be composed of different blocks and each block has its own configuration UI (comparable to the BernArticle implementation but implemented in a somewhat nicer way). Enough for today....some observation:
- the UI is pretty complicated and not directly intuitive
- the UI is overloaded with icons and little text
- the usability is not straight forward
- the Typo 3 backend feels a bit sluggish and slow (similar to old Plone 2.X versions) - Plone's inline editing mode is much faster to use
- the default page composition options are definitely stronger than what we have in Plone out-of-the-box (which raises the discussion if the editor needs a idiot-proof UI or requires a UI like in Typo 3 with many options).
That's it for now.
During the Blackforest Sprint a new package z3c.pypimirror has been created under the lead of Daniel Kraft. The major goal was to build up a distributed mirroring infrastructure. Why? PyPI is still a single point-of-failure and because there are a bunch of cases where you need an in-house mirror.
After easy_install-ing z3c.pypimrror you can use the pypimirror script for downlading all packages from PyPI (and as an option all external packages (experimental)). This requires roughly 4 GB of diskspace. After mirroring PyPI you can run a buildout against your local PyPI mirror. Right now I have full copy of PyPI available under http://pypi.zopyx.com. By default zc.buildout asks PyPI always when looking up a package. You can avoid that by the following configuration in your buildout.cfg:
find-links = http://pypi.zopyx.com
allow-hosts = *.zopyx.com
This configuration tells zc.buildout to also look for packages on my local server and to restrict any lookup to the hosts defined within the allow-hosts section - this works like a charm.
The local PyPI mirror also works nicely with easy_install:
easy_install -i pypi.zopyx.com <your package>
The Blackforest Sprint is coming to an end after three days of intensive working.
Some of the results in short:
- a new package z3c.pypimirror has been created in order to prepare a more reliable and fault-tolerant PyPI mirroring infrastructure for the future
- Jim Fulton, Christian Theune, Dieter Maurer and Laurence Rowe were working on ZODB issues. The foundation for several ZODB improvements like a more pluggable ZODB architecture have been laid. Other improvements like a better control over the ZODB cache sizes will likely pop up in next major ZODB release.
- Major progres has been achieved in the eggification of Zope 2.12 (Hanno Schlichting, Florian Schulze, Godefroid Chapelle)
- Andi Zeidler and Simon Pamiés were working on a Grok application where you can point to a existing Zope instance. It will fulltext-index all your ZCML files and provide a UI for searching through your ZCML configuration.
- The Devilstick team made significant progres on the project (sorry, but I don't know about the details :-))
Click here for some sprint impressions.
Starting today, SmartPrintNG V 1.2.0 and higher is available under the LGPL 3 license. There is no longer a difference between commercial and non-commercial usage. This means that SmartPrintNG is now free for commercial usage under the terms of the LGPL.
Are you dealing with lots of SVN externals? Are you impatient and don't want to wait for minutes until Subversion updates all your svn:externals one after the other?
You might look at zopyx.parallel_svn_externals_updater performing update operations on svn:externals in parallel (e.g. updates all svn:externals of a Zope 2.11 checkout in 10-15 seconds).
Although a lots of projects and companies moved from the CVS to Subversion, obviously nobody seems to be really happy with subversion.
My personal issues with SVN:
- Overlong URLs: for
copy/merge operations you always have to specify the full URL. This
requires copy/paste operations with the mouse...pretty annoying and
lame. With the de-facto directory structure (trunk, branches, tags) it
would be nice using relative paths like
svn copy . ../tags/1.0.1As a workaround you might look at sv which simplies things a lot.
- svn:externals: at the first glance SVN externals are a good thing for including external repositories or for emulating the old CSVROOT/modules mechanism. So far so god. The problem arises when you are trying to update a checkout with lots of externals. Zope 2 for example has more than a hundred svn:externals to reference to various Zope 3 packages. Updating a checkout takes very long (several minutes). The update process is serialized and can not update several external references in parallel (which would help a lot). The primary reason for the slowness is that SVN has to reconnect (through ssh/http) to the backend SVN server.
- Revision numbers: Revision numbers are are good for machines but basically meaningless for humans. In CVS you have the concept of a tag representing some state within the repository at a given time.. You refer the tag by a human-readable name that you can remember easily. Rembering numbers is much more painful (especially if you're older :-)).