From the publisher's summary:

A comprehensive overview of Jewish History from Creation through the redaction of the Talmud, illuminating the intricacies and complexities of Torah tradition and philosophy according to the sages and classical commentaries, spanning the length and breadth of Jewish experience to resolve many of history’s most perplexing episodes, offering profound insights and showing their relevance to life in the modern world. An invaluable resource for scholars and laymen. A priceless tool for education and outreach.

How did the sin of Adam transform mankind and the world? How were the prophecies of Noah fulfilled through the rise of the Greek Empire? How did the builders of the Tower of Babel believe they could wage war against G-d? Why did there have to be three patriarchs? What was King David's crime regarding his involvement with BasSheva? Why did some Jews oppose the construction of the Second Temple? How can we trust the transmission of Torah if our scholars engaged in such fierce disagreements? These and many other questions are answered in this unique volume.

There's a far more complete manual that comes with the download, but these are the steps I used to generate the data for the webservices graphs. It assumes you've got a black and white image of the graph, with continuous lines for the data and orthogonal gridlines, and linear axes.

We'll use the bilirubin risk levels from the AAP bilirubin guidelines:

1. Open the digitizer

   You can't use Open with... from the context menu because the program expects filenames as part of the options; you can read the manual to see how to modify the context menu. Click Import on the toolbar: and select your image file:

   

   Save your work (it's a .dig file) often. You don't need me to remind you.

2. Set the axes

   Click Axis Point in the toolbar: and click on the origin (lower left corner) of the graph and enter the x,y values for the origin in the units of the graph (not pixels!). Usually that's (0,0) but can be anything. Click on the maximum of the y-axis (upper left corner), then the maximum of the x-axis (lower right corner).

3. Remove the grid

   Select Grid Removal... from the Settings menu. Select "Remove thin lines parallel to the axes" and play with the "Minimum line thickness" until the gridlines are gone from the preview on the bottom but the real curves are still there.

   

   Now the grid is gone and digitizing the curves will be easy:

   

4. Create curves

   Select Curves... from the Settings menu. Create as many curves as you need (we have three). Give them descriptive names if you like:

   

5. Digitize each curve

   Click Segment Fill in the toolbar: . For each curve, select it from the curve menu: and click the points on the graph for that curve until it is covered with points. There's no undo command. If a wrong point is included, use the Select tool: to select the bad points and use the Delete key. To add individual points, use the Curve Point tool: . In a few clicks, you have the fully digitized graph:

   

6. Set up the export

   If you exported the data now, you'd have lots of points; probably far more than is justified from the original graph. Decide which x-axis values should be exported (the program will interpolate appropriately if the digitized points don't land exactly). Select Grid Display... from the Settings menu:

   

   The values to be specified are related by count = (stop - start)/step so you only need to specify three; select the one you don't want to specify from the Disable dropdown menu. Make sure that the start and stop values are actually in the curve; the program will happily extrapolate off the curve but it's probably not scientifically legitimate. Ignore the y axis grid lines.

   Select Export Setup... from the Settings menu. In the Points Selection section, select Intepolate Y's at gridline X's.

   

7. Export

   Click the Export icon in the toolbar: . Pick a name and you now have a CSV file with your data. Simple, no?

So how to get the numbers off the graph? I emailed the lead author of the original paper, but haven't gotten any answer. I can pull the graphs as gif's from the PDF of the paper (thanks to OpenOffice.org and Sun's PDF importer; Adobe's reader seems to get more limited with each upgrade). I was afraid I would have to digitize the graph by hand; I read the cool article on Sudoku recognition and figured I could learn about Hough transforms to get the graph, and 2-D Fourier transforms to remove the gridlines, then blob detection to find the lines. Turning pixels into measurements would be the trivial last step. Sounds like fun, if I had an infinite amount of free time.

Luckily, I found Engauge Digitizer. With almost no time reading the manual, I had it removing gridlines, digitizing the curves on the graph, and exporting values at x-values that I selected into CSV files. It was close to easy. Not quite automated, but with only 4 graphs to digitize, I was done in half an hour. Highly recommended. With my remaining free time, I'll write a quick tutorial so I don't forget what I did.

