Flare to "ordinary" Web pages — XHTML, or…?

This forum is for Single-Sourcing your Flare content to multiple outputs.
Post Reply
Phlawm53
Sr. Propeller Head
Posts: 442
Joined: Tue Mar 16, 2010 10:58 am
Location: San Francisco, CA
Contact:
Contact Phlawm53

Flare to "ordinary" Web pages — XHTML, or…?

Post by Phlawm53 »

I have a customer who wants three types of single-sourced outputs:
  • PDF and HTML-based online help
  • Web pages that are part of a larger corporate Web site
I have experience using Flare to produce the first two targets. I have no experience using Flare to produce the third.

My first thought is that Flare's XHTML target might work.

Has anyone done any "Flare-to-Website" single-sourcing? If so, any guidance on the workflow, et cetera?

Cheers & thanks for your help,
Riley
Top
LTinker68
Master Propellus Maximus
Posts: 7247
Joined: Thu Feb 16, 2006 9:38 pm

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by LTinker68 »

It depends on what you mean by part of the corporate website and if the HTML-based online help you mentioned you've done is the HTML Help (.chm) or the WebHelp output. You can certain stylize the WebHelp output to have your company's branding and look-and-feel, if not the actual layout structure. And even then, you might be able to simulate the layout structure to a certain extent.

So please provide some more details about what you want to do and how it's to be part of the corporate website.
Image

Lisa
Eagles may soar, but weasels aren't sucked into jet engines.
Warning! Loose nut behind the keyboard.
Top
Phlawm53
Sr. Propeller Head
Posts: 442
Joined: Tue Mar 16, 2010 10:58 am
Location: San Francisco, CA
Contact:
Contact Phlawm53

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by Phlawm53 »

Lisa:

What I'm thinking of is NOT an online help system of any sort.

Instead, it's "plain vanilla" HTML or XHTML content of the sort displayed as part of an ordinary Web page. For example, the prose on this page, but NOT the stuff necessary to create the entire page layout:

http://www.pwc.com/us/en/audit-assuranc ... ices.jhtml

That is to say that the content created in Flare may be part of a PDF or help system "document", but it may also be incorporated into one or more "non-document" Web pages. That in turn means that I need to deliver the content from Flare in a format that can be more or less readily processed into standards-based XHTML.

As I said, I know how to use Flare to produce PDFs and WebHelp outputs. That part's easy.

But Flare's XHTML appears to have *LOTS* of non-standard, Flare-proprietary detritus in it. So my question is essentially, what if any Flare output and workflow would enable content to be contributed to non-document Web pages?

Does that clarify what I'm trying to do?

Cheers, thanks, & have a GREAT weekend,
Riley
Top
RamonS
Senior Propellus Maximus
Posts: 4293
Joined: Thu Feb 02, 2006 9:29 am
Location: The Electric City

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by RamonS »

Phlawm53 wrote:But Flare's XHTML appears to have *LOTS* of non-standard, Flare-proprietary detritus in it. So my question is essentially, what if any Flare output and workflow would enable content to be contributed to non-document Web pages?
What would be non-standard XHTML in Flare output? I cannot see anything non-standard. Do you have an example?

As for a more bare bones HTML based output, take a look if mobile output works for you.
Top
Phlawm53
Sr. Propeller Head
Posts: 442
Joined: Tue Mar 16, 2010 10:58 am
Location: San Francisco, CA
Contact:
Contact Phlawm53

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by Phlawm53 »

Ramon:
What would be non-standard XHTML in Flare output? I cannot see anything non-standard. Do you have an example?
Flare's XHTML target isn't exactly XHTML. Instead, it's meant to be read by the Madcap-provided reader as an XHTML book.

As such, the .htm files output as part of a Flare XHTML target seem to contain a lot of stuff that while not exactly a violation of XHTML syntax, does include a lot of instructions to the book reader.

For example:

Code: Select all

