On 06/13/2011 03:11 AM, Gary Schnabl wrote:
On 6/13/2011 2:18 AM, Andrew Douglas Pitonyak wrote:
On 06/10/2011 06:58 AM, Nino Novak wrote:
Hi all,
just a comment from a (very occasional) lurker...
I happen to like lurkers :-)
My own (theoretical) thought is: In an ideal world, there should
exist a
hierachical framework with a "content master" from which any of the
derivates (brands, flavours, translations etc.) can be produced by a
given set of rules.
Although I agree with you, my primary concern is now (and always has
been) divergent products. I was left with the impression (that may be
totally wrong) that LO split and intended to go their own way and the
two products would not share any new code.
This is made all the more difficult by UI changes so that "official"
type documentation cannot show menus, icons, or screen shots from the
other (because they are likely to differ greatly).
With strongly divergent products, it does not seem practical. With
weakly divergent products it may be possible to use links to images
and then simply swap out screen shots and then also have some
paragraphs that are hidden and some not.
But I'm not an expert on how to best implement such a solution (maybe
DocBook or even better DITA? What about Drupal? Wiki?).
I have not looked seriously at the GIMP documentation build scripts,
but I have produced GIMP documentation. You write in XML and then
that XML is manipulated into the final form. This means that graphics
are referenced, and not part of the text. Unfortunately, it would
likely take significant time to setup something similar, it is very
complicated and understood by few (meaning few can troubleshoot the
build system).
If the intent is to produce documentation for multiple products off a
single source, then we require:
Ability to associate sections of text to a particular product.
A method to reference the product in such a way that it can be
changed to reference the correct product (ie, OOo or LO).
A means to substitute figures.
Generation of the final document must be automated. I expect that
what ever form is used by this group will not be made available to
the general public. In the GIMP project, they may generate the docs
as PDF or HTML (as just two possibilities).
I am very interested in how things play out between Apache control
over OOo and LO (specifically, will the products be more likely to
track in the future). I expect that we need to understand that before
we can make a decision.
If one wants to author documentation going the XML route, one (older)
method, of course, is to employ DocBook, which was used to create
software documentation for quite some time already. For that, one
could use structured (XML) FrameMaker, based upon the DocBook DTD (or
other XML) file and create an EDD file to format the documents. I have
created a general-purpose DocBook 4.5 EDD for FrameMaker from the DTD
file produced by the DocBook people.
I do agree that if we went the XML route, that DocBook would be a good
choice. Sure would seem ironic to NOT use OOo or LO because it lacked
the required features :-)
Another tack would be to use another WYSIWYG application--<oXygen/>
XML Editor http://www.oxygenxml.com/xml_editor.html. There are others,
but this app is reasonably priced.
I expect that a "for pay" product would be a problem in general for the
group, as would a product that did not function on multiple operating
systems.
Gary
--
Gary Schnabl
Southwest Detroit, two miles NORTH! of Canada--Windsor, that is...
Technical Editor forum <http://TechnicalEditor.LivernoisYard.com/phpBB3/>
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
--
-----------------------------------------------------------------
To unsubscribe send email to authors-unsubscr...@documentation.openoffice.org
For additional commands send email to sy...@documentation.openoffice.org
with Subject: help
