AUTOMATING UNIX APPLICATIONS in Objective-C

Printer QR Code ISO/IEC18004 in Objective-C AUTOMATING UNIX APPLICATIONS

Line 10 checks to see whether there were any fonts found in the PDF. The first two lines of the result string are table headings, so you ignore those. If it contains more than two lines, you can start extracting the data from the remaining lines; otherwise, you just let the user know that no fonts were found. In line 11 you create a list that includes all the paragraphs of the result, starting from the third paragraph (paragraphs 1 and 2 are the title and underscore). Once you have the list, you loop through each font information line and pick out the information you need. Although the finished solution looks simple enough, coming up with one that will work reliably isn t always as easy, so let s look at how this one was arrived at and some of the potential traps discovered along the way. As is common for command-line tools, table-style data isn t presented as simple tab-delimited text but arranged as vertical columns designed for viewing in a monospace font on a command-line display. This sort of format is rather trickier to parse reliably because the number of spaces between each item in a table row will vary as the application tries to arrange everything into vertical columns. If you re lucky, the columns will all be fixed widths that never, ever change, in which case you can extract the bits you want using references like this: text start_position thru end_position of the_line Unfortunately, this is not always the case. For example, if a left column contains a long value, then all the remaining columns may be pushed to the right to fit it in. These sorts of issues often aren t obvious at first glance, so be careful; otherwise, you could introduce all sorts of subtle, hidden bugs into your code. Faulty code that happens to produce correct results most of the time but occasionally slips in an incorrect answer can easily often go unnoticed for a long time if it doesn t cause an actual error. In this case, testing pdffonts with a PDF file whose font names are known to be longer than 37 characters (the width of the first column) quickly shows that this approach won t be an option here. Another common way to break down these sorts of tables is to use another Unix application, awk. awk is a basic pattern-matching language for identifying and extracting sections of data from a single line. It s ideal for dealing with command-line table data where spaces appear between items but never appear inside them because it treats any number of adjoining spaces as a single divider. For example, to extract the third column from such a table, you would pipe the table data from the previous command into an awk command like this: some_command | awk '{print $3}' Alas, this won t help you either because the values in the second column of the table may often contain spaces (for example, Type 1), so a value that appears as item 3 on one line could be item 4 or 5 on the next. Still, it feels like you re getting closer to a solution, doesn t it Looking at the columns on the right, notice that they re all a lot more regular; therefore, I reckon you ll be OK if you count columns from the right instead of from the left. Using awk would be trickier here because it normally counts from left to right. However, the values in the right columns are all either numbers or words, so you should be able to get the one you want using a word -5 of... reference in AppleScript. Problem (you hope) solved! Once you ve extracted the desired yes/no value from the line s Embedded column, you can see whether it s a yes and increment the value of embedded_font_count if it is. This happens on lines 16 to 18. Finally, on line 20, the finished message is assembled and displayed.