Unlike word or FrameMaker, there is no page information in XML data.
When asking for LEP, it really means asking for a page-based solution.
To support this, one idea is to have page information, use PI or element
in a different namespace, inside the XML data. Your stylesheet do page
break according to this page PIs or elements when composing. So that you
can maintene individual revision number, revision date, change
description, change status, page number and so on for each page. This
will be able to support alpha page, page 138A/B, since you can save page
number on each page in the xml data. Via this way, generate LEP is not
difficult: go through the whole manual and find out all pages in the XML
data and list each page's status in a table. You can also maintain
change description for each page and can generate revision highlights.
There are still problems to solve: if the user add content or remove
content and the page break in original place will be incorrect. They
should be adjusted manually or automatically.
I implement this using XSL-FO on top of RenderX and Arbortext PE. When
implementing, the key problem to solve is to know which content/elements
in which page. In RenderX, the approache is to look into and process the
intermedia file, XEP. In arbortext, the approach is to generate a
intermedia file which page information and elements information in it by
doing a compose. Please have a look at linenum function and
formatcompletehook/formatcontinuehook.
According to my experience, It is a challenge task to implement a
page-based solution when the customer decided to go XML-based publishing.
Hope this helps,
Jingjun Long
于 1/16/2011 9:08 AM, Dan Vint 写道:
At 03:56 PM 1/15/2011, G. Ken Holman wrote:
At 2011-01-15 14:43 -0800, Dan Vint wrote:
Not looking for the code or anything right now, but I need to put
together a plan for a new project. I'm working in a milspec
environment and they require that changes be tracked by release for
when/what changed that page.
So first release everything is baseline and no problem. With
subsequent minor revisions, paragraphs and such will be modified. We
will track those changes with markup and a revision level. I need to
maintain the original page breaks as well so that I don't get
information reflowing between releases. Major additions would create
a new point page as well.
The footer for these changed pages will reflect the latest change
that was made and I need to produce a list of pages (a table up
front) that lists every page and its current revision.
Typically this would then be produced as a change package (just the
updated pages) for loose leaf publishing but they haven't required
that yet.
Typically this has been done with FOSIs and either Arbortext
publishing or Datalogics composer, I would like to do this with FO
if possible.
XSL-FO doesn't support loose leaf publishing because there is no
knowledge of page breaks from one publishing run to the next. No
database of page images either.
You might make some progress with an intermediate form like XEP's,
and comparing one to the next, but then I'm unclear how you would
create change pages, say page 138A/B between pages 137/138 and
139/140. How would you "restart" page 139 in the following run at the
exact same point where page 139 started on the previous run?
What I have seen with FOSI implementations is they put a PI at the
page break from the first run.. When I first started this email I was
only thinking about the LEP itself and capturing the information about
what changed. I had forgotten about the point pages until I was writing.
I figure this was going to be difficult.
Thankfully when my customers with LEP requirements have come to me
for XSL-FO they've been willing to abandon the LEP in favour of
getting to use XSL-FO. In each case they were abandoning loose-leaf
for complete electronic products. If you have change markup on the
way in then using markers one can tell that on a given page there is
changed content by adding something in the header/footer that the
page has changed, but you can't preserve the page breaks that follow
changed content.
If you can't convince your client to abandon loose-leaf, I think
you'll have to use something other than XSL-FO.
I have a hybrid product as it is and I'm making recommendations to
drop some features. I wasn't sure if this was one I wanted to (or
could) tackle with FO. I'll have to check with Arbortext, they may
have some extensions to help with this.
Thanks for the help.
...dan
. . . . . . . . . . . Ken
--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
---------------------------------------------------------------------------
Danny Vint
Panoramic Photography
http://www.dvint.com
voice: 619-938-3610
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--