 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There has been some talk about how the search function in the Help
file is broken.
I had forgotten about this workaround until I used it without thinking.
When you search for a keyword and Help takes you to the top of a large
page. Left click on the right hand pane and press Ctrl + F to bring up a
search box. There you can search for your keyword.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/1/2016 8:52 AM, Stephen wrote:
> There has been some talk about how the search function in the Help
> file is broken.
> I had forgotten about this workaround until I used it without thinking.
> When you search for a keyword and Help takes you to the top of a large
> page. Left click on the right hand pane and press Ctrl + F to bring up a
> search box. There you can search for your keyword.
>
Some of the pages are simply too long. I can barely grab onto the
scrollbar handle.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16-02-01 17:43, Mike Horvath a écrit :
> On 2/1/2016 8:52 AM, Stephen wrote:
>> There has been some talk about how the search function in the Help
>> file is broken.
>> I had forgotten about this workaround until I used it without thinking.
>> When you search for a keyword and Help takes you to the top of a large
>> page. Left click on the right hand pane and press Ctrl + F to bring up a
>> search box. There you can search for your keyword.
>>
>
> Some of the pages are simply too long. I can barely grab onto the
> scrollbar handle.
>
>
> Mike
Yes, section 3 is huge. It shoulod be broken down to more manageable
chunks, like a section for the primitives, one for the lights, one for
the cameras,...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/1/2016 10:43 PM, Mike Horvath wrote:
> On 2/1/2016 8:52 AM, Stephen wrote:
>> There has been some talk about how the search function in the Help
>> file is broken.
>> I had forgotten about this workaround until I used it without thinking.
>> When you search for a keyword and Help takes you to the top of a large
>> page. Left click on the right hand pane and press Ctrl + F to bring up a
>> search box. There you can search for your keyword.
>>
>
> Some of the pages are simply too long. I can barely grab onto the
> scrollbar handle.
>
>
That is why the pop up search box is handy. The focus jumps to the first
found search item. At least in the windows version it does.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/2/2016 5:05 AM, Stephen wrote:
> On 2/1/2016 10:43 PM, Mike Horvath wrote:
>> On 2/1/2016 8:52 AM, Stephen wrote:
>>> There has been some talk about how the search function in the Help
>>> file is broken.
>>> I had forgotten about this workaround until I used it without thinking.
>>> When you search for a keyword and Help takes you to the top of a large
>>> page. Left click on the right hand pane and press Ctrl + F to bring up a
>>> search box. There you can search for your keyword.
>>>
>>
>> Some of the pages are simply too long. I can barely grab onto the
>> scrollbar handle.
>>
>>
> That is why the pop up search box is handy. The focus jumps to the first
> found search item. At least in the windows version it does.
>
It is still a PITA to scroll up and down that page though. It's hard to
grab the scrollbar handle, and when you do grab it you can't move it in
small increments. This is easily solvable by just splitting the page
into a few smaller portions.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.02.2016 um 05:30 schrieb Mike Horvath:
> It is still a PITA to scroll up and down that page though. It's hard to
> grab the scrollbar handle, and when you do grab it you can't move it in
> small increments. This is easily solvable by just splitting the page
> into a few smaller portions.
>
> Mike
Still using a mouse without a scroll wheel?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/3/2016 1:30 PM, clipka wrote:
> Am 03.02.2016 um 05:30 schrieb Mike Horvath:
>> It is still a PITA to scroll up and down that page though. It's hard to
>> grab the scrollbar handle, and when you do grab it you can't move it in
>> small increments. This is easily solvable by just splitting the page
>> into a few smaller portions.
>>
>> Mike
>
> Still using a mouse without a scroll wheel?
>
Never designed a GUI application before?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16-02-03 13:30, clipka a écrit :
> Am 03.02.2016 um 05:30 schrieb Mike Horvath:
>> It is still a PITA to scroll up and down that page though. It's hard to
>> grab the scrollbar handle, and when you do grab it you can't move it in
>> small increments. This is easily solvable by just splitting the page
>> into a few smaller portions.
>>
>> Mike
>
> Still using a mouse without a scroll wheel?
>
If you have a few hours available to invest into scrolling through that
page... Beter use the Page Up and page Down keys to navigate here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/3/2016 5:33 PM, Alain wrote:
> Le 16-02-03 13:30, clipka a écrit :
>> Am 03.02.2016 um 05:30 schrieb Mike Horvath:
>>> It is still a PITA to scroll up and down that page though. It's hard to
>>> grab the scrollbar handle, and when you do grab it you can't move it in
>>> small increments. This is easily solvable by just splitting the page
>>> into a few smaller portions.
>>>
>>> Mike
>>
>> Still using a mouse without a scroll wheel?
>>
>
> If you have a few hours available to invest into scrolling through that
> page... Beter use the Page Up and page Down keys to navigate here.
I think I've also noticed the page not loading 100% before the program
tries to resolve a link or index. I.e. the navigation falls short of the
target anchor because the page hasn't fully loaded yet. Which shouldn't
happen in document stored on the local hard drive.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/3/2016 8:16 PM, Mike Horvath wrote:
> On 2/3/2016 5:33 PM, Alain wrote:
>> Le 16-02-03 13:30, clipka a écrit :
>>> Am 03.02.2016 um 05:30 schrieb Mike Horvath:
>>>> It is still a PITA to scroll up and down that page though. It's hard to
>>>> grab the scrollbar handle, and when you do grab it you can't move it in
>>>> small increments. This is easily solvable by just splitting the page
>>>> into a few smaller portions.
>>>>
>>>> Mike
>>>
>>> Still using a mouse without a scroll wheel?
>>>
>>
>> If you have a few hours available to invest into scrolling through that
>> page... Beter use the Page Up and page Down keys to navigate here.
>
> I think I've also noticed the page not loading 100% before the program
> tries to resolve a link or index. I.e. the navigation falls short of the
> target anchor because the page hasn't fully loaded yet. Which shouldn't
> happen in document stored on the local hard drive.
>
>
> Mike
If I have the time I may look at the docs and see why the indices are
all messed up. It should be a simple but maybe tedious task, since I've
worked on HTML Help documents in the past.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.02.2016 um 02:17 schrieb Mike Horvath:
> If I have the time I may look at the docs and see why the indices are
> all messed up. It should be a simple but maybe tedious task, since I've
> worked on HTML Help documents in the past.
If you do, don't forget that the docs are auto-generated from the Wiki
content.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/3/2016 8:48 PM, clipka wrote:
> Am 04.02.2016 um 02:17 schrieb Mike Horvath:
>
>> If I have the time I may look at the docs and see why the indices are
>> all messed up. It should be a simple but maybe tedious task, since I've
>> worked on HTML Help documents in the past.
>
> If you do, don't forget that the docs are auto-generated from the Wiki
> content.
>
Where in the wiki are the indices stored?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/3/2016 8:17 PM, Mike Horvath wrote:
> On 2/3/2016 8:16 PM, Mike Horvath wrote:
>> On 2/3/2016 5:33 PM, Alain wrote:
>>> Le 16-02-03 13:30, clipka a écrit :
>>>> Am 03.02.2016 um 05:30 schrieb Mike Horvath:
>>>>> It is still a PITA to scroll up and down that page though. It's
>>>>> hard to
>>>>> grab the scrollbar handle, and when you do grab it you can't move
>>>>> it in
>>>>> small increments. This is easily solvable by just splitting the page
>>>>> into a few smaller portions.
>>>>>
>>>>> Mike
>>>>
>>>> Still using a mouse without a scroll wheel?
>>>>
>>>
>>> If you have a few hours available to invest into scrolling through that
>>> page... Beter use the Page Up and page Down keys to navigate here.
>>
>> I think I've also noticed the page not loading 100% before the program
>> tries to resolve a link or index. I.e. the navigation falls short of the
>> target anchor because the page hasn't fully loaded yet. Which shouldn't
>> happen in document stored on the local hard drive.
>>
>>
>> Mike
>
> If I have the time I may look at the docs and see why the indices are
> all messed up. It should be a simple but maybe tedious task, since I've
> worked on HTML Help documents in the past.
>
the reason that (for windows help) the indices are messed up has nothing
to do with the wiki files or the code written to pull the docs from the
wiki ... it's the post processing that formats it into a windows help
file. the former i have control over, the later i do not
>
> Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/8/2016 9:32 AM, Jim Holsenback wrote:
> the reason that (for windows help) the indices are messed up has nothing
> to do with the wiki files or the code written to pull the docs from the
> wiki ... it's the post processing that formats it into a windows help
> file. the former i have control over, the later i do not
just recalled another reason that's also contributing to the busted
indices issue ... there are a fair number of indexentry tags that did
NOT get converted to the new tag style (a last minute change) i did SOME
of them but obviously not ALL ... there's an office politics reason why
and i don't think getting into that is appropriate in this forum.
windows help is the ONLY flavor of docs that even cares about this, the
mac and nix flavors have them stripped out.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/8/2016 2:32 PM, Jim Holsenback wrote:
> the reason that (for windows help) the indices are messed up has nothing
> to do with the wiki files or the code written to pull the docs from the
> wiki ... it's the post processing that formats it into a windows help
> file. the former i have control over, the later i do not
Welcome back. Long time no see.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/8/2016 11:08 AM, Stephen wrote:
> On 2/8/2016 2:32 PM, Jim Holsenback wrote:
>> the reason that (for windows help) the indices are messed up has nothing
>> to do with the wiki files or the code written to pull the docs from the
>> wiki ... it's the post processing that formats it into a windows help
>> file. the former i have control over, the later i do not
>
>
> Welcome back. Long time no see.
Thanks ... back wouldn't be entirely correct. Not much time for tracing
ray's lately. Just an occasional touch-n-go.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/8/2016 4:45 PM, Jim Holsenback wrote:
>
> Thanks ... back wouldn't be entirely correct. Not much time for tracing
> ray's lately. Just an occasional touch-n-go.
I've not been Poving much myself. I've been poorly but getting over it
now. :-)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.02.2016 um 13:15 schrieb Mike Horvath:
> On 2/3/2016 8:48 PM, clipka wrote:
>> Am 04.02.2016 um 02:17 schrieb Mike Horvath:
>>
>>> If I have the time I may look at the docs and see why the indices are
>>> all messed up. It should be a simple but maybe tedious task, since I've
>>> worked on HTML Help documents in the past.
>>
>> If you do, don't forget that the docs are auto-generated from the Wiki
>> content.
>>
>
> Where in the wiki are the indices stored?
The magic is in the "{{#indexentry:...}}" tags.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback <spa### [at] nothanks net> wrote:
> the reason that (for windows help) the indices are messed up has nothing
> to do with the wiki files or the code written to pull the docs from the
> wiki ... it's the post processing that formats it into a windows help
> file. the former i have control over, the later i do not
You know, given no other Wiki editors ever materialised in years, one might
considert backporting to the 3.6 docs format that worked flawlessly, even though
it wasn't a well documented process. Still having broken docs all over the place
is hardly going to help new users getting started...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/1/2016 8:52 AM, Stephen wrote:
> There has been some talk about how the search function in the Help
> file is broken.
> I had forgotten about this workaround until I used it without thinking.
> When you search for a keyword and Help takes you to the top of a large
> page. Left click on the right hand pane and press Ctrl + F to bring up a
> search box. There you can search for your keyword.
>
Just to be clear about this I'm responding to the head of this thread so
as to not have it taken that I'm commenting to anyone in particular.
I'm absolutely certain the problem is all the indexentry tags that DID
NOT get converted to the new format imposed at the last minute.
I'm going to go ahead and step back from this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/8/2016 9:33 PM, Jim Holsenback wrote:
> On 2/1/2016 8:52 AM, Stephen wrote:
>> There has been some talk about how the search function in the Help
>> file is broken.
>> I had forgotten about this workaround until I used it without thinking.
>> When you search for a keyword and Help takes you to the top of a large
>> page. Left click on the right hand pane and press Ctrl + F to bring up a
>> search box. There you can search for your keyword.
>>
>
> Just to be clear about this I'm responding to the head of this thread so
> as to not have it taken that I'm commenting to anyone in particular.
>
> I'm absolutely certain the problem is all the indexentry tags that DID
> NOT get converted to the new format imposed at the last minute.
>
> 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
createSubIndex.php scans the files in directory tagged (these files are
un-post processed windows docs pulled from wiki) and writes to directory
indexed. the .txt files are the break outs. of special interest ...
progress.txt as you can see there are > 1500 tags that need to be
converted in the wiki mark-up
Post a reply to this message
Attachments:
Download 'subject-index.tar.gz' (1442 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/13/2016 1:02 PM, Jim Holsenback wrote:
> On 2/8/2016 9:33 PM, Jim Holsenback wrote:
> createSubIndex.php scans the files in directory tagged (these files are
> un-post processed windows docs pulled from wiki) and writes to directory
> indexed. the .txt files are the break outs. of special interest ...
> progress.txt as you can see there are > 1500 tags that need to be
> converted in the wiki mark-up
several more things ...
- unpack the archive preserving directory structure. work in
subject-index. i've "grouped" the tag types. create-SubIndex has some
hints (comments in the code) and so do the .txt filenames that i used.
- i figured if i could filter, i could convert them to a landing spot
from the index. the simpler (and some of the compound) tag forms have
been done. sans the conversion to a landing place.
- compound tags are a single landing place for more than one topic from
the index
- i've discovered some of the compound tags (in the mark-up) are
malformed, that is they aren't formatted correctly, or their intent is
not clear. some of the more complex tags can be made simpler without
sacrificing intent. finding them and cleaning them up (on the wiki) is
the biggest task.
- once the mark-up has been fixed and all tags types can be parsed
correctly. it's easy enough to reformat into a landing place.
... i'm sure there's more
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.02.2016 um 14:41 schrieb Jim Holsenback:
> On 2/23/2016 9:11 PM, clipka wrote:
>> 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.
That does sound fundamental indeed.
> That brings to mind why chm ... it's been obsolete for sometime now and
> only exists as legacy now.
That's pretty simple to answer: It's what POV-Ray for Windows has been
using for its inbuilt help for quite a while; switching to any
alternative would require changing the program code -- and in the case
of the official alternative the input to the help file compiler would be
exactly the same, so it wouldn't solve the problem at all.
As a matter of fact, the newest official "alternative" to CHM seems to
be to have no context-sensitive help at all, or to roll your own.
> At any rate I got tired of being the only
> person doing /any/ of the grunt work necessary to get this fixed.
If the goal is to repair stuff in the Wiki, I wonder whether there is
anyone else /able/ to do that "grunt work" with reasonable effort. After
all, it seems like something that can be automated -- but that certainly
requires "bulk" access to the Wiki, which you seem to have. I presume
Chris has this level of access, too, but we all know he doesn't have
much time to spare.
> 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.
Still not as elegant as placing the cursor on a keyword and pressing "F1".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/24/2016 8:41 AM, Jim Holsenback wrote:
> 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.
CHM is pretty great. Quick loading when compared to PHP. Can search all
help files or just within one page. Nested, alphabetical index with more
stuff than just key terms. A TOC that is always visible and within easy
reach, and automatically shows/highlights the page you are on.
Context-sensitive help, as clipka mentioned.
I don't think anyone here is going to roll an alternative that is just
as good. Just because an OSS alternative is /possible/ doesn't mean
anyone will get around to actually making it.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/24/2016 10:05 PM, Mike Horvath wrote:
> On 2/24/2016 8:41 AM, Jim Holsenback wrote:
>> 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.
>
> CHM is pretty great. Quick loading when compared to PHP. Can search all
> help files or just within one page. Nested, alphabetical index with more
> stuff than just key terms. A TOC that is always visible and within easy
> reach, and automatically shows/highlights the page you are on.
> Context-sensitive help, as clipka mentioned.
You've misunderstood ... PHP is ONLY used to pull from wiki and format
back into to the standalone html packages (win, nix and mac)
>
> I don't think anyone here is going to roll an alternative that is just
> as good. Just because an OSS alternative is /possible/ doesn't mean
> anyone will get around to actually making it.
>
>
> Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/25/2016 9:12 AM, Jim Holsenback wrote:
> On 2/24/2016 10:05 PM, Mike Horvath wrote:
>> On 2/24/2016 8:41 AM, Jim Holsenback wrote:
>>> 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.
>>
>> CHM is pretty great. Quick loading when compared to PHP. Can search all
>> help files or just within one page. Nested, alphabetical index with more
>> stuff than just key terms. A TOC that is always visible and within easy
>> reach, and automatically shows/highlights the page you are on.
>> Context-sensitive help, as clipka mentioned.
>
> You've misunderstood ... PHP is ONLY used to pull from wiki and format
> back into to the standalone html packages (win, nix and mac)
>
>>
>> I don't think anyone here is going to roll an alternative that is just
>> as good. Just because an OSS alternative is /possible/ doesn't mean
>> anyone will get around to actually making it.
>>
>>
>> Mike
>
I didn't mention PHP.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.02.2016 um 21:18 schrieb Mike Horvath:
> On 2/25/2016 9:12 AM, Jim Holsenback wrote:
>> On 2/24/2016 10:05 PM, Mike Horvath wrote:
...
>>> CHM is pretty great. Quick loading when compared to PHP. Can search all
...
>> You've misunderstood ... PHP is ONLY used to pull from wiki and format
>> back into to the standalone html packages (win, nix and mac)
...
> I didn't mention PHP.
You didn't?
My eyes must be getting bad then. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/25/2016 10:17 PM, clipka wrote:
> Am 25.02.2016 um 21:18 schrieb Mike Horvath:
>> On 2/25/2016 9:12 AM, Jim Holsenback wrote:
>>> On 2/24/2016 10:05 PM, Mike Horvath wrote:
> ...
>>>> CHM is pretty great. Quick loading when compared to PHP. Can search all
> ...
>>> You've misunderstood ... PHP is ONLY used to pull from wiki and format
>>> back into to the standalone html packages (win, nix and mac)
> ...
>> I didn't mention PHP.
>
> You didn't?
> My eyes must be getting bad then. ;)
>
Oops! Well, I meant that some people have advocated having only a wiki
and no standalone docs. I would prefer keeping the CHM docs over this.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
