RE: RE: Interviewing "under the hood"? (long)

["Mark Baker" <mbaker -at- ca -dot- stilo -dot- com>]

Dick Margulis wrote:

> Thinking in XML for the moment, I might have something called
> <featurelist>, say, that defines a block containing some
> arbitrary number of <featurename>-<featuredescription> pairs.
>
> Okay, now I want to render that list of features in different
> output formats--PDF, HTML, whatever. So I have some sort of
> engine (I'm vague on all this stuff because I haven't actually
> used XML for anything yet) that applies a transformation to my
> document (is that what XSLT means???) and outputs it in one
> format or another.

There are generally a few more step involved than that. There are a number
of rendering engines available. The job of a rendering engine is to paginate
text, kern fonts, apply appropriate leading, and generally do all of the
page-fitting tasks for which people have been discussing these ugly
style-based tricks.

Word and Frame can be usefully thought of as rendering engines with WYSIWYG
editors stuck on the front. (That the editor is a front end for a rendering
engine is the clear implication of "What you see is what you get")

There are several other rendering engines available, a couple of which are
TeX and XSL-FO.

Each of these rendering engines has its strengths and its weaknesses (some
more of the former, some more of the latter). The point is, with your
document and its XML markup, you are completely independent of all of these
rendering engines and free to choose whichever one you want.

So, you choose the rendering engine that has the strengths you are looking
for. Now the question is how to get there. Each rendering engine has its own
language that is used to drive it. (In fact, TeX and XSL-FO are both
rendering engine languages rather than rendering engines themselves. For
XSL-FO there are several rendering engines available, including FOP from
Apache and Render-X, which is commercial.)

So what you need to do is to convert you document into a set of instruction
written in a rendering engine language. Basically this consists of replacing
the element markup in your document with formatting instructions, though it
may get more complicated than that.

To perform this transformation, you need to write a transformation script in
a transformation language such as XSLT or OmniMark. Which you choose depends
on a number of factors. For instance, XSL-FO is an XML based language and
TeX is not. If you want to use TeX, which is more sophisticated than XSL-FO,
XSLT won't work for you.

Since writing these formatting scripts can be difficult and time consuming,
if you want sophisticated layout effects, you should probably design an
intermediate presentation language in XML. Write your formatting routines
against that language, and transform all your XML documents into that
presentation language as a step on the road to formatting. That way, your
formatting routines are written once and you don't need to touch them again.

You can actually find some XML tagging languages for which extensive
formatting routines already exist. DOCBOOK is one of these. While I would
never recommend anybody actually write anything in DOCBOOK, using it as a
stepping stone to get formatting done may be a useful strategy.

Anyway, the point is, you write your content in an ad-hoc XML tagging
language that is designed to support the work you are doing. You then
transform it into a presentation language and then apply formatting routines
to the presentation language to drive the rendering engine of your choice
and get the output you want.

This way, your content exists completely independent of any concern about
formatting. Formatting is a job for machines, not human beings.

> But, from what I gather, this transformation is rather
> simplistic. It can figure out that an em dash is a glyph in PDF
> and an entity in HTML and space-hyphen-hyphen-space in ASCII,
> perhaps; but it can't figure out that the top-margin defined for
> the list should not be applied if the list follows a heading or a
> page break but it should be applied if the list follows a text
> paragraph. Or it cannot figure out that the figure should go
> after the third list item in order to fit it on a letter page but
> after the fifth bullet item to fit it on an A4 page. Nor can it
> figure out that the top-margin (or "space above" or whatever you
> call it) needs to be adjusted up a couple of points on page 6 and
> adjusted down a couple of points on page 7.

The appropriate rendering engine can figure out all these things, and if
they are not built into it, your formatting script may be able to implement
these rules by manipulating the instructions it gives to the rendering
engine. The key is to pick the correct rendering engine for the effects you
want. That decision should be in no way tied to your choice of authoring
environment. The problem with WYSIWYG is that it ties authoring and
rendering together.

> So what I am in general decrying here is that we've gained some
> power but traded away some subtleties to get it.

I don't see that WYSIWYG gained anybody any power. As far as I am concerned
it is chains and shackles, both for the writer and for the content. It has
its place, of course, for pamphlets and office documents, but for technical
communication applications of any sophistication, it does more harm than
good.

---
Mark Baker
Stilo Corporation
1900 City Park Drive, Suite 504 , Ottawa, Ontario, Canada, K1J 1A3
Phone: 613-745-4242, Fax: 613-745-5560
Email mbaker -at- ca -dot- stilo -dot- com
Web: http://www.stilo.com

This message, including any attachments, is for the sole use of the
intended recipient and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient please contact the sender by reply email and destroy
all copies of the original message and any attachments.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ANNOUNCING ROBOHELP STUDIO

RoboHelp Studio maximizes your Help authoring power by combining 
RoboHelp Office and RoboDemo, so you can easily create professional 
Help systems that feature interactive tutorials and demos.

Find out more about RoboHelp Studio at http://www.ehelp.com/techwr-l2

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.