Before I write a single line of code I want to build a thorough mental map of the jtapi standard. The first thing I did was print off the headers and study those. That only took me so far and raised some further questions. Now I’m reading the jtapi spec itself.
The jtapi spec is are the top pages and the headers are on the bottom.
It just goes to show how not often I print that I was surprised how many pages 79 pages are once printed.
My first instinct was to register libjtapi.com since .com is the ‘default’ tld and would be the easiest to remember. But once I was sitting at namecheap.com (which is much better than godaddy (Please do not ever use godaddy)) I noticed that libjtapi.org looks better. Then I started typing random open source projects + .org into the address bar:
My ratio of random tries to hitting the correct website was about 50-50. Which settled the internal debate, libjtapi.org it had to be.
My motivation for creating libjtapi.org was patio11’s “how to successfully compete with open source software”. Patio11 wrote from the perspective of proprietary software selling to consumers competing against open source clones. Despite Libjtapi being a open source library usable by programmers much of the advice still applies.
The general advice patio11 gives is to focus on what the software’s capabilities and the surrounding environment and not the software itself can do. That is to say: Our users do not have a jtapi problem, they have a job ticket problem.
Thus we need to talk about job tickets and their place in a modern printing system. We need to write targeted pages for each format as if libjtapi was THE solution for THAT job ticket. If they search ‘pwg job ticket library’ or ‘how to parse pwg job tickets’ they should arrive at libjtapi documentation for a pwg job ticket specific hello world.
This is an easy one. Much of my freelance work is setting up attractive wordpress sites. In the past year alone I’ve shipped upwards of eight wordpress sites.
The downside is that these beautiful wordpress themes are all closed source. One battle at a time.
Programmers prefer code so the hello world is going to be plastered everywhere. The homepage is going to open with a small paragraph about consuming & producing jobtickets with jtapi. Right below that will be the hello world. Each job ticket format page will contain a standard specific hello world. The site’s footer will also have the hello world.
On the download page below the link to the zip will be, you guessed it, the hello world. Bonus: there will be a link to download libjtapi_helloworld.c
Once visitors see the zip they’ll see the exact command line for creating a local branch of the bzr repository. Then a series of screenshots that document using the bzr explorer gui to create the local branch.
The end game goal here is to assure programmers that libjtapi solves their problem and get them to download us. Once we have users then contributors & bug reports will follow.
There is going to be a set of re-occuring problems. Some will be fixed in software, others will need documentation. When these get fixed we should make an issue of this. The site’s news section should re-assure programmers that libjtapi is active and getting better and better.
Every bug I fix will be one more reason to use libjtapi, it is one more mistake that libjtapi can save the programmer from committing.
One of the many reasons typical open source libraries’ websites are sub-optimal is that the website comes last. By creating libjtapi.org now at a time when there is no code and we do not need users or contributors the website will be well-established and ready for when we need it.
My workstation is similar to last years. I’m down to two monitors from three. The third monitor blocked my view of the window so it is packed into the closet.
This year my project, libjtapi, will being getting a proper repository along with the other openprinting bzr repos. I’ve also registered libjtapi.org which will host documentation and news for libjtapi. My intention is to run libjtapi as a full-fledged open source project.
Perhaps a bit verbose but the foomatic-db option’s human readable namespace refers to all the elements in our options that are meant for the end user. The foomatic-db data sets allow for multiple languages to be present in human readable elements. The issue is that only one xml in our repository uses this feature, the main proprietary Epson driver xml with its english and japanese comments.
Thus for all practical purposes foomatic-db is a mono lingual data set. This leaves downstream responsible for any translation.
Downstream may have an army of translators but they are going to have a hard time if the data set is inconsistent, ambiguous, and verbose. This is thus what I spent my remaining week of GSoC working on.
To do this I used Google Refine and a set of throw away scripts which created a csv with the xml filepath the human readable string.
With a global view of the namespace it became clear that it wasn’t as bad as I thought it would be. All Resolution options were consistently named, as were Page Size options, and others. Some things were simply misspelled or similar’arly spelled. Though in many cases I needed to do some digging to group things. In total I brought the total number of unique option choices from ~830 to ~740 with other uncounted improvements to readability. A brief and incomplete overview of the consolidation:
It wasn’t a major overhaul but hopefully this will result in more complete and helpful translations for end users.
*The user is already being shown a setting dialog. Visually the presence of a toggle or checkbox communicates that something is a setting. Appending ‘setting’ to a setting is thus redundant.