Time for revolution?

[rasmuswikman]

Since I entered the printing industry three years ago I've become more and more surprised (or horrified) of the shrewd relation between supply and demand. Since our business is all digital I don't really know if it applies to the "traditional" part of the industry aswell (offset etc). There are few free ($99 for a printer comparison report!) objective sources of information, and discussion forums (like this one) are only starting to get populated.

Four of my major issues with the suppliers (equipment providers) are:

1. The prices
It's hard to find information on who pays what (especially click costs). The secrecy lends me to believe that there is a large difference. And if there isn't, then why aren't they published? Born in the 80's I'm used to getting information about products BEFORE I buy them WITHOUT having to listen to sales people. (Yes, I bought my Volkswagen Polo by surfing on the net and without test-driving it, and I love it!)

Edit 2: What I'm really trying to say is that while I understand that the click-model is a good way of measuring the need for service, I think that the difference in price between monochrome and full color is too steep. It "forces" us to sell black & white while roughly 95% of our customers want color.

I'd like to see is a simple service like Pricerunner where we (anonymously) could fill in the details of what and to who we pay for software, hardware and service.


2. The competition
First they sell their services and machines to inhouse printing, second they come to us PSPs selling the same machines. Result? They've taken away the most profitable client segments and left us with scraps. And the print buyers are locked to them. With us PSPs as the middle hand, we could make sure that the print buyers are getting most out of their money by letting us choose on what equipment to print and where. I'm not saying that it's such a huge problem yet, but for example we're getting more and more clients that only want to buy covers for their presentations that they'll print and finish inhouse.

While HP recently has changed their strategy and is morfing marketsplash.com from a competing service to a assistive service, Canon has even announced that they are focusing their strategy to inhouse printing (according to an industry news site). If there was a healthy supply & demand on the market, then companies wouldn't have to resort to inhouse printing because with JDF the printing could be done outside the house.


3. Compatibility
While they all claim to have full support for JDF, it's absurd how hard it is to find information to evaluate compatibility issues. I haven't made extensive research, but the machines I've tried to find information about has made me sceptical to say at least;

EFI Fiery - When I tried to find information about the JDF Connector I was constantly made aware of the fact that I'm now on dangerous water and that I have to buy this and that product to make sure that everything works (or really; that they can squeeze a little more money out of me to make sure I don't have any resources to educate my personnel in using the software).

HP Indigo - They have SDKs, but I still feel like an intruder when I'm trying to find information. The only thing that makes me push onwards trough the "WARNING"-signs is that if I'm paying 300 000-500 000€ I do have to know EVERYTHING about potential issues.

Duplo 645 - Though they have no information whatsoever on software on their site (which I find quite strange since the software to control it is so incredibly simple), they have been very communicative and I have high hopes that I will eventually be able to send JDF straight to the machine.


4. Software (Edit 1)
With a background in web development I fear that the printing industry is in for a similar ride as the dotcom-boom. I haven't had time yet to really go through exactly how JDF is handled by different equipment, but my gut feeling is that the coding required to create a W2P/MIS/PPM is not very complex compared to the open source CMSs like Joomla.

So the only missing link is a coder writing a JDF/JMF/PPML-module for Joomla. With that in place, AFAIK it would then compete with industry leading systems like Hiflex.


Conclusion (Edit 2)
My conclusion is that while these issues would probably be OK in a normal situation and solved as the market matures, the competition from new media is pressing on and I believe that the only way to fight back is by cooperating.


Thoughts?

 

[carlmcdade]

Rasmus you still there?

Rasmus you still there?

I have recently come to the same conclusions that you have only two years later. If you or anyone else is interested I am going to put forth an effort to start an open source web to print project based in Drupal and Zend framework. The first step will be to create a simple plugin for creating PDF, PPML/GA and JDF files then connect them to an ecommerce soluiton.

 

[rasmuswikman]

Still alive...

Still alive...

Yeah, still alive.

And I've made the solution, full scale W2P with production management etc. All web based and open source.

I've of course made it only for my company, WhyPrint.eu, so it requires a bit of adjusting to fit into other workflows.

But working on documenting everything at the moment and is hoping to have a public demo online with complete source code at the end of the summer at the latest.

 

[carlmcdade]

Yep,

We already have such a solution and I am working on another one like it. The problem is open source requires a more generic approach. So I am going at this from the other end also by making companies fit their workflows to the open source software.

Personally I think that most software companies take advantage of the ignorance of the print industry. They sell software that is only one of or require workflows that are archaic in implementation. None of them seem to take full advantage of built in utilities that come with large digital presses.

