Document Liberation Project announces initial QuarkXPress support

Document Liberation Project announces initial QuarkXPress support

The Document Liberation Project (DLP) announced the first release of libqxp, a library for reading QuarkXPress 3.3—4.1 documents. And this is one hell of a trip down the memory lane.

The initiative is a perfect fit for the project's agenda to implement support for as many legacy file formats as possible (see our earlier interview with Fridrich Strba et al.), although the timing is a bit of a puzzle.

History lessons

QuakXPress was once the king of desktop publishing, with reported 95% of the market share at its highest point. But corporate greed, overconfidence, and lack of vision pretty much killed it in early 2000s, and Adobe InDesign nailed its coffin.

A typical comment to the Ars article (linked above) on the subject looks like this:

We hated Quark, the program and the company. But of course we used it because it was ubiquitous. InDesign 1.0 wasn't great, but we were so desperate to move away from Quark that we slowly converted.

From many discussions on the web regarding Quark and Adobe it looks like QXP users mostly got their closure in 2003—2004, when Adobe's Creative Suite 2 arrived and settled in, although some sticked with Quark's software through v5 and v6.

Ever since Adobe introduced subscription-based model in 2013, there's a somewhat popular notion that Adobe is the new Quark and it's on the road to failure. However, after initial setback in 2013 and 2014, the company's financials have been steadily growing, in terms of both revenue, net profit, and net income. And since introduction of Creative Cloud in May 2013, Adobe's stock price is up by ca. 230%. So it looks like they need to try harder to fail.

Although Quark has been trying to bring back the former market share by any means deemed necessary, they haven't been very successful. The company eventually refocused on automating content creation, management, publishing, and delivery. There are very few businesses around that still run once popular QuarkXPress, let alone the versions from 15—20 years ago which DLP focused on. Which brings us back to the actual topic at hand.

What's in libqxp 0.0.0

The newly released first version of the library is the result of several months of work by Aleksas Pantechovskis, a student from Lithuania, who participated in the Google Summer of Code program this year (again).

Aleksas already had good track record with the Document Liberation Project. Last year, he wrote libzmf, a library for importing Zoner Callisto/Draw v4 and v5 documents.

In this initial release the libqxp library reads:

  • pages and facing pages;
  • boxes (rectangles, ellipses, Bezier);
  • lines, Bezier curves;
  • text objects, including linked text boxes and text on path;
  • font, font faces, size, alignment, paragraph rules, leading, tabs, underline, outline, shadow, subscript, superscript, caps etc.;
  • colors (including shades), gradients (linear, radial, rectangular);
  • line/frame color, width, line caps and corners, arrows, dashes;
  • object groups;
  • rotation.

Some rather important features like custom kerning and tracking aren't yet supported, because OpenDocument file format doesn't support those. But that's not much of an issue, according to Aleksas:

librevenge is just interfaces, so if there is another output generation lib instead of libodfgen for format that supports them, then it can use any attributes passed to it.

One big missing part in this release is support for image objects, because, Aleksas says, the picture format seems to be quite complicated.

Development of libqxp sits on top of reverse-engineering work started by Valek Filippov in OLE Toy in 2013 and continued by David Tardon and Aleksas in February 2017. Although libqxp sticks to ancient versions of QuarkXPress for now, OLE Toy can parse some of the data in QXP v6 and v8 (it's encrypted since v5), so this might change in the future.

LibreOffice has already been patched to open QXP files, this feature will be available in v6.0 (expected in early 2018). The library itself ships with the usual SVG converter which you are likely to find of limited use. Also, if all you need is extracting text, there's a perfectly sensible qxp2text converter as well.

Support in Scribus

One would rightfully expect Scribus to be the primary beneficiary from libqxp. But here is some background info.

First of all, the history between Quark and Scribus is rather hairy.

Initially, Scribus was pretty much modeled after QuarkXPress, and the two projects still share some similarities. Early in the history of Scribus, it made a lot of sense to introduce support for QXP files. Users got mad with Quark's continuous quirks and bad user support, they would jump ship at the very next opportunity.

Paul Johnson, former Scribus contributor, actually started working on support for QXP files in 2004. But after he had posted to a public mailing list about his progress, he reportedly received a cease and desist letter from Quark.

Scribus was nowhere near its current fame at the time, and even now it would not be able to handle legal expenses (save for a theoretical FSF intervention). Back then Paul just stopped working on that project.

Quark didn't quit monitoring Scribus though and continued tracking the progress of the project to the point where developers jokingly discussed blocking Quark's IP addresses range from accessing Scribus's source code repository (they reportedly had logs of that). Eventually Quark turned their attention towards more pressing matters like losing their market share to Adobe.

Today, much like LibreOffice, Scribus supports both ubiquitous file formats like IDML and bizarre ones like those by Calamus and Viva Designer. It even has support for Quark's XTG files. Getting a QXP importer would also perfectly fit Scribus's narrative.

The team is well aware of the libqxp project, they already have experience writing librevenge-based importers for Corel DRAW, Microsoft Publisher, Macromedia FreeHand etc. So it's likely just a matter of time till they introduce QuarkXPress importer.

Is there any closure left to get?

Was it useful? There's more:

7 Responses. Comments closed for this entry.

  1. On support of newer versions of the format: Note that what OLEToy reads is just the top-level “container” format (a qxp v1-5 doc consists of one or more chains/streams, which in turn consist of blocks, whose size is a multiple of 256 bytes. The most important chain is “document” (contains all styles, colors, pages, etc.), but there can be also text info and picture chains, one for each story or picture. The chains’ blocks can be—and usually are—interleaved.) This is what OLEToy could read from v3-4 docs in January, before I started the “real” rev-enging. And this is what we do have for v6+ now, except that the structure appears to be sligthly more complicated. But I suspect the encryption/obfuscation is going to be a tougher problem… (Btw, v3-4 already uses obfuscation—or encryption, if you want—but only for some crucial values, e.g., the number of objects on a page.)

    OTOH, adding support for older versions is very easy. All that prevents it is lack of sample docs: I do have QXP 1.10L and 3.1, nothing in between. Support for v1 is about 75% done; it took me just a couple of hours to write the code…

  2. On qxp2text: it’s a matter of opinion whether the tool is “perfectly sensible” .-) I suppose it works well enough for simple documents, but it’s problem is that RVNGTextDrawingGenerator is a simple stateless processor of the librevenge API calls, so it outputs the text in the order the library emits it, which is not necessarily the expected one. What it should do is to order text objects by their position on the page and z-index; it should also follow—or at least allow to follow—links, to put stories together. But that would require at least a simple page model and delayed output, which would have to be implemented by someone .-)

  3. Thank you for the clarification, David!

  4. Sure, Adobe’s financials are looking remarkably good these days. But if you read that Dave Girard article you linked to on Ars Technica, you will see the level of ill feeling that is steadily building up among its users.

    Adobe is steadily turning into another Quark, and the time will soon be ripe for another InDesign-style upset. It would be good if the Free Software community could do something to prepare for that.

  5. Alexandre Prokoudine 12 September 2017 at 12:59 am


    It might be nice, yes, however Scribus is maintained by just two developers these days (who made 90% of commits for the last 12 months).

  6. “Maintained” might be a misleading word here. The truth is that we released 1.5.3 as a stable development version, which means only reliable new features and bugfixes will make their way into the 1.5.4svn branch. These are always filtered through the two developers you mentioned.

    Just like the new text layout engine in 1.5.3, however, the next big step (Indigo Dock) is being developed in a separate branch, because the changes are too massive and disruptive for those who already moved their production to 1.5.x.

  7. I think we want to avoid cloud services.