Parsing the header is straightforward; the mime-types are separated by commas (note that the top-level separation is the comma, not the semicolon) and within each mime-type description the parameters are separated by semicolons. The first field is the mime-type itself (with possible wild card '*'), the second (if present) is the quality factor, "q={number from 0 to 1}" which describes how much the requestor wants that particular mime-type, and the remainder of the fields are other parameters.

As the specification says, parameters in the Accept: header are rare, and my programs don't use them, so we will ignore them. That means that Accept: text/html; q=0.8; level=2, text/html; q=0.2; level=1 is interpreted the same as Accept: text/html; q=0.2; not exactly the same as the spec but easier to code.

The q parameter technically should be weighted by how much the host wants to send that type. Thus, Accept: image/jpeg; q=1, image/gif; q=0.2 means "Send me a png; I'll accept a jpeg, but I'll be only 20% as happy." If the host feels that the gif is 10 times better than the jpeg, it should rank the gif as 10*0.2 = 2 and the jpeg as 1*1 = 1, and send the gif. My code doesn't have such strong feelings and ignores such niceties.

A q parameter of 0 should be interpreted as "never send me this type" but my code simply ignores it and, if there are no other mime-types in the Accept: header, sends the default. If it's the default type that has the q=0, then the requestor loses.

One subtle trick from Kris Jordan's Recess: wild card ('text/*' and '*/*') types should rank below more specific types with the same q parameter. We subtract 0.0001 from the stated q to push them lower; the specification says the value cannot have more than 3 decimal places.

function parseAccept ($accept){
	$mimetypes = array( // associate types with file extensions
		'*/*' => 'html',
		'text/*' => 'txt',
		'text/plain' => 'txt',
		'text/html' => 'html',
		'text/csv' => 'csv',
		'text/javascript' => 'js',
		'image/*' => 'png',
		'image/png' => 'png',
		'image/gif' => 'gif',
		'image/jpeg' => 'jpg',
		'application/*' => 'js',
		'application/json' => 'js',
		'application/xml' => 'xml'
	);

	$types = array();
	foreach (explode(',', $accept) as $mediaRange){
		@list ($type, $qparam) = preg_split ('/\s*;\s*/', $mediaRange); // the q parameter must be the first one according to the RFC
		$q = substr ($qparam, 0, 2) == 'q=' ? floatval(substr($qparam,2)) : 1;
		if ($q <= 0) continue;
		if (substr($type, -1) == '*') $q -= 0.0001;
		if (@$type[0] == '*') $q -= 0.0001;
		$types[$type] = $q;
	}
	arsort ($types); // sort from highest to lowest q value
	foreach ($types as $type => $q){
		if (isset ($mimetypes[$type])) return $mimetypes[$type];
	}
	return 'html';
}

The same sort of code would work for Accept-Encoding: and the other Accept-type headers.

I want to get it to parse the Accept: header, so users can leave out the file extensions, but it looks like browsers don't implement that correctly, so I'll have to keep using extensions as well.

I still need to learn more about caching and effectively using eTags and all the headers that go with it. It always makes my brain hurt.

When I moved this blog, I kept it updated, so I don't think it is vulnerable, but I completely forgot to remove the old one. I just changed the links to refer to the new one. Stupid! And now I've paid the price.

Well, we got just about everything restored from backups (missing some old announcements that I don't think anyone will miss), and I think I've removed any vulnerable code. I also am now the proud owner of some cool-looking hacking software that was installed on the site that I want to try to take apart and experiment with. Just more tuition paid to the school of hard knocks.

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

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]]> http://bililite.com/blog/2009/10/15/openoffice-org-fontdescriptor/feed/ 0 http://bililite.com/blog/2009/10/07/preventing-irony-deficiency/ http://bililite.com/blog/2009/10/07/preventing-irony-deficiency/#comments Wed, 07 Oct 2009 19:45:23 +0000 Danny http://bililite.com/blog/?p=1107 Today was the last day of a 3-month locum stint and they had a lunch for me. Ham and cheese subs.

And someone who knew what kosher meant brought in Cheezits (my main vice). But it's sukkot, so I couldn't eat those in the office either.

In all seriousness, I'm never offended when someone offers me nonkosher food like this, and I try to discourage people from trying too hard. It's a lot easier to politely decline something clearly nonkosher, than responding to someone who worked really hard at getting it right but missed one detail. "Here—you can eat this!" always elicits a cringe.

For those who don't see the irony in thanking an Orthodox Jew with ham and cheese, see wikipedia.