OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: DOCBOOK-APPS: Re: Help project structure

A chunking PI sounds like a great idea.

Love the idea for the linebreak too.

#4 and #5 - I didn't explain very well.  I don't want to merge an existing
TOC with a manual one.  When the TOC is generated, it would be nice to
specify ahead of time that a topic not be included in the TOC. What I am
referring to in #4 is that there is no way to add a topic without it being a
topic inside a book/folder (in the .chm).  Typically you will see a topic in
a table of contents with the article icon next to it without it having to be
inside of a book icon.

I want to do both of these things and I almost have this finished using a
customization.  I only need one topic (not in a book or folder in compiled
help file), my default and first topic, to be an article (not in a book or
folder icon).  I basically am checking to see if it is the first topic and
if so, make it appear as an article in the TOC (no book|folder).  If I
specify all my extra help topics as a section of level 2, then I will
exclude them from having an entry into the table of contents.  Not very
elegant, I know, but it is giving me some beginner XSL experience.

Yes, I've been thinking about making our development environment save the
topic ID's and names as XML (in addition to the regular .h file).  That
would be simple enough.  What's the best way to marry the alias.h and
context.h (also save as context.xml) together?  A PI or a stylesheet


-----Original Message-----
From: Jirka Kosek [mailto:jirka@kosek.cz]
Sent: Friday, February 01, 2002 11:32 AM
To: Maggie Strevell
Cc: Norman Walsh; David Cramer; denisb@rational.com;
Subject: Re: DOCBOOK-APPS: Re: Help project structure

Maggie Strevell wrote:

> For a help project, I'd like to be able to:
> 1) Specify whether or not an element should be chunked (chunk="yes" |
> Applies especially to Set,Book,Chapter,Title.

This can be implemented by processing instruction. E.g:

<?dbhtml chunk="yes"?>

But implementing this will require big changes in current chunking code.

> 2) Be allowed to specify which file is the default in the .hhp file

I will add parameter for this.

> 3) Add a template to add a linebreak, for those who like to customize
>    (If all <p>'s were changed to <br><br>, then you'd never need <p>)

This issue was discussed several times ago.
Norm, what about adding support for sth. like <?db line-break?> ?

> 4) Be allowed to add a topic in the TOC without having it be in a TOC
> book/folder.  Should be able to be first in the TOC, in the middle of the
> TOC, or at the end.
> 5) Be allowed to exlude a topic in the TOC.  All other functions still
> like chunking the topic, add it to the index.  This is required for
> context-sensitive help for topics that might relate to a windows control
> which really don't need a help section in your TOC and possibly the
> manual too.

I can't imagine how to merge automatically generated ToC with manual.
Solution might be to generate ToC based on some external ToC file --
user should have possibility to create its own ToC or use current
automatic generation.

> 6) Ability to specify the title of the help project.  Currently, for me,
> defaults the title of my first <chapter>.

You probably have all chapters in book. You can set title for this book
and it will be used. Stylesheets use first title in document to get
title text. But if there is a demand, I can add parameter for this also.

> 7) Ability to remove the appending of a chapter title to a section.
> 8) Ability to specify a name for a manually constructed context.h (maybe
> alias.h for someone else?).

This is possible by parameters:

and if you create them manually, you must also set

> 9) A way to manage Help ID's specified in the dbhh PI.  We base our help
> ID's off the same number as the resource ID for each window control.  As
> C++ GUI application is shared among many developers, resource ID's for
> window control/button/dialogbox can get renumbered each time the app is
> built.  Therefore, our help ID's can change.  IDC_MY_BUTTON becomes a help
> ID of IDH_MY_BUTTON, both defined as "765".  Since my help ID defines are
> moving target, I can do one of two things, manually maintain the alias.h
> file or find a way to automate it.  I'm big on automation, so possibly we
> could have the PI dbhh take a help ID name and then look up the number
> is defined for it in the context.h file?  Otherwise, I could write a
> post-operation script to replace the context.h with my own, then
> the numbering scheme between the auto-generated alias.h file with the
> context.h that was created by my GUI application.

This is probably impossible to implement directly in XSLT (it will be
possible if your development environment can save topic ids and names as
XML file in some common format).

> I'd like to be able to understand chunking for some things I'd like
> customize.

Me to. ;-)


  Jirka Kosek
  e-mail: jirka@kosek.cz

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC