MadCap Blaze

[quills at airmail.net]

The problem is that XML and by extention XHTML describe content, not 
presentation or formatting. HTML is designed to present data in a 
formatted state (XHTML is designed to allow the content author to 
define the structure and presentation). But HTML does not have the 
control built into it for printed media. It can be used, but is a 
pale shadow of what can be done with a word processor, much less 
dedicate apps like FrameMaker or InDesign.

The data format is text for Gods sake. And  Blaze's output to print 
is through PDF or XPS. Fine, but it means you have to define your 
output. A second step of design that you don't do with FrameMaker or 
InDesign, or even Word.

Scott

At 3:39 PM -0800 3/20/08, Sharon Burton wrote:
>****Vendor post****
>
>Forgive me - these are straight questions. I really don't quite understand.
>
>What's convoluted about getting printed output out of XML, HTML, or 
>XHTML topics
>in Blaze?
>
>You create topics, you define and assign style sheets to topics (you can also
>have multiple style sheets in one project and assign them at build time when
>you create the output), you create outlines that define the content for the
>output, you specify PDF, XPS, or HTML as the output, you output, and you're
>done.
>
>What other printed outputs would you want? PDF and XPS seem to be 
>the only ones
>you can send to a printer for printed books... If your workflow needs you to
>also output to Word or Frame, we have that too, but it's not really a print
>output, per se.
>
>As to XML, HTML, or XHTML not being the right data format for 
>content, it's the
>direction the industry is moving. Data in these formats are more 
>extendable and
>reusable than in a Word format, for example... Pretty much all CMSs, for
>example, store data as one of these formats.
>
>We've not found much that you can do in unstructured Frame that you 
>can't do in
>Blaze. But Blaze does things that Frame can't do, like Smart Cross-references.
>[see the docs or our website for what those are but they are very powerful]
>
>As to the docs, we have a 36 page Quick Start Guide and very extensive help
>system in the first beta build. This *is* a beta, so we're finishing the docs
>during the beta, hopefully using info you guys give us about what else needs
>tight docs. We would need to know what are you struggling with that needs more
>docs?
>
>Can you help me understand?
>
>Quoting quills at airmail.net:
>
>>
>>For a product that is supposedly Print oriented, HTML is a lousy
>>media to produce it in. There is no reason to use HTML. Even XHTML is
>>not the best route, nor is XML. While HTML and XHTML are presentation
>>based, they don't allow the same type of easy manipulation that
>>FrameMaker or even Word allows.
>>
>>This just isn't a paradigm that makes sense to me. There isn't an
>>output other than html or PDF or XPS. The means to get to your output
>>result is laborious and convoluted. This just doesn't seem to be a
>>well thought out print solution.
>>
>>And the beta did not provide me with any real documentation that I
>>could view with confidence. Was that a problem with the build?
>>
>>Scott