🚀 go-pugleaf

In article <z21mc6m.ergo@netcom.com> ergo@netcom.com (Isaac Rabinovitch) writes:
>In <w1ym8xa.garyd@netcom.com> garyd@netcom.com (Gary Dietz) writes:
>>> Why not just use WINHELP?
>>Well, quite frankly, the windows help viewer sucks.
>I more or less agree, but I disagree with some of your specifics.
>>Some simple examples:
>>- You can't do a full-text search
>HLP files are compressed, so a full-text search would be *very* slow.
>And fancy searching tools (which, come to think of it, are the main

I don't want to search *existing* help files.  In fact, I could care less
about exsiting help files.  I want to create a help file for OUR product
and distribute a viewer for it WITH our product.

True, not standard.  But we are very concerned about providing a very 
functional and intergrated help system with our product.

3rd party stuff like IBM's BookManager or Frame's hypretext viewer are
too expensive.  And besides, the are really "book" viewers, not help systems.

>>- The placement of bitmaps is very rudimentary
>I'm no sure what you mean.  In any case, you might want to check out
>the new bitmap tools for the 3.1 help compiler.

I can place a bitmap on the left, on the right, or in the center.  I think
that there is a sort of way to get text to flow around a bitmap, but I can't
get it to work.

The segmented hypergraphic tools you refer to in 3.1 are kind of spiffy, but
very hard to maintain if your source bitmap changes. 

>>- There is really no way to 'index' things -- it is really just a 
>>  keyword search (you can't do a two level index)
>I don't understand this point at all.  I certainly agree that the

See the :i1. and :i2. tags available in IPF (the OS/2 help compiler).

>
>>- I can't dictate what fonts the viewer will use unless I assume the
>>  default fonts that ship with windows
>This is a problem with *all* Windows apps.  If you know how force a
>program to use a font that isn't actually installed on the user's
>system, I wish you'd share it with us!

I am not a windows programmer (I don't even play one on TV).  I am just 
a technical writer with an attitude problem.

So, basically, I understand that you CAN'T do this.  DOesn't stop me from
wanting to do it though.   :-)

>>Also, the help file format is COMPLETEY undocumented by Microsoft.
>So any alternative help engines would not be backward compatible.
>Windows is a kludgy enough environment already, thank you very much!

Again, I don't care about backward compat.  I don't want to view 
*existing* HLP files.  I want to compile my own and suppy them to our
customers with a viewer.

>
>Still you've touched on one of my pet peeves with MS.  They guard file
>formats like the Ark of the Covenent, supposedly because third-party
>other silly variations!  

Yeah, like we might actually introduce an INCONSISTENCY in a windows-related
product :-)

>
>>So, I'd like a 3rd party help compiler and viewer that will respond to
>>the standard WINHELP calls in the windows apps we have in development.
>
>If you *must* have your own help engine, then you should design your
>own set of calls. 

I ain't got the time or the knowledge to do this.  That's why I want to pay
someone $500 to $1500 to sell it to me (and others).  Shit, we paid $500 for
RoboHelp, and all that is is a few WinWord macros!  (But very useful ones)

>Otherwise you're likely to break all the programs
>that rely on the MS engine!
>
Other programs can still use WINHELP.EXE if they want to.  I just don't want
our program to use it.

>		


-- 
I'm garyd@netcom.com

     "If I hugged you any closer, I'd be behind you."  -G. Marx
     "Whatsa matta you?"                               -C. Marx