Hacking at 0300 » OpenOffice.org

Column Widths in OOo Tables

Danny — Fri, 16 Oct 2009 06:07:13 +0000

Finding the width of a column in a table in OpenOffice.org writer is a bit of a black art, because the widths aren't stored anywhere, just the relative widths in arbitrary units. And if cells have been combined, then the object model has no concept of "columns" and there is no way to find the widths of cells. But, based on the table tutorial, I've written this function:

function colwidth (table, index) ' index is 0-based
	' need the table to be oriented (http://api.openoffice.org/servlets/ReadMsg?list=dev&msgNo=12552) 
	table.horiOrient = com.sun.star.text.HoriOrientation.LEFT_AND_WIDTH
	' tricks from http://wiki.services.openoffice.org/wiki/API/Samples/Java/Writer/TextTable
	dim n
	n = table.columns.count
	if index >= n then
		colwidth = 0
	elseif n = 1 then ' single column table
		colwidth = table.width
	else
		dim ratio as double
		ratio = table.width / table.tableColumnRelativeSum
		dim pos
		pos = table.tableColumnSeparators
		if index = 0 then
			colwidth = pos(0).position * ratio
		elseif index = n-1 then ' last column
			colwidth = (table.tableColumnRelativeSum - pos (ubound(pos)).position) * ratio
		else
			colwidth = (pos(index).position - pos(index-1).position) * ratio
		end if
	end if
end function

OpenOffice.org FontDescriptor

Danny — Fri, 16 Oct 2009 05:57:00 +0000

OOo controls have a Struct FontDescriptor that contains all the information about the text (font name, point size, etc.) so one would hope that to make an editbox have the same font as the containing text range, all you would have to do is

textField.fontDescriptor = textRange.fontDescriptor

but no such luck. FontDescriptors apply to everything but actual text; text has all those properties as part of the CharacterProperties service, so each property has to be accessed separately:

fontDescriptor = textField.fontDescriptor
fontDescriptor.name = textRange.CharFontName
fontDescriptor.height = textRange.CharHeight
' etc.
textField.fontDescriptor = fontDescriptor

Note that you can't do textField.fontDescriptor.name = textRange.CharFontName, because Structs are always copied. Even if it makes no sense.textField.fontDescriptor.name creates a temporary copy of textField.fontDescriptor and modifies its name, leaving the original textField.fontDescriptor untouched

OOo Tutorial on Exporting to PDF

Danny — Tue, 06 Oct 2009 09:47:18 +0000

There's a great tutorial on exporting from OpenOffice.org Writer to PDF, but as far as I can tell it's orphaned on the openoffice.org website; there's no link from the tutorials page. It documents all the properties of the export filter and goes through the process in great detail. Hopefully the link from this blog will help keep it from staying orphaned.

OpenOffice.org quirks

Danny — Wed, 23 Sep 2009 01:13:47 +0000

Some of the first things I needed to get straight to move from Microsoft Office scripting to Open Office scripting:

The BASIC isn't quite compatible: I know the object model is completely different, but even the underlying language isn't quite the same. I wanted to use the InStrRev function, but it wasn't there! Then I found option VBASupport 1 which puts it in. It's (as far as I can tell) undocumented but mentioned all over on the web. I'm not sure what else it changes (again, in the language, not the object model).
The name of the program is OpenOffice.org; evidently Open Office is trademarked by someone else. I'll do my best to comply.
Sizes are in hundredths of a millimeter (dekamicrons? abbreviated as daµ; I can't find anyone using a better abbreviation), so my code has a lot of x = y * 2540/72: 2540 mm per inch, 72 points per inch.

Inserting control elements is more complicated than I would have thought; the object model divides them into "model" and "view" and figuring out which properties belong to which takes some searching and experimenting:

	Dim rng as com.sun.star.text.TextRange, checkModel, checkbox
	checkModel = doc.createInstance("com.sun.star.form.component.CheckBox")
	checkView = doc.createInstance("com.sun.star.drawing.ControlShape")
	checkView.control = checkModel
	rng.Text.insertTextContent(rng, checkView, True)

Diving into OpenOffice.org

Danny — Wed, 09 Sep 2009 02:41:38 +0000

My hospital isn't fully electronic yet; they use a hybrid system where doctors notes and orders are written on paper, to be scanned into the electronic chart at the end of the patient's stay. Everything else (nurse's notes, labs, radiology results) are electronic. It actually works pretty well, with most of the advantages of an EMR (Electronic Medical Record) without forcing the older doctors to use the computer. That's coming, of course, but it won't be pretty.

But those of us for whom the computer is mother's milk, and whose handwriting is somewhere between chicken scratch and Linear A, we'd rather do it all online. I've been writing my admission notes for a few years with a Microsoft Word template, printing them out and putting them in the chart, with nary a problem. And the medical records department clearly used PDF's for the pages, both the blank order sheets and the preprinted, fill-in-the-blanks "standard orders" since they were available on the hospital intranet. So let's create PDF's with actual editable text boxes and check boxes (these are mockups, but they look right):

The response from medical records: not an option. It's too hard, inserting all those textboxes by hand on all those lines, and they don't "possess the very expensive software that makes this possible." They had to go to the graphic arts department to use their copy of Pagemaker. And any change means having to put all those controls back in the form again, by hand.

Never tell me something on the computer is impossible. I have teh l33t hax0r ski1z! The expensive software problem is easy to solve; OpenOffice.org Writer can generate PDF's, and a little experimentation shows that form elements are preserved. The "too hard" problem should be solvable, too; Writer is scriptable and I've scripted Microsoft Word with VBA often enough; how hard could it be?

Famous last words.

Scripting Microsoft Office is like pulling teeth; Basic is verbose and tedious, and the documentation for the object model is sparse. But scripting OpenOffice.org is like pulling teeth with your eyes closed. The documentation (the bane of all open source software) is virtually nonexistent; the macro recorder (so useful for Microsoft Office) records the user interface interactions, not the underlying object model; and there is no object browser to explore the methods and properties of each object (there is the xray tool to look at objects one at a time as part of a macro).

So I just went to the documentation wiki and dived in, spending a few hours browsing, trying to find a place to start. I'd recommend the BASIC guide and the Introduction to UNO, which is Sun's answer to Microsoft's COM and the basis for the OpenOffice.org document object model, then the BASIC Binding chapter to put them together. The documentation of the object model is near impossible to find but it's there.

You really need to be able to read Java to understand the rest of the documentation, since both the examples and the underlying concepts are in that language. I wouldn't use anything but Basic, though, since it abstracts away all the underlying interface querying and dispatching and type casting.

The code I developed is here; I'll blog about the things I learned as I get the time.