Web-to-print workflow for newspapers (SoC proposal)

I would love to be involved with this project. We currently have a need within our organization for a simple web to print solution. We currently have about half of our staff who have access to computers daily and another half who only interface "when it is needed". As a rural telco, many of these people are out on the roads a lot and and can spend time reading while riding from one place to the next. Being able to take local intranet information and push it too a printed form would be wonderful.

What can I do?

tmg-studio (Jamie)

I posted a proposal and design of an import export framework for summer of code. I think this web-to-print workflow could be implemented using that framework, so you would only have to develop the higher-level processes for pulling together lists of things you want to publish, then you could assign an export type and send them to the export module.

If you have a chance, check out the post entitled "create modular, extensible, API-based import and export framework for drupal" - I think it shows up in the newspapers group, but also is in the SoC 2008 group (I am new to these groups).

It is lower-level than this, but it is designed to abstract out the importing and exporting of data, and I think it might make sense to consider coordinating these two projects.

For PDFs, etc., this import/export framework way of dealing with the nuts and bolts of your export would let you abstract out the part of the process that formats the output, so that you implement the part that deals with setting up the exports, then just assign an output format type from the export framework. This would enable you to add in different formats as modules and then just pick a format type when you set up a given channel (I'd recommend enabling this to store multiple output channels, not just one, so you can output some things to print, but also output some things to blog software, an archive system, etc.). It would also enable you to just change the export type if you have to change pagination systems (or archive systems, or blog software) without having to change any of the other settings for a given channel.

You could consider integrating XSL:FO into your project regardless. It can be a little tough to generate the XSL:FO, but once you have it, you can convert to PDF, printer control languages (these are the native formats that printers speak, like Postscript, which files are converted to when they are printed - when you print a PDF file, for example, it is translated to a printer control language before it is sent to the printer) and many other formats (I know apache's FOP XSL:FO transformer is in good working order for Java - http://xmlgraphics.apache.org/fop/. I don't know if there is a good equivalent for PHP.).

1 > Web-to-print does not mean that your online and offline content should be the same. You can put additional content for the web in different cck fields that you don't include in your print version. (This is how we do it at this moment.) Or, a bit more advanced, you could work with a tag to indicate content that the export should filter out but that is still displayed in the online version. That might be worthwhile to include in this project, so that's a good suggestion. Video captions shouldn't be a problem as the preferred method using Drupal is with a CCK video field rather than inline anyway. Hyperlinks and other tags that you don't need in print don't pose a problem either because you have to allocate tags to styles anyway in DTP-software, so if you don't define a special style for hyperlinks, they are displayed just like regular text. And ligatures (fl, ff, ...) do not need to be specified in the XML, the dtp-software takes care of those.

2 > Exporting to print, in my proposal, isn't the last step (that's just one possible workflow). If you set up an automatic export your print version is in sync with what is online, so the dtp-staff can start working as soon as there is a rough draft of the article available and stop updating the XML when the deadline is near and the final touches need to be made. I'm not sure how that would work for Quark, but in InDesign that's cake. I should look into the functionality that Quark offers, though. The word "export" is perhaps a bit off the mark to describe the full scope of this project, as it seems to imply a one-time last-minute export - what you're talking about.

The main benefit of web-to-print is that you can use a free (yet advanced) content management system that is available from anywhere where there is internet access. In some cases where I've used web-to-print, we didn't even have a public website, and we only used Drupal as an easy-to-use central place where everybody could edit the content that would appear in print. It saves time, and if you do have a public-facing website it's easier because you don't need a second piece of software for print content management.

Did this project ever get off the ground? I am looking to put together something remotely similar, for a commercial printing operation.

I would like to have a PDF "template" with static text and images, and also fields that accept variable data. Then use CCK to create a form to have a user input the data for the variable fields, let the user view the results, and then create a hi-res PDF print ready file.

Any ideas??

so whats the state and are there any no-go's?

I want to get involved too!

has anyone developed some kind of module or workaround to pull articles from drupal (web) to inDesign (print)

kindly share, if there is something in place.