Glom: Print layouts

As mentioned before, Glom needs a more precise way to specify print layouts, for instance to print on a pre-printed form. I’m looking at the problem again. At the same time, Johannes is working on a prettier drag-and-drop UI for Glom’s regular (automatic) view layouts.

For now, I think I’ll start with text areas that don’t move or shrink depending on their content. But for later I would like to gather some examples of how other software does this. I wasn’t impressed with what I found, though FileMaker is the best of the bunch:

FileMaker print layouts

FileMaker offers two ways to achieve this: You can use the <<fieldname>> placeholder format in static text, or you can specify that a field’s text box will be moved left, right, up or down until it hits another box. Both techniques can be seen in this screenshot:

FileMaker designing print layout

Kexi print layouts

Kexi (version 1.1.3) doesn’t seem to have any support for printing, but please correct me if I’m wrong. (Update: It doesn’t support printing of details forms – the print menu is grayed out in that case. It does support printing of list views, though the result is arranged differently than what’s on screen. It has a reports feature, available under “queries”. For me, a report is for multiple records, not a single record, and I’d like to keep them separate to keep things simple.) However, the regular layout is pixel-perfect rather than automatic, which would be suitable for precise printing, though awful for all other situations.


Knoda print layouts

Knoda (version 0.8.3) seems to support printing, but I didn’t find any features to support flowing of variable sized text. Its layout is pixel-perfect rather than automatic, as with Knoda and Access.


Microsoft Access

It looks like Access (the version in Office 2007) also doesn’t have special printing support. I think you are just meant to design a regular custom form and print it. But I couldn’t find a way to print an invoice in their “Northwind” example, so I’m guessing. The regular layout is pixel-perfect, with the ability to make widgets stretch to fill available screen space, with the new “Anchoring” feature in Access 2007.

As seen in this screenshot they also use an invented markup (or mini programming language) to show data, as in FileMaker, but it’s even more complicated here.


libgda reports

libgda has some reports support (example). It uses custom XML tags (and a custom mini programming language for conditionals) to replace XML nodes (arbitrarily named, without any libgda prefix, it seems, such as <row>) with query results in, for instance, DocBook. So that’s not really useful for the precise layout problem and seems targeted more at multiple rows reports rather than single record printouts. Glom already has its reports feature which seems equivalent, though it is more integrated with Glom concepts such as Relationships and Related Fields.


What other systems should I look at? Note that I’m not interested in anything that requires the user to edit XML or SQL queries, though it’s possible that I could reuse some of that implementation some day.
By the way, having to use all these other systems for a while convinced me once again how badly Glom is needed. They are so unnecessarily low level and complicated, instead of directly helping people to achieve their actual goals.

13 thoughts on “Glom: Print layouts

  1. You absolutely need to take a look at Clarisworks/Appleworks’ database layout manager. Some small screenshots:

    My father still swears by it, every time he makes a new database. The layout is shared between on screen (for the “application”) and printout.

  2. Bastien, that’s very much like FileMaker. It might even be based on an early version of FileMaker, which has been through various owners, including Apple.

  3. I am here to correct you.

    Kexi obvously supports printouts from version 1.0 since april 2006. Try to use standard File->print, File->print preview menu. In particular unlike other office apps, tt supports massive printouts (thousands of pages without blocking the GUI).

    More at: and

    Moreover, forms are not designed for printing in _any_ app. If glom or gnome tries t ouse them for printouts, I consider this as bad decision. Reports _are_ the tool for printouts (therefore, no idea why you mentioned that MSA has no printounts). One of most important reason for this is that forms are pixel/screen-based and printing is point/paper-based.

    I’d be grateful if you update your blog entry, not only in case of Kexi.

    regards, Jaroslaw Staniek

  4. Jarsolaw, I added this text:

    Update: It doesn’t support printing of details forms – the print menu is grayed out in that case. It does support print of list views, though the result is arrange differently than what’s on screen. Apparently it has a reports feature but I couldn’t find that. For me, a report is for multiple records, not a single record, so I wonder how this looks.

    Please avoid irrelevant advertising links in your comments. I’ve edited them out.

  5. For the report layout capabilities you might want to take a glance at Eclipse’s BIRT and and Jaspersofts iReport (for JasperReports).

  6. For Libgda, I’ve had a look at RML which allows flowable areas and has a lot of features. The transformations workflow is then:
    RML file + gda specific tags –(gda report engine)–> pure RML file –(rml2pdf)–> PDF file

    The drawbacks are that:
    * the rml2pdf transformer seems not really maintained and not up to date with the latest RML specs
    * there is no graphical editor

    If you do a graphical editor for Glom, I’d like to be able to use it from within libgnomedb…

  7. One of my projects, PDF::ReportWriter, could help you out. Currently, you *would* have to edit some XML ( SQL ), but I am currently doing about as much work as I can on a GUI builder. I’m also half-way through rewriting my website. The old site is at: and here you can download stuff and check out some simple XML report definitions and PDF output. The new, incomplete site is as and the main reason you’d go here at the moment is for the screenshots of the new GUI builder ( hit the ‘future’ link ) which are relatively up-to-date ( it changes fast these days ).

    All 3 projects are designed to replace MS Access, and are all open-source and cross-platform. They’ve also all been in production use for a number of years.

Comments are closed.