Question

This a useCase ..followed by a question. Please feel free to move the topic somewhere else if Support Web is not the right place..

• The teamA use a dedicated web "webA" to write a book made of Topics, and want to publish the book to the teamB, which have read access on web "webB" on the same or another Twiki installation, and no access to "webA".
• We want teamA to be able to work on new release of the book while teamB only sees current release .
• We want teamB to be allowed to produce some feedback
• We want each published release of the whole book to be saved to an archive.
• We'll assume that we use some kind of WorkflowPlugin to validate documents inside "webA" before publishing them to "webB".
• We'll assume that we use PublishContrib in order to publish from webA to webB.
• It seems to me that in order to avoid access issues, we should use a rule such as : in order to get published, webA should contain only includes or links referring to / from itself, or to/from a "everybody's read access" web

• The question is : is Twiki is the right tool to handle such a useCase..? do experimented users confirm ?

Thank you a lot. Twiki is great job.

Environment

-- OlivierThompson - 06 Aug 2008

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

To answer your question simply: yes, TWiki is a great tool for creating the kind of collaborative-editing-to-publishing workflow you describe. I'm creating a very similar application for a client currently. The links issue you mention should not be a problem as long as parallel topics exist in the published version.

-- LynnwoodBrown - 06 Aug 2008

Thank you for your answer. May I ask some more questions : most of the time, the legacy documentation ( was | is ) written with a word processor. Users will then have to (duplicate | create directly ) their documents in twki topics, so that search and all the dynamic stuffs works.

• Would Wysiwyg plugin feed the needs of users used to produce documentation with a word processor ?
• How would you print out enterprise logos and graphics ( assuming we don't embed html in topics ) ?

Thank you

-- OlivierThompson - 10 Aug 2008

"Would Wysiwyg plugin feed the needs of users used to produce documentation with a word processor" - it very much depends on the users. If users are used to power tools such as Microsoft Word or Open Office, then the answer is no. The Wysiwyg tools in browsers, even when combined with TWiki features, just don't offer that kind of power or integration. If, on the other hand, collaborative authoring is more important than simple publishing, then Wysiwyg can be used quite successfully.

-- CrawfordCurrie - 14 Aug 2008

Yes, "collaborative authoring is more important than simple publishing".

-- OlivierThompson - 20 Aug 2008

I'm not clear what your second question means (regarding logos and graphics). Could you elaborate? If you mean simply can you display enterprise logos and graphics within your TWiki skin, the answer is "most certainly."

-- LynnwoodBrown - 20 Aug 2008

The second question was about printing pdf files with TWiki + css ( http://twiki.org/cgi-bin/view/Plugins/MoveableTypeSkin?cover=print ) .. I don't know how to render css in the pdf files with TWiki ..I did try GenPdfAddOn but it doesn't support css.

-- OlivierThompson - 21 Aug 2008

have you tried ToPDFAddOn? It uses a much more intensive php based html2pdf conversion that does look at external css files (GenPDFAddOn does do some css rendering if it is inline in the html file - especially if you use the 'development' version of htmldoc - which I've found reasonably stable.

-- SvenDowideit - 21 Aug 2008

Why not creating webA and webB as a TWiki web with webA only accessable by the authors and webB being read-only. When publishing a new version, webA (or parts of it) could be copied to webB, next time to webC and so on. Old versions, e.g. webB could then be hidden. This way search in TWiki still works.

Maybe the feedback could also be in a TWiki web linked to and from the webX topics (similar to the discussion pages in Wikipedia).

-- MatthiasThullner - 21 Aug 2008

Although I have never used the pdf-generating feature in PublishContrib, I assume it applies whatever skin is specified (including associated css) when generating the pdf document.

-- LynnwoodBrown - 21 Aug 2008

PublishContrib uses skins (e.g., "print" so that the left bar and top bar do not appear), but it won't use CSS unless you use the development version (1.9) of HTMLDOC. As Sven indicated, the stable relase (1.8) "supports most HTML 3.2 elements, some HTML 4.0 elements, and can generate title and table of contents pages. The 1.8.x releases do not support stylesheets"

I haven't tried ToPDFAddOn but, from the dev discussion, I gather that "much more intensive" also means "slow".

-- SeanCMorgan - 21 Aug 2008

Time for some PublishToPDFConsolidation talk, isn't it?

-- FranzJosefGigler - 21 Aug 2008

> the legacy documentation ( was | is ) written with a word processor. Users will then have to (duplicate | create directly ) their documents in twki

BTW, there are tools to convert MS Word formatted files (the de facto standard) into TWiki markup.

-- SeanCMorgan - 22 Aug 2008

To produce a PDF, I would suggest taking a look at the Latex-based solutions in TWiki. It will give you more flexibility and control over the produced PDF. Personally I use GenPDFLatexAddOn and its requisite LatexModePlugin.

-- RafaelAlvarez - 22 Aug 2008

Thank you. I really appreciate your help.

-- OlivierThompson - 26 Aug 2008