Since my last experiments with the Lazarus documentation I have a big wishlist.

1) Updates
I've applied many updates to the LCL documentation, mainly with regards to docking. It would be nice to have SVN write access to the docs folder, because I'm pretty sure that nobody can/will check documentation patches before checking them in.

2) Structure
IMO all documentation should reside in $Lazarus/docs/, regardless of packages. I.e. when I want to document the IDE and related packages, the files should go to an docs/xml/ide/ folder. Paul instead argues that the documentation should stay together with the (package) sources - but this might cause problems in finding documentation at all, fpdoc path maintenance etc.

Eventually all documentation (about packages, tools etc.) can be stored in independent SVN projects, which are added to /docs/xml/ as subprojects.

3) Packages
We should have at least documentation skeletons for all packages, so that everybody can see what's missing. I'm willing to create the skeletons, when their integration into LazDE is established (see below).

Can somebody try to create a documentation skeleton for any package, based on e.g. an .lpk file, that can be opened for further edits in LazDE? I found no way to do so yet :-(

4) LazDE
LazDE has a nice GUI for adding bulk documentation, or for filling the gaps left by the FPDoc editor. Unfortunately I achieved, somehow, that LazDE cannot open any package documentation any more, and also not the new documentation created with FPDoc Updater. At least should it be possible to add existing XML files to a package, as long as LazDE cannot create documentation for packages and all contained files itself.

5) FPDoc
The FPDoc editor is nice for adding help on the fly, but not easily usable for reviews. Switching amongst the tabs is nasty, I'd appreciate an option to expand the tabbed view into something like the LazDE GUI, where short and long descriptions can be seen at the same time.

It would be nice to have kind of an import feature in LazDE, so that

6) FPDoc Updater
I've added some remarks to the wiki. Main question: how to create a documentation package, compatible with LazDE?

7) 64 bit
Dunno remember where, but at least on documentation tool deserves fixes for 64 bit (cast between LongInt and TObject reference)

All in all I feel a need for better integration of the various documentation tools. Who ever will try to create documentation for a new package or project will see the many problems...

DoDi

You can send to me.

The opposite.
fpdoc paths are automatically maintained with the packages. If you put them somewhere else the maintenance will cost more. The search is done by the chmviewer or eventually directly in the xml files.

Eventually all documentation (about packages, tools etc.) can be stored in independent SVN projects, which are added to /docs/xml/ as subprojects.

?

What do you mean?

Please create a bug report.

I guess Michael welcomes patches for LazDE.

Mattias

Sure. Or at least detailed error reports so I can fix things.

Michael.

I have given Hans-Peter Diettrich write access on trunk/docs/xml after quickly reviewing r23306:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?limit_changes=0&view=rev&root=lazarus&revision=23306

Vincent

2009/12/28 Mattias Gaertner :

fpdoc paths are automatically maintained with the packages. If you put them somewhere else the maintenance will cost more.

This I understand.

The search is done by the chmviewer or eventually directly in the xml files.

What do you mean by search is done by chmviewer? What, chmviewer searches for .chm file in the various package and component directories?

I guess the first step would be to get the chmviewer actually working from inside the IDE. Last time Vincent and myself couldn't get this going. I triedd various settings and options and followed the wiki pages to the letter - no only thing I did manage, was to even break the HTML help after pressing F1.

Thanks :-)

As soon as I have a useful LazDE, I can start to review the documentation systematically.

I'm also willing to manage and check in documentation patches, so that I can e.g. distribute jobs and suggest documentation guidelines to the contributors.

DoDi

> Eventually all documentation (about packages, tools etc.) can be stored > in independent SVN projects, which are added to /docs/xml/ as subprojects. ?

This would allow to gather all available documentation (locally) in one directory tree. The formatted output will go into the same tree, when the user builds the final documentation. The build tool and help viewers will have to look only into one location, in order to find all documentation to create or show.

You didn't try to do what I suggested, didn't you?

Two bugs already have been fixed :-)

The remaining problem is that LazDE cannot open the docs for a package in an single tab. Every tab contains an degenerated tree, containing only three nodes: packages - <package> - <module>, and every module must be opened manually.

IMO an entry type "moduleref" is missing, which could be used in package doc files to refer to the contained modules. Alternatively a <module file="..."> entry, instead of <module name="...">. These entries then could be used to populate the package node in the treeview. IMO Makeskel doesn't save the used units in otherwise empty (package) unit files, so that opening e.g. lcl.xml will not result in a list of modules for the lcl package. Other xml files seem to contain references to the used units, with e.g. <element name="Classes">, which could be changed into <uses name="...">.

Alternatively LazDE could check the package name when loading an module file, and add the module to an already existing package node of this name. Or when loading an empty skeleton file, only containing an package name, it could search for all module files with this package name, and open them automatically. I've started to add according code, but I do not yet understand the object managment (doc file ownership) in LazDE, that would allow to handle multiple doc files in an single tree.

Finally I'm missing a feature to review documentation and source code in sync, as I implemented in PasDoc2 (branch of the SF pasdoc project). I understand that this is not easily feasable, since the FPDoc structure does not contain references to the declarations in the unit files. Such a feature may be better located in the FPDoc editor, which could be extended with navigation buttons to the preceding/next (undocumented) element in a module.

I guess Michael welcomes patches for LazDE.

I saw that he also read my suggestions :-)

DoDi

That would be feasable, since the IDE (package manager) maintains a list of all available packages.

Some time ago I implemented an CHM decompiler (D7), in order to get access to the Delphi help files. Parts of this code could be useful in the chmviewer integration, or in a replacement for the chmviewer itself.

I only couldn't manage the HTML browser navigation to an selected topic, and syncing the contents tree after an jump to an linked entry, using the MS browser interface. Firefox may expose a better usable interface?

DoDi

Hello Lazarus-List,

Monday, December 28, 2009, 8:25:17 PM, you wrote:

GG> I guess the first step would be to get the chmviewer actually working GG> from inside the IDE. Last time Vincent and myself couldn't get this GG> going. I triedd various settings and options and followed the wiki GG> pages to the letter - no only thing I did manage, GG> was to even break the HTML help after pressing F1.

I have a the "lhelp" chmviewer working fine, integrated in my Lazarus SVN (a few days ago). Running since around 2 months. Integration is quite good, topics appears as soon as pressing F1 (when no duplicate symbol across units).

I had follow the steps in the readme.txt file in lhelp. Windows XP environment.
CMH files taken from a post in this mailing list, but I can not remember the poster :-?, around 2 months ago.

Have you tried to read wiki:
http://wiki.lazarus.freepascal.org/IDE_Development#Builtin_CHM_help

Best regards,
Paul Ishenin.

2009/12/28 Hans-Peter Diettrich :

But how does chmviewer know when to search directories and when not too? For example, if I open ref.chm (FPC language reference doc) I don't want the chmviewer to go searching in other directories - that will just low it down even more.

Unless chmviewer is explicitly meant (and tied too) the Lazarus project and is only meant to be used with Lazarus - which I think is a very bad idea by the way.

2009/12/29 JoshyFun :

I have the same CHM files and I tried integration about 1 and a bit months ago. No luck. I tried the readme file, the wiki (various locations) etc.. My environment is Linux. I even tried the integration via package install or via compiler define in the IDE itself. No luck.

2009/12/29 Paul Ishenin :

Have you tried to read wiki: http://wiki.lazarus.freepascal.org/IDE_Development#Builtin_CHM_help

Yes I have, and the installed package method. No luck. When I'm back at work, I'll run the IDE from the command line so I can see some debug output and report it in Mantis.

2009/12/29 Paul Ishenin :

Have you tried to read wiki: http://wiki.lazarus.freepascal.org/IDE_Development#Builtin_CHM_help

Just tried this again with my home PC, also (like my work PC) running Linux. Lazarus SVN from yesterday.

* I compiled the lhelp project
* I recompiled the iDE with the -dUseCHMHelp compiler define
* I specified the directory location for the cHM help files (Environment > Options > Help Options > CHM Help viewer > HelpFilesPath). HelpEXE was already pointing to the correct lhelp executable.

Placed the cursor over the 'Classes' unit in the uses clause and pressed F1. I get a error (though this one is different from what I remember on my work PC). See attached screenshot.

PS:
Lazarus did NOT try and build the lhelp.lpi project automatically like the wiki page says. I had to build that project manually myself.

29.12.2009 15:59, Graeme Geldenhuys ?????:

Just tried this again with my home PC, also (like my work PC) running Linux. Lazarus SVN from yesterday. * I compiled the lhelp project

Lazarus should do this itself.

* I recompiled the iDE with the -dUseCHMHelp compiler define

Open ide.inc and just uncomment it. This is only supposed to work for 0.9.29. Therefore don't try this is you have lower version.

* I specified the directory location for the cHM help files

Try with LCL units first.

Best regards,
Paul Ishenin.

2009/12/29 Paul Ishenin :

> > * I compiled the lhelp project Lazarus should do this itself.

It did not. It simply said (when I pressed F1) that it couldn't find the lhelp executable.

I am. I'm using v0.9.29 r23241 from 23 December at the moment. I added '-dUseCHMHelp' in the 'Tools > Configure build lazarus > Advanced > options) location. That should do the same thing - I always build the IDE from inside the IDE.

Try with LCL units first.

I just did and it gives the same error message. Pressed F1 will the cursor was over the Controls unit. Even worse, when the cursor is over the Menu unit and I press F1, the whole IDE crashes and closes without giving any error message. No idea why it's trying to open something in the /tmp directory in the first place. I have setup the CHM directory location to /opt/fpc_docs/chm/

Graeme Geldenhuys wrote

It did not. It simply said (when I pressed F1) that it couldn't find the lhelp executable.

Then it is something wrong with your settings/working copy/process of IDE building.

1. Open ide/ide.inc and change the {off $define UseCHMHelp} to {$define UseCHMHelp}.
2. Open terminal and type: "make bigideclean bigide"

Then try again.

It works here both for Classes and for Controls and for any other identifier.

Best regards,
Paul Ishenin.

2009/12/29 Paul Ishenin :

Then it is something wrong with your settings/working copy/process of IDE building.

To be honest, it is quite difficult to screw-up the "Configure Build Lazarus" dialog. So I can't image what I could have done wrong. Attached is a screenshot how my configure build dialog > advanced tab. I have used that dialog for the last 4-5 years, so I would have thought that I know how to click the "build" button by now. ;-)

1. Open ide/ide.inc and change the {off $define UseCHMHelp} to {$define UseCHMHelp}. 2. Open terminal and type: "make bigideclean bigide"

OK, having nothing to loose and all to gain, I tried your way. Unfortunately it yielded the exact same results. Show the error about not being able to open the /tmp directory. Why is it looking for something in the tmp directory in the first place??

Graeme Geldenhuys wrote

OK, having nothing to loose and all to gain, I tried your way. Unfortunately it yielded the exact same results. Show the error about not being able to open the /tmp directory. Why is it looking for something in the tmp directory in the first place??

No idea. It does not do this here. Please show the help options you have.

If nothing help be ready to give a remote access to be able to give us understanding of what happens :)

Best regards,
Paul Ishenin.

2009/12/29 Paul Ishenin :

No idea. It does not do this here. Please show the help options you have.

See attached image. Also attached is a text file showing the output Lazarus IDE generated when I started the IDE from the command line, placed the currsor on the Menu unit in the uses classed and pressed F1.

I think it is simply meant that the file is registered by the package somewhere in Lazarus.

How you then approach and search that registry is a matter of configuration.

Unless chmviewer is explicitly meant (and tied too) the Lazarus project and is only meant to be used with Lazarus - which I think is a very bad idea by the way.

Explain.

Hello Lazarus-List,

Tuesday, December 29, 2009, 9:59:25 AM, you wrote:

GG> * I compiled the lhelp project
GG> * I recompiled the iDE with the -dUseCHMHelp compiler define

I had not done this, so I think the only difference is that the IDE will not autorecompile the lhelp.exe ?

GG> * I specified the directory location for the cHM help files GG> (Environment > Options > Help Options > CHM Help viewer > GG> HelpFilesPath). HelpEXE was already pointing to the correct lhelp GG> executable.

Attached an image of my config in the help.

2009/12/29 Marco van de Voort :

Unlike Windows, there is no default CHM viewer for Linux. So if lhelp is a CHM viewer, why can't we use it for other CHM (non Lazarus related) files. Otherwise Linux users would have to install two CHM viewers - one for Lazarus CHM files and another for any other WINE projects that have CHM files. If that is the case, if lhelp doesn't support other CHM files, then I will simply use a CHM viewer like GnoCHM (or any of the others) than do support any CHM files and ignore lhelp. Why use two separate viewers to view the same CHM file format?

2009/12/29 JoshyFun :

Attached an image of my config in the help.

Ah, I thought maybe my BaseURL was wrong for RTL, FCL and LCL help, so I changed it like your screenshot showed. Unfortunately that didn't make any differences.

So for now, I will continue using DocView with the External Tools option and view context help via Ctrl+F1 instead.

True. The default depends on desktop suite (gnome ->gnorpm, KDE -> kchmviewer, rest mostly xchm or use a CHM plugin in mozilla)

So if lhelp is a CHM viewer, why can't we use it for other CHM (non Lazarus related) files.

What is the point? There are already at least 4. Admitted, none is default, but a 5th one won't suddenly become default either.

Otherwise Linux users would have to install two CHM viewers - one for Lazarus CHM files and another for any other WINE projects that have CHM files.

So what? Then at least we can focus lhelp sharply on Lazarus' needs, and not get bogged down in Wine users complaints and feature wishes, just to save on average 1.5 MB of kchmviewer on a minimalists HDD. Lhelp is about FPC/Lazarus' needs, not about Wine's.

If that is the case, if lhelp doesn't support other CHM files, then I will simply use a CHM viewer like GnoCHM (or any of the others) than do support any CHM files and ignore lhelp.

The other viewers are just that, viewers/ebook readers.

lhelp is meant as the backend of an integrated helpsystem. For an IDE.

Lhelp should be
- be instrumentable to be able to forfill all roles for the IDE (all forms of search, including fulltext)
- be relatively lightweight (no additional packages as dependancies)

This is easiest achieved when lhelp is a part of lazarus more or less, and the way to instrument is undocumented (so the best can be chosen on each and every platform, and can be changed if the optimum changes), and uses an internal html engine.

I liked the original setup of lhelp, no nonsense using an internal widget, I heard Andrew is messing with an external browser backend, and I hope that is only an option for extreme cases.

I don't think you can really instrument a browser perfectly in this, since good instrumentation is a two-way street. (and browsers know nothing about helpsystems). The fact that there is no single browser and no single way of instrumentation to one aggrevates this. DCOM, COM, QT IPC all will require libs to interface to Mozilla, Opera Konquerer etc.

Even if a good helpsystem ever arrives on Linux (which I seriously doubt atm, unless freedesktop gets a whole lot stronger), I think the early steps will be tiny, and horrible compromises, and it will be 4-5 years before something usable is in every distribution.

It's a bit the same as why I don't like helpsystems to be plugin patchworks. Somehow the interface is always the lowest common denomitor, and because the plugin architecture is a weak compromise, the plugins are bad in quality and never really fullfill the potential they could have had, even given the limited (lowestcommon denomitor interface) border conditions.

Such architectures are purely compromises to avoid taking irreversable decisions, but I think usually one gets in a situation where the dominant plugin determines the interface, and the other plugins are stopgaps, still resulting in effectively a monoculture, but one that has unnecessary limitations forced on them for political reasons.

So we keep our own, and keep the documentation in a way that multiple formats can be generated (which I admit is not the case for the latex docs), and wait till there is really a suitable alternative.

It looks like that windows 7 will be chm as default most of its lifetime (since even if htmlhelp3 emerges with a VS release this or next year, it will require additional runtimes to be installed), so the only question is the helpfile situation on Apple (of which I directly admit not having a clue about)

But at least if something is possible there, and somebody is interesting in writing the backends and the ide->helpsystem communication, there is a possibility.

Why use two separate viewers to view the same CHM file format?

First, lhelp is not a viewer but a helpsystem backend. It would be called "lview" otherwise ;-)

And why invent two wheels? A ferrari and a farmers cart should simply use the same ? No, they are designed for totally different purposes, even though they both have wheels.

The .INF duplication is actually worse than this, in that they are both helpsystems, contrary to e.g. gnorpm or kchmviewer which are not.

On Tue, Dec 29, 2009 at 02:06:52PM +0100, Marco van de Voort wrote:

Note that the dependancies bit even goes stronger when you also start to use lhelp for application's help. Which is what I'm currently looking into, and is a target for FPC 2.4.2.

Yesterday I converted a little delphi project(*) that uses chm help on windows, and it worked flawlessly. This will allow me to debug the project support for context sensitive help in applications easier.

(*) it is probably a project for a delphi version that has no built in CHM
support.

2009/12/29 Marco van de Voort :

> Unlike Windows, there is no default CHM viewer for Linux. True. The default depends on desktop suite (gnome ->gnorpm, KDE -> kchmviewer, rest mostly xchm or use a CHM plugin in mozilla)

Not even. I use ChmSee which is also GTK based, but is a lot faster than GnoCHM. :-)

OK, I see my previous email was misunderstood or I misunderstood what I was replying too. There was mention that lhelp will search for CHM files. This is what confused me. I thought lhelp has some hard coded seach text that always searches for RTL, FCL and LCL and Lazarus package help. This is where I got confused between the usage of lhelp compared to other CHM viewers.

But apparently I misunderstood the "search for CHM files" text. I believe there is no "hard coded search for know CHM files" in the lhelp code.

So what? Then at least we can focus lhelp sharply on Lazarus' needs, and not get bogged down in Wine users complaints and feature wishes, just to save

At the moment lhelp seems just like any of the other CHM viewers available under Linux? (to me that is) What exactly makes lhelp different other than maybe performance? Also is there a differences between RTL, FCL and LCL's .CHM files compared to other CHM files shipped with Windows software? If not, then what is the "specific lazarus needs" you are referring too - command line parameter support to enable automatic searches etc?

The other viewers are just that, viewers/ebook readers. lhelp is meant as the backend of an integrated helpsystem. For an IDE.

So what is LCL based applications supposed to use for application help if lhelp is specific for the IDE only? I thought the goal of lhelp is the be a help viewer that can be used by the IDE and applications built with the IDE.

So we keep our own, and keep the documentation in a way that multiple formats can be generated (which I admit is not the case for the latex docs), and wait till there is really a suitable alternative.

I have to agree with this. Latex is excellent for printed documentation, but is not suitable for a "multiple format" output system. LaTeX to HTML or LaTeX to CHM just looks crap! That is why I decided to take the long route and manually convert ref.tex (ref.pdf) to INF format - taking advantage of the features and layout that INF supports. I also wrote a complete new INF backend writer for fpdoc to generate *much better* looking INF documentation of RTL, FCL and LCL. The manual conversion of FPC Language Reference document is actually going quite quickly - LaTeX and INF have a lot in common (describing the content, not the layout). I'm near completion with the ref doc conversion and the way I did it, w make that it is easy to keep it in sync with the Latex version.

First, lhelp is not a viewer but a helpsystem backend. It would be called "lview" otherwise ;-)

Please explain what makes lhelp different? At the moment it simply (clearly to the untrained eye) looks just like a ordinary chm viewer. Only obvious difference is that it's cross platform enabled thanks to FPC and LCL.

I just tested this on Windows XP, and only works (something :-) ) when the CHM files are exactly where they should (/lazarus/docs/html). If I specify another path in the options dialog, then it can?t find any chm files... plus in the zip file there is not lcl.chm.

Horacio

The SimpleIPC unit that lhelp uses for IPC creates a named pipe in tmp that corresponds to the the HelpLabel option. Try setting the HelpLabel value to something. I think that it uses a default and lazhelp and lazhelpclient see if there are similarly named files in /tmp/ and delete them and try again.

Or as I said set your own name and it will use that instead.

Regards,

Andrew

r 23316 now ensures that HelpLabel cannot be blank

2009/12/29 Andrew Haines :

The SimpleIPC unit that lhelp uses for IPC creates a named pipe in tmp that corresponds to the the HelpLabel option. Try setting the HelpLabel value to something. I think that it uses a default and lazhelp and

That was the problem. HelpLabel was blank - and there is now help regarding that opition in the lhelp + CHM wiki page. Setting HelpLabel to some text solves the problem and I found find help on the SysUtils unit for example.

Now the other problem is lhelp itself. Scrolling is totally broken. Click the scrollbar and drag it to scroll to current page. It jumps back and forth erratically between the start and end of the page being viewed.

Also when using the mouse wheel to scroll, once I get to the bottom of the page and keep rolling the mouse wheel the contents starts jumping up/down by about two or three lines continuously.

Seems lhelp still needs lots of testing and debugging before it's ready as a general Lazarus help tool.

Thanks again for help regarding the HelpLabel option.

Graeme Geldenhuys wrote

Not even. I use ChmSee which is also GTK based, but is a lot faster than GnoCHM. :-)

I use kchmviewer mostly to doublecheck, and simply XP/Vista's CHM support. I had some problems with gnochm in the past, and the browser plugin was useless with larger files.

But I'm mostly testing for features etc, so speed is not an objective (for that i use lhelp, or more often, fp)

Lazarus has a chm registry. Currently rtl, fcl,lcl are hardcoded in the UI that registers those in the registry, but afaik that is a GUI, not system limitation.

lhelp doesn't search at all, it gets its data from lazarus, and is fully instrumentable.

The main one that it is instrumentable in a two way direction. IOW they are linked over IPC means, and afaik that is a two way connection. So lhelp can also generate events that Lazarus could react too (e.g. jump to function definition from help, disambiguation choices, copy and paste etc)

The more minor reasons are footprint, dependancies and being integral part of the project. (iow control of both sides)

Also is there a differences between RTL, FCL and LCL's .CHM files compared to other CHM files shipped with Windows software?

No other than that they are not generated by the MS help compiler.

This minor difference works two ways, the con is that the FPC chm compilers might have bugs and/or missing features (which we are stamping out bit by bit), and the pro is the fact that the MS helpcompiler is notoriously bugged (specially with larger helpfiles), which makes some functionality hard to access. Having it as a library is also great for Lazarus' documentation systems.

I don't have an example yet, but when researching CHM, you constantly find references about both the help control and help compiler limitations.

If not, then what is the "specific lazarus needs" you are referring too - command line parameter support to enable automatic searches etc?

Lhelp is a server, and Lazarus is a client (and potentially the applications it generates are a second). You can create any interaction one could need. Multiple popup screens, test views of documentation parts, running results of a CHM search through data of codetools to see if irrelevant options can be eliminated, the sky is the limit.

That's the point I originally thought you meant. I wish I had a smart answer. The objective is of course both, but its current needs are mostly geared towards the IDE. IOW it will need fleshing out, and exploration.

I don't work on lazarus<-> lhelp much, but I do like the general setup, except maybe the fact that lazarus has a plugin system that forces load of all indexes on start. That's a time and memory hog.

I've had this discussion now (for 4 or 5 different latex2 converters) more times than I would have liked. All these failed before. Including postedit events etc. Same with the original ps2pdf conversions (before pdflatex), which were very nicely postedited, but a while later that initiative also failed (but in that case we got saved by improvements in pdflatex and hyperref)

Maybe it is because the converters are general latex2* converters, and a specific one under our control would be more succesful, without the kind of infinite catch up that you describe (which usually works fine for a few versions till the maintainer runs out of steam).

But that first would mean agreeing on a latex subset, something that Michael always has refused afaik.

Switching to another format is no solution IMHO, specially not as arcane as INF.

See above.

2009/12/29 Marco van de Voort :

Lazarus has a chm registry. Currently rtl, fcl,lcl are hardcoded in the UI

Ah, so that is what was meant by "search". Looking through the registry of CHM help files managed by the IDE.

The main one that it is instrumentable in a two way direction. IOW they are linked over IPC means, and afaik that is a two way connection. So lhelp can

Ah, you guys beat me to it. :-) I planned that for fpGUI's DocView as well. Managing things like tutorial based help where DocView tells the application to advance to the next step, or the application informs docview of help window size change etc... The two-way communication is a very handle feature I think.

answer. The objective is of course both, but its current needs are mostly geared towards the IDE.

Ah, good to know the current goal of lhelp. DocView is primarily designed for application help, but then the IDE is also an application. :-)

except maybe the fact that lazarus has a plugin system that forces load of all indexes on start. ?That's a time and memory hog.

After getting lhelp working via the IDE I immediately noticed the slow loading time, even for a small help file like rtl.chm it is noticeable.

times than I would have liked. All these failed before. Including postedit events etc. Same with the original ps2pdf conversions (before pdflatex),

I quickly noticed that with the Latex to INF converter I wrote. Latex can get quite complex and is very hard to translate programmaticly. I will use it only for the odd Latext document conversions, but for the FPC Language Reference document I wanted a neatly formatted and well layout document, just like what latex produces for printing (in PDF format). That's why I decided to convert that document manually.

But that first would mean agreeing on a latex subset, something that Michael always has refused afaik. Switching to another format is no solution IMHO

I immediately made it clear to Michael that my INF conversion of the ref document is not a suggestion that he must change to INF format. The INF format is simply an additional benefit to the original PDF document. I have no problem with this, after all, Michael did all the documentation work so he is entitled to dictate the documentation format he wants to write in.

This is not lhelp problems but turbopower ipro component which we are using to show html.

Best regards,
Paul Ishenin.