So where are we, exactly?

Been quiet for a while, sorry. I spent several days doing the initial stages of post-proofing a moderately complex book, using the current PPQT2. In the process I found and fixed several minor bugs. By the end it was working quite smoothly, fully the equal of V1. I can use this tool. And will, if I can just get it finished and shipped.

Concurrently with using the program, I was documenting it. I already set up the help file, but that is a summary organized around the UI: menu by menu, panel by panel. An equally important, perhaps more important document is the task-oriented "suggested workflow" document. That takes the reader through a step-by-step process of post-processing a book, showing how to apply the features of PPQT to perform each.

There was a suggested-workflow for V1, of course. For V2 the initial work steps are the same with only minor changes due to changes in the menu structure. But being an obsessive scribbler I had to rewrite them anyway to be easier to read and more terse.

But a number of changes come in the sequence of later steps. V1 has its own ASCII reflow and HTML conversion built-in. For V2, both of those functions are handed off to Translators (that have yet to be written to an API yet to be implemented). I expect that the most-used Translators will be ones that convert to Ppgen and to Fpgen, markup languages unique to DP and DP-canada respectively. Those markups are used to feed into batch conversion apps that produce the ASCII, the HTML, the EPUB. So the documentation has to assume that the user is aiming toward a smooth conversion to another markup -- not aiming toward generating the final product within PPQT2. (Of course, I expect the user will continue to edit the Ppgen/Fpgen document in PPQT2. There are several advantages to doing so. But the responsibility for generating HTML, or for properly formatting an ASCII etext, falls on that package and on its documentation.)

Anyway, this changed my approach in documenting the tasks of post-processing. But I got that pretty well done.

On the shipping front, which means bundling a Python app as a self-contained package, there has been some progress. Hartmut, the top maintainer of PyInstaller, stepped up and took over the task of rebasing the Python3 code branch onto the current Develop branch. Or so it seemed...

Today I applied the latest PyInstaller to generating a Mac app, and it worked splendidly! If you want to try it, here's the link. So that was good.

Then I moved to Ubuntu. Downloaded the Python3 branch and installed it, ran it, and hit exactly the same problem (the bundled app dies looking for "orig-prefix.txt". If I hack around that, it hits another problem. Both come out of the same little stretch of code in compat.py and hook-site.py. When I compare these two source files between the Develop and Python3 branch, they are very different. Why? I thought when Python3 had been rebased onto Develop, these issues would disappear. I put a query on the PyInstaller list and stopped for the day.

Dang, so close.