<html xmlns:MadCap="http://www.madcapsoftware.com/Schemas/MadCap.xsd" MadCap:lastBlockDepth="6" MadCap:lastHeight="843" MadCap:lastWidth="628" MadCap:disableMasterStylesheet="true" MadCap:tocPath="Processing Phone Interactions" MadCap:medium="print" MadCap:InPreviewMode="false" MadCap:RuntimeFileType="Topic" MadCap:TargetType="HTML" style="mc-auto-end-on-left-page: disabled; mc-page-layout: url('Resources/PageLayouts/ContactualChaptersSS.flpgl'); mc-page-layout-override: url('Resources/PageLayouts/ContactualChaptersSS.flpgl'); mc-page-number: '1'; mc-page-number-format: decimal; mc-page-number-reset: continue; mc-chapter-number: 4; mc-chapter-number-text: 4; mc-chapter-number-format: n; mc-volume-number: 1; mc-volume-number-text: 1; mc-volume-number-format: n;" MadCap:endnoteStartIndex="0" MadCap:autonumPosition="none" MadCap:pageCount="146" MadCap:bookPageCount="149" MadCap:pageContinueIndex="38">
    <head MadCap:autonumPosition="none"><title MadCap:autonumPosition="none">Transferring a Phone Interaction to a Different Agent</title>
        <link href="Resources/Stylesheets/ContactualManuals.css" rel="stylesheet" type="text/css" MadCap:autonumPosition="none" />
        <link href="Resources/Stylesheets/MadCapBlaze.css" rel="stylesheet" type="text/css" MadCap:autonumPosition="none" />
    </head>
    <body MadCap:autonumPosition="none">
There are other autonumber and similar sorts of things throughout the file, as well.

An automated process (albeit not one readily available for Windows) could presumably go through the files doing lots of GREP and SED type operations to clean up the file. But that's an additional production step that not only needs to be created, it needs to be maintained.

Also, if the objective is to generate content BOTH as "document" type outputs (PDF, online help) and "non-document" XHTML, it appears to me at this point that I may have an irreconcilable conflict in how the content must be authored. That is:
  • I need to include / use Flare's list, x-ref, and similar features to generate the document outputs
  • I need to exclude / not use Flare's list, x-ref and similar features to generate the non-document output
In the meantime, I'll check into the mobile output target per your suggestion.

I also wonder if a DITA target might be one way to go…(?)

Cheers & thanks for your help,
Riley
Top
RamonS
Senior Propellus Maximus
Posts: 4293
Joined: Thu Feb 02, 2006 9:29 am
Location: The Electric City

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by RamonS »

Oh, OK, I was thinking of WebHelp. As you mentioned, the "XHTML target" was always meant as a construct for further processing. Then again, Flare is a help authoring tool. I think it is understandable when Flare does not excel at things other than help output.
Depending on how much offensive stuff is in the files it ought to be fairly easy to build a processor in PHP that reads in the files and removes the stuff you do not want assuming it is enclosed in specific tags or specific parameters.
Top
Andrew
Propellus Maximus
Posts: 1237
Joined: Fri Feb 10, 2006 5:37 am

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by Andrew »

A DITA export and then import into some tool that can generate "normal" xhtml / html from DITA might work. I don't really see any other way, unless you write an XSLT to translate the MadCap namespace stuff into "bog standard" xhtml.
Flare v6.1 | Capture 4.0.0
Top
crdmerge
Sr. Propeller Head
Posts: 248
Joined: Tue Dec 16, 2008 5:37 am

Re: Flare to "ordinary" Web pages — XHTML, or…?

Post by crdmerge »

Every help authoring tool will have "non-standard, [xxxx]-proprietary detritus in it," none of which should be seen by anyone viewing the web pages in a browser.

As to the help vs. web page issue, have you investigated creating a third target for WebHelp or HTML Help that would have no left navigation pane and possibly even no toolbar (I just tested, and it's possible)? You might want to go the HTML Help route, since you could control the size and location of the window, whereas in WebHelp those are controlled by the user's browser settings. A full-screen WebHelp output with no navigation pane on a 19-inch monitor is really, really w-i-i-i-i-i-d-e!

Also, consider this: producing "web"-y pages, that is, pages linking only to each other rather than through the TOC/Index/Search/Glossary navigation links, will require a structural redesign on your part for this new target. That is, the "Home" page will now need a comprehensive "site map," all TOC "book" topics will also need a "site map" that will allow the user to either drill down to the "pages" within it, or up to pages above it. Above all, it is your responsibility to guide the user around your "site," since the page your users are viewing is their only connection to the totality (since the left navigation pane "lifeline" is nowhere to be found). You should be able to use condition tags to include/exclude related content for each of your targets, although you might even consider entirely separate conditionalized pages.

Sorry, but I can't see any other way but to roll up your sleeves, and get to work designing your new "plain vanilla" web pages! :(


Good luck,
Leon
Top
Post Reply

Return to “Single-Sourcing”