[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 customization? Maggie -----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; docbook-apps@lists.oasis-open.org 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" | "no"). > Applies especially to Set,Book,Chapter,Title. This can be implemented by processing instruction. E.g: <section> <title>xxx</title> <?dbhtml chunk="yes"?> ... </section> 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 apply > 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 printed > 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, it > 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: htmlhelp.alias.file htmlhelp.map.file and if you create them manually, you must also set htmlhelp.force.map.and.alias=1. > 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 my > C++ GUI application is shared among many developers, resource ID's for each > 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 a > 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 that > 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 coordinate > 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 -- ----------------------------------------------------------------- Jirka Kosek e-mail: jirka@kosek.cz http://www.kosek.cz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC