Third-party or "out of the box" plugins [was "re:

[Peter Ring]

With a bit of duct-tape, Excel worksheets, and Python scripts, the 
future is now. We use 'out-of-band' index entries to produce 
back-of-the-book indexes.

The index is authored separately from the body text, using simple Excel 
worksheets as the exchange format, and associated to the body text 
through section numbers or similar identifiers. A script translates the 
index terms and a list of section numbers vs. page numbers into MIF, 
from which FrameMaker generates a beautiful index.

The index terms in the Excel worksheet actually correspond to DocBook 
indexterms (i.e., easy to repurpose). We tried using FrameMaker's 
DocBook application, but the translation to index markers is quite 
buggy, so MIF was the easiest way forward.

Well, the point of this is that wrt. the semantic part of it, we rely on 
completely general tools and formats, and wrt. integration with 
FrameMaker, we rely on MIF and generated lists (to extract section 
numbers vs. page numbers). The process is driven by a Makefile. Better 
FrameMaker scripting would be welcome, but DZbatcher [1] goes a long way
when you want to drive the process no-hands.

Kind regards
Peter Ring

[1] http://www.datazone.com/dzbatcher2.html


mcarr at allette.com.au wrote:
> Eric Dunn wrote:
> 
>> Now what exactly is the difference between "hunt and peck" and "drill".
> 
> Drilling through a graphical user interface would involve pointing at hot
> spots to get to the subsystem of interest, then working from a list of
> commonly required process - Servicing, Repair Procedures, etc. Hunt and
> peck would involve someone typing into a search form on a keyboard. Is
> that really your question, or are you asking what the advantages are of
> each?
> 
>> And how is a toughened and oil covered touch-screen and more elegant than
>> a toughened keyboard? It's poor form to use derogatory terminology for one
>> option we don't support and positive terminology for the one we do. The
>> statements also unveil a certain snobbery of IT superiority by denigrating
>> those that work in other fields. Denigrate anything linked to the awful
>> old hands-on industry and try to enlighten it with beautiful IT derived
>> terms and symbology.
> 
> My apologies if it sounds like snobbery - it was not intended to. When I
> was young I spent 7 years on an assembly line (http://www.travelaire.com/)
> and a year digging ditches (sorry, no URL). When I leave IT, my next
> career will be much more hands-on - I like factories and equipment. I
> accept that it may have sounded like snobbery, but I don't think it was,
> really.
> 
> As for whether a touch-screen is more elegant than a toughened keyboard,
> frankly, you're missing the point. I don't know or care what the devices
> will look like in ten years, but the discussion isn't predicated on that.
> It's the data and the ways of accessing it efficiently that we're talking
> about.
> 
>> Drop the prejudice against indices as a hardcopy only issue and recognise
>> that index information is useful metadata, regardless of how it is
>> ultimately searched and presented.
> 
> I don't think you've been reading this discussion properly and given your
> tone, I'm not inclined to explain it again. I haven't been advocating the
> abolition of indexes, I have been noting that an index is most useful when
> it has been created based on the view of the data that the user will see.
> As the trends toward syndication and purpose-driven republishing of
> components increases, conventional indexing tools begin to show a
> weakness, as there is no "final" view of a document. How do you decide
> whether to direct a user to an occurrence of a term in one fragment or
> another when you don't know which fragments may ultimately be combined, or
> whether this fragment will be combined with an as yet unknown and
> altogether different publication? Obviously, you cannot know how best to
> index a publication that does not yet exist.
> 
> Alternate ways of collecting and presenting metadata are precisely what I
> was arguing is necessary. My point was that metadata organisation and
> presentation has to be carried out *after* the publication has been
> assembled. If you want to pull those derived publications into FrameMaker
> and index them with an improved version of what FrameMaker already offers,
> well, knock yourself out. Most organisations will be looking to replace
> you with software though, and Adobe will presumably be only too keen to
> facilitate them.
> 
> 
> Marcus Carr
> _______________________________________________
> 
> 
> You are currently subscribed to Framers as pri at ddf.dk.
> 
> Send list messages to framers at lists.frameusers.com.
> 
> To unsubscribe send a blank email to 
> framers-unsubscribe at lists.frameusers.com
> or visit http://lists.frameusers.com/mailman/options/framers/pri%40ddf.dk
> 
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.
>