So, basically, you had to go from an online-created and -stored html doc to an offline custom parser that fed its output to an online (I take it) TIDY prettyfier, then sent that to another offline html->[InDesign format] perl module, which finally delivered a workable text file? Way to go, guys, way to go. But wasn't there a way to do it all online with Yahoo Pipes?

Ianf: I doubt it. In my experience, Yahoo Pipes still mostly feels you have to continuously come up with ways to circumvent the limitations and missing features of Pipes.

And in any case, how are you going to pull Google Documents stuff into Yahoo Pipes?

Ianf: XSLT would seem like a more obvious route

Couldn't you just have exported it from Docs as a Word file with styles intact and then imported that into InDesign?

To second Ben's question/suggestion. My preferred route would be to export to a RTF file and place the file in InDesign. Generally real Word documents don't place quite as good as RTF. They have extra formatting that can confuse my older version of InDesign.

So is possible to have some follow-up as to why the Perl route was chosen over real placed text/RTF/Word files?

One nice thing about InDesign is that its paragraph and character style menus highlight imported styles, so you can tell them from styles created directly in InDesign. That makes it a simple matter to search for all paragraphs or characters with a imported stylesd and convert them to the target styles used in the final page layout.

It was certainly interesting knowing how it was done, but the method makes me question the very sanity of using Google Docs for something as --apparently so out-of-Googleworldly-- as input preprocessor for an SGML/XML offline page production tool. No, I don't have a better idea.

Iolaire,

That's a good question about the Perl route. One of the reasons I wanted to do my own translation was that we have a set of styles in our InDesign documents that differs greatly from the default styles in Google Docs. Also, once I grabbed the zip file and slurped the HTML into Perl, it was very easy for me to extract the figures and number them in sequence.

But the key reason is that by going directly into InDesign Tagged Text, the chapters and figures imported without any hassle or massaging. It went in very cleanly and didn't give us any surprises (with Word and RTF, there's also a little tweaking that I need to do after the import). Converting each finished chapter was really easy after I wrote the code.

Motti: XSLT would have been a better route, but I was leaning on my existing skill set, which is frozen in time from years ago when I programmed full time. So I went with an API that I was familiar with, but someone with very strong XSLT skills could have created a more extensible solution, I think.

- Brian

Thanks Brian

Brian made the GDoc.pm source code available on requested, I updated the article with a link to the zip:
http://www.jepstone.net/downloads/GDoc2Indd.tar.gz

Thanks for outlining some of this process. I've been trying to come up with a streamlined workflow (at work) that we can use to move our course guides through their revision cycles faster from instructors to designers to the printer. I hadn't thought of using gDocs for this, but it really addresses the need to have a single document available to multiple editors. Again, thanks for sharing!