What changes when the grid becomes a plan

Neither of the two spreadsheets I have contains page numbers. Not a page-number column left blank, not one filled in for some rows and not others — no such column at all, in either file. The column evidence is here, field by field, if you want to see how little else the two agree on.

What they do have is the order the rows sit in. That order is the editor's first pass at a running order, made by a person thinking about the issue — this near the front, that against the back, these two apart from each other. It is the only placement information the document carries.

And it does not look like information, which is exactly why it gets thrown away. A column announces itself; a sequence just sits there looking like the order things happened to get typed in. An import that hands the rows back alphabetised, or grouped by section, has deleted the one part of the flatplan that was already there — and it will look like it did nothing, because nothing visible was lost.

I read the row counts out of the template this site hands out today: sixteen data rows on the articles sheet, eight on the advertising sheet. Then I imported it and watched the screen. What came back was a 24-page plan.

Sixteen and eight is twenty-four. A row is a page — that is the whole of the arithmetic, and it is worth knowing before you meet it. There is a page-count column in the file and it is carried through the import, so the extent you wrote against a row survives; but the length of the plan comes from counting rows, not from summing those extents.

Which matters the first time you look at a total that disagrees with your own arithmetic. If you have been adding up the page-count column in your head, the number on the screen will not be the number you expected, and the discrepancy is not the plan being wrong about your issue. It is two different questions: how many things are in the issue, and how many pages those things will eventually run to. The import answers the first one.

Four readings, from two exports of one issue, two sheets each. Declared rows is what the sheet says it has; the second column is what a read of those rows actually found.

A sheet exported from a spreadsheet tool routinely declares a thousand rows and holds thirty. On its own that is unremarkable — everyone who has ever scrolled to the bottom of a sheet knows the empty part is down there, and it costs nothing to ignore.

The fourth reading is the one that matters. Same kind of sheet, same issue, and it declares fourteen rows and holds fourteen. No padding at all. Padding is a property of a sheet, not of a file: one export in front of me has a padded tab and an unpadded tab sitting side by side in the same workbook. Anything that measures once per file and applies the answer to every tab is wrong on at least one of them.

Columns do the same thing sideways. One of the advertising sheets reported twenty-six columns; five of them held data. The other twenty-one are not columns anybody made — they are the width the file happens to claim, and they arrive looking exactly like the five that are real.

A thousand empty rows look like nothing when you open the file. To anything parsing it, they are a thousand rows.

The header row is located, not assumed. Nothing decides in advance that row 1 holds the column names; the rows at the top of the sheet are scanned in order and tested, and the first one that passes the test is the header.

The test has three parts. A candidate row must carry at least two non-empty cells. It must contain no genuinely numeric, date or boolean cell — a header is text, and a row with a real number in it is data. And it must be followed by at least one further non-empty row, because a header with nothing under it is not heading anything. The first row in the scan window that satisfies all three is the header.

The consequence falls straight out of the first part. A title row across the top of a sheet — the issue name, the month, whatever the file calls itself — holds one cell. One cell is not two, so it does not pass the test, and the scan moves to the next row. Nothing has been ignored and nothing has been let off: a title row simply does not look like a header, and the row that does look like one is found a line lower.

You can watch this run on the template from this site, which has its headers on row 2 with a title row above them and imports with its columns intact. That is the rule doing its job, and no more than that — I am not telling you the headers sit on row 2 for that reason.

One category, spelled three ways across two issues, arrives as one category.

The confirm screen shows the vocabulary the publication has accumulated, not only what is in the sheet in front of you — so the second issue you import gets the benefit of the first, and the third gets the benefit of both. When I imported into a new project, none of an existing publication's categories came with it. The vocabulary belongs to the publication, and it stays there.

A flatplan tool for people who actually make magazines.