iOS, PPML, and AFP

So after spending a lot of time with the various Apple developer platforms I see the potential to create some AFP-based tools for iPhones and iPads.

For one thing the Quartz system on iOS provides a convenient means to rasterize PDF and PS to bitmaps so its likely that creating an iPad or iPhone APP to convert these file types to AFP PSEG (Page Segments) would be fairly simple.

We already have the tools and infrastructure in place to do this...

The question is does anyone care?

The second element would be to allow viewing of something like a PSEG on an iPhone or iPad.  Again we have the code written and in production to support this if someone is interested.

(AFP PSEG files are basically like image files - just stored in the AFP format.  They contain image data like a JPEG or TIFF but the "wrapper" is different.)

I imagine there would be other types of viewers possible as well.  For example, a tool that read an AFP file and then displayed all the image content on-screen.  Again this would be easy to do as we have all the technology in place today - but would anyone care?

Lexigraph also has a PPML/PDF tool called Argon.  This allows you to take a PPML file and composite it to a PDF.  Again, because of Quartz, this would be simple to have on the iPhone or iPad.

Since the iPhone and iPad only work on wireless and don't have easy access to traditional means (like FTP or SMB) to easily share files the only easy way to use it would be via a web page.  Thus a potential user would only be able to access content (AFP files or files to convert to or from AFP) via a web page.

A full AFP viewer is probably out of the question at this point.  There is some opensource work in this area and there are some partially functioning viewers.  So it would be possible to get an iPhone-based app up and running for full AFP...

Just some business thoughts...

(cross posted on Lone Wolf)

PDF - Technology to Live Without?

See it at PDF Outsider.

Interesting color problems...

Its been a while since I posted here - mostly because not much is happening right now business-wise in the industry (I think people are biding their time waiting to see what happens in the economy).

At any rate here's an interesting color story....

A few months back I get a call from a customer - its the operations folks down on the shop floor.  They tell me that the RIP is failing to properly process the files because there are "ghosting" and "shadows" around the fine strokes on small black text.  They say this is an on-going problem and its happened before and could I help them fix the RIP...

Only one problem with this - we didn't sell them any RIPs...

So I get on the phone and talk to the operator - always a challenge for a variety of politically incorrect reasons.  Eventually I tease out of her the specifics - fine black lines in images have halos of C, M and Y around them - basically as reported.  So I ask - is this on all the work on some of the work - only on one type of job on one kind of logo is the reply.

So I stop and think for a minute: A) they are not our RIPs, B) we have a process that creates image content, C) there is a workflow to prevent CMYK black.  This particular system has been running live for at least a decade in one form or another so I am not about to dive in and start changing any settings without some very careful thought.

The RIPs in this configuration pass CMYK as-is, i.e., don't remove CMYK black, because sometimes there is need for it.  So turning it off in the RIP will invite untold production disaster fifty midnights from now.  Plus its been set this way for a decade and so far this is the only problem we have been called on.  My buddy checks the RIP logs and we see no signs of tom-foolery with settings, etc.

Next I get hold of a logo that's causing the problems in source form, i.e., a PDF.  Sure enough there's CMYK-black tiny text (six point).  So now we've tracked down why the press is doing what it does.

So I call the vendor of the press and explain to the tech how its not really their issue (save for any alignment issues they may have on their own).  He doesn't know enough about us to understand we didn't sell the RIP so he's been thrashing for a day or two trying to fix something that's not really broken.

Since the actual logo creation processes is out of our hands I talk to the big boss and explain what's wrong.

Fast forward to today...

I get an email from the press vendor explaining a service call for the exact same issue has come up.

This time we can save an airfare and a few days on site diagnosing nothing because the new guy from the press vendor is on the ball. 

The wonder of transpromo...

We are talking about this over a Lone Wolf today.

AFP plays (and has played) a role here.  I think that the "printing industry" is, or, rather, is trying to co-opt this.

For me AFP content creators are in a much better position to "own" this industry....

PPDs, Clouds and AFP...

Over on the Lone Wolf I have been talking about the Google "Cloud Printing" nonsense.  Part of this discussion was a mention of PPDs.  In my past PDF-based life, particularly in the age of Windows PPD's caused no end of problems related to generating incorrect output.

I am not going to go into the details of PPDs here or the specific problems they caused.  Instead I am going ponder briefly about their function in AFP - if any.  On Windows a PPD told the printer driver what the paper size choices might be, what the print device capabilities were, and so on.

At any rate, as for AFP and Cloud Printing.  It would seem that cloud printing would be the antithesis of AFP - particularly from the aspect of ensuring that output was printed correctly. 

So let's take a look a the google interface for cloud printing:

Well, this is informative.

I think its crucial for AFP users like banks and financial services companies to see how well organized and thought out this print process is - particularly in the context of "remote printing" (remote meaning I print from the cell phone or PDA).

I think the most glaring error in all this is the "Printer Errors" path.  Now, let's suppose I am out at some offices, say for example Google's offices, and I have my handy PDA on which is my important contract.  Now, in the cloud world I suppose that I could just wave my PDA around and find a locally willing printer for my job - at least one that isn't too particular about who prints to it.

So, with the printer in hand, so to speak, I print my contract.  But, as is often the case, a paper jam occurs.  Now what?

Well, I imagine that on my PDA will be the small unhappy face (the opposite of the "happy" face linked to the ERROR box).  So my important contract is now laying in some output bin - half printed - for the cleaning people to find.

I guess now I have to grab my GPS (or use my PDA GPS) to find the printer - where ever that might be.  Let's just hope I didn't accidentally print the job in the next state.

Enough sarcasm.

I surely hope Google does not try and enter the commercial printing arena.

PPDs do a bad enough job handling things as simple as output bins and stapling.  One can just imagine the agony of trying to navigate a print-style dialog on a PDA or cell phone.

Now imagine AFP bundled into the mix...

I think its probably safe to assume that AFP and "Cloud Printing" will probably not mix - except perhaps in the heads of marketers - for a long time.

Patent war update...

Follow it here.

AFP and the web...

We are currently working on getting our web servers and browsers to support AFP content, i.e., you can go onto a web site and if you have the right plug-in loaded in your browser you can directly view AFP that's linked.

So we need to get MIME type of 'application/afp' working I guess - we use IIS so there is no doubt some unpleasant nonsense involved with that.

We have been working on some demo web stuff and we have the various browser plug-ins working so now we need to get them working together.

My hope is to announce this all soon in some public way but I would like to have this working before hand.