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:
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.
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 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.