Re: What layout/styling technologies have people used? [Was: Revise group description?]

From: Dave Pawson <dave.pawson@gmail.com<mailto:dave.pawson@gmail.com>>
Date: Wednesday, December 18, 2013 at 3:10 AM
To: "public-ppl@w3.org<mailto:public-ppl@w3.org>" <public-ppl@w3.org<mailto:public-ppl@w3.org>>
Subject: Re: What layout/styling technologies have people used? [Was: Revise group description?]
Resent-From: <public-ppl@w3.org<mailto:public-ppl@w3.org>>
Resent-Date: Wednesday, December 18, 2013 at 3:11 AM

Just picking up on two points.


I wrote some fairly complex FOSIs for Arbortext’s original TeX based
publishing engine from 1995 – 2000 and beyond.

I still remember this noisy guy (!!) on the DSSSL list shouting 'we don't need
no steenking FOSI's. Norm Walsh.

At the time they were deemed to be quite powerful.

LOL. Yeah. I know. And Norm still came to work at Arbortext. :)


with a FOSI if you were in the know, tenacious, and had access to the
engineers on the 4th floor… The APP engine is capable of far more
sophisticated layouts, though. Unfortunately, it has taken a long time to
put an interface on top of the engine to make it usable by mere mortals
(compared to programming gurus).

does that mean you have Jean?

A styler interface? Not me. The Styler interface hooked up to the APP engine is all Arbortext R&D. I actually left PTC just after they released Arbortext Editor with the APP engine as the default publishing engine, so I don’t know the current progress or usability of the Styler interface. I do know that it is a much more intuitive interface for mere non-code-writing mortals than was the original 3B2 macro language.

<gloryDays>

FOSIs were my bailiwick when I was at Arbortext. In addition to writing numerous Docbook FOSIs for internal use (Engineering, Services, Training, and Product Documentation), I also got to write the very first Epic Editor Docbook print FOSIs (everything after 1.0 was written by someone else, though). I also got to refactor and/or customize numerous Docbook FOSIs for customers.

The really challenging stuff was making FOSIs do scholarly journal publishing. Which we did. And yes, it is possible to get 17 different flavors of journal article out of one FOSI, but I don’t recommend it for code maintenance and sanity purposes. The 17 different flavors also included at least 23 styles of bibliographic reference, some of which were unique to each of the 17 different flavors. Tear your hair out stuff.

On occasion, I took some particular page-based thing I’d figured out to an engineer only to have them tell me that it wasn’t actually supposed to work like that. At which point I responded “please don’t fix it! I’ve got what I need right now!!!” On more occasions, though, Paul Klock (RIP), Gary Grosso, and Andrew Dobrowoloski saved my bacon. Especially when I was first learning how to do the “hey. No one ever thought about making a FOSI do that!” stuff.

</gloryDays>


The big two missing from your list are Quark and InDesign. Quark was the
next big thing just as I was leaving the comp house where I did page layout
with a pica stick and a calculator in 1995. InDesign seemingly took over the
professional/trade/educational publishing world around 2006-2007.

I've heard it said that inDesign is now often taken as the master, from which
print houses then wish to take epub, html etc.

Absolutely. This is the case in trade, scholarly, STM, and educational publishing almost across the board for print. There are a few who choose a different path, but most take the path of least resistance, and most adoption which is currently Indesign. Trade publishers are particularly interested in taking something from Indesign all the way through to EPUB and KF8, though.

A friend of mine (who works for a trade/professional publisher) recently wrote a blog entry for digitalbookworld.com as a follow up to an ebook QA webinar she had presented the previous day. Here’s a question from the article:

“[Q]I’ve never created an ebook. If I export one from InDesign, will I end up with a file that still needs tons of tweaking?
“[A]The short answer: Yes.”

Here’s the link to the rest of the article: http://www.digitalbookworld.com/2013/on-ebook-quality-assurance-some-questions-answered/

The Indesign > EPUB approach does not go across the board, though. It really doesn’t scale very well due to the sheer amount of manual tweaking required. Most STM, scholarly, and educational publishers might use Indesign as a a way to get to something as a way to eventually get to EPUB, but not through the Indesign export to EPUB. Since many of these publishers are using publishing service providers, there’s sometimes little transparency into what’s in between Indesign and EPUB because everything is done with proprietary in-house built production tools, UI's, and automation scripts, which of course, vary from provier to provider. I saw a few different examples of the workflow and automation variations when I was at Cengage Learning and worked with some of the vendors.

It always struck me that Adobe were missing a trick not to provide a path
from XML to InDesign.  I guess they have commercial reasons for that.

There’s one big commercial reason for why Adobe decided not to pursue a more dedicated integration between XML for content-based publishing in Indesign: because they put it all into FrameMaker.

It’s my understanding that Adobe went down the “process XML as data to flow into Indesign objects” path because they figured that more people would be using XML specifically for things like catalogs and other things that you can easily flow XML into. This was the impression I got when I went to the big Adobe CS3 launch in NYC a bunch of years ago, anyway. If people wanted to do variable content in XML, they would use Framemaker. At this point, the Framemaker implementation has come so far (thanks to DITA), and is so different from what was done in Indesign that Adobe would have to rewrite a significant portion of Indesign in order to bring it to the same level of functionality, and they’re just not going to do that because they already did that in Framemaker. And yet there are people out there who are still trying stuff XML into Indesign in a way that Indesign is not capable of handling without some pretty heroic measures and plug ins and Javascript stuff and… the list goes on.