BTW, are you in Sweden?

 

[rasmuswikman]

I don't see why it would have to be generic just because it's open source. Using Ghostscript as a RIP to produce dumbed down PDFs (that the client has to approve) and then JDF to submit to press or printer it should be there. Because of the lack of JDF in a number of smaller printers I've used LP via CUPS to print to those. Our package label printer is a black & white Xerox Phaser 4500. Works just dandy.

I built it our software from scratch using;

PHP with Apache on OS X as a base
TCPDF for imposition
Ghostscript for ripping (previewing)
CUPS for LP-printing
PHP XMLWrite for JDF-printing
jQuery for user interfaces

I've also made a design application to design print ready PDFs (and of course web pages at the same time since it's browser based) that I hope some coder will jump on to. It's quite buggy at the moment but we use it to design business cards and labels. Could be used for anything with some finishing touches though.

Personally I think the software companies know just as little as anyone else. Trying to merge the press industry with the print industry was a dumb move from the beginning. It's like merging the electric car industry with the fossile fuel one.

Calling digital printers "digital presses" is just plain marketing dumbness. They are still just digital printers. Nothing more, nothing less. And digital inkjet will eventually replace everything else because of it's versatility (why stick to ink and paper when you can print solar panels or biomatter?).

Speak Swedish but I hail from Finland, you?

 

[carlmcdade]

By generic I mean use of the subsets of JDF and PPML that work on several manufacturers machines. Right now the different flavors of JDF is a headache especially if you toss in Adobe products.

sidebar (I wanted to use CheckJDF to validate but found that the script for it is not available to non-members of CIP4, so much for the open source aspect)

I like your choices for you software. I am still testing TCPDF against Zend_PDF there does not seem to be a large speed difference but I am running PHP on IIS7.5 web servers. With Zend_PDF I am running straight to PDF (imposition and all) without Ghostscript or Acrobat Distiller. Using Zend framework also means fewer libraries (xml writer is built in too) with less worries about future PHP compatibility issues.

Jquery/HTML5 is my choice for front end also though the app we use now is FLEX/FLASH

I would like to take a look at your code and help out with the PHP. Let me know if you get it posted up to Github or BitBucket. I'll post a link to my Visio diagram later.

I am originally from Oakland California but I have lived in Sweden for about 16 years.

 

[rasmuswikman]

In my opinion it would be best to create a dynamic/editable JDF schema that could be added to and improved as the specification improves.

But then again, Adobe is really in the shitbucket at the moment. I don't think they'll survive that much longer. PDF is a crappy standard and with software moving online there won't be a need for that standard anymore. XPS is a lot better and have it's own Job Ticket (if my memory serves me correctly) for job submission. It will take some time, but most of the printed matter is new and old can be converted.

And Apple, Google and HP all have their own solutions; AirPrint, Cloud Print and ePrint respectively that doesn't use JDF at all.

LinuxPrinting are having some summer of code projects with regards to this matter, but I haven't really had the time to get to know the details.

So basically I wouldn't set anymore time than necessary on developing for the JDF standard. It's a behemoth and as such will die away, before it even get traction. Presses are so extremely expensive and require so much man power that automation is really just a nice thing, except for the really large printing houses, but they can also afford to customize everything and/or build from scratch.

I've never really tried Zend, don't like the idea of combining open source with proprietary. And Nicolas Azuni who develops TCPDF is a genius and because he's a one man army development has been at the speed of light for the last years.

This is probably a bit bittersweet symphony, but with HTML5 things are about to change again in the world wide west. And I suspect it's going to get really nasty this time around. For example Adobe doesn't have anything left to offer except advanced photo and video editing after HTML5 hits; Flash, Indesign, Illustrator will all be replaced by open source equivalents.

Going to post it as soon as I've made a developer reference and some demonstration movies. Since I've one-man coded the system it doesn't follow any "traditional" patterns, just got it done as quickly as possible.

Nice, where in Sweden? I lived in Karlskrona for two years.

 

[memonservices]

let's get something going today

let's get something going today

Hey guys, great points. Have you guys released any code yet? because I am interested in either starting something or contributing to an existing project.

A question for you guys, I noticed you guys were talking about libraries like TCPDF, Zend, Ghostscript etc. I wonder why go so far down the stack, many of these problems have already been solved and we just have to connect a few things together.

I mean we don't need to go down to Zend level to build a shopping cart when solutions like Magento or PrestaShop are mature and available. Or why would you create your own PDF authoring app when things like InkScape and Scribus exist (I realize they aren't browser based)