On 2/23/2016 9:11 PM, clipka wrote:
> Am 13.02.2016 um 19:02 schrieb Jim Holsenback:
>
>>> I'm going to go ahead and step back from this.
>>
>> attached is a gzip archive which contains php scripts notes and results
>> that show the scope of the problem. no images included to reduce the
>> payload of the archive
>
> I'm afraid that to me, who has virtually no PHP experience whatsoever,
> the contents of that archive don't give many clues.
>
> First of all, what is the nature of the work to do? I previously had the
> impression that it was a matter of modifying the Wiki content to fit an
> existing conversion process, but this seems more like modifying an
> existing conversion process to fit the Wiki content, right?
>
>
> But somehow I think I fail to see the actual problem. After all, it
> seems to be just a matter of replacing everything that matches
> `{{#indexentry:ANY TEXT}}` with `<a name="ndxntry_NUMBER"
> id="ndxntry_NUMBER"></a>`, while compiling a list(*) of mappings between
> keywords (as specified by the `ANY TEXT` portion) and the respective
> replacement hypertext anchors (as given by `ndxntry_NUMBER`).
>
> (* Or so I presume; I haven't been able to identify that generated list
> yet. I'd have expected the process to generate a .hhk file, but that
> doesn't seem to be the case.)
>
> Analyzing the `ANY TEXT` portion to catch the special cases seems to be
> the tricky part, but even that doesn't look too difficult. At present I
> only see the `Keyword1|Keyword2|...` and `Keyword, Section` cases that
> need handling. The former should be easy: Just generate multiple
> separate entries in the mapping file. The latter -- well, that depends
> on the format of the file that needs to be generated.
>
>
> Am I missing something fundamental here?
>

I NEVER was responsible for the windows documentation (chm version) I 
just produced a html version (from wiki) that contained the indexentry 
tags as they appeared in the wiki mark-up and passed it on to Chris. He 
did some post processing that converted to chm and also produced the 
searchable index. In the process of attempting to unravel I discovered 
that the markup has more than a few indexentry tags that need to be 
checked / fixed. The main php script in the archive I attached (earlier) 
was just a tool to help quantify the problem a identify where the 
offending tags are in the markup. Once that has been addressed I'd 
imagine the post processing code would need to be looked at as well. 
That brings to mind why chm ... it's been obsolete for sometime now and 
only exists as legacy now. At any rate I got tired of being the only 
person doing /any/ of the grunt work necessary to get this fixed. I 
don't use windows version so this just dropped off my radar. I getting 
plenty of mileage out of stand-alone unix version docs. When I want to 
find something quickly I just go 3.3.1.2 Keywords section.

Post a reply to this message