H&M 7.1, PP 3.15, eWriter
Moderators: Alexander Halser, Tim Green
H&M 7.1, PP 3.15, eWriter
I'm experimenting with converting my CHM help to eWriter, and have a few questions about creating the eWriter eBook:
1) The help says that the eWriter format supports the WebHelp skins, but that doesn't seem to be true for all WebHelp skins. I get errors when trying to use the V3 Responsive skins -- are they in fact not supported? It seems that the V2 skins are supported; any others that I could try?
2) If the v3 skins aren't supported, will there be new/updated v2 eWriter skins, or are they being deprecated in favor of the "full" webhelp?
3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?
4) Any way to get it to remember the position of the splitter?
5) The up/down cursor keys don't work in the contents / index windows -- are they not supported?
Thanks for your help.
1) The help says that the eWriter format supports the WebHelp skins, but that doesn't seem to be true for all WebHelp skins. I get errors when trying to use the V3 Responsive skins -- are they in fact not supported? It seems that the V2 skins are supported; any others that I could try?
2) If the v3 skins aren't supported, will there be new/updated v2 eWriter skins, or are they being deprecated in favor of the "full" webhelp?
3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?
4) Any way to get it to remember the position of the splitter?
5) The up/down cursor keys don't work in the contents / index windows -- are they not supported?
Thanks for your help.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: H&M 7.1, PP 3.15, eWriter
Hi Rex,Rex Conn wrote:1) The help says that the eWriter format supports the WebHelp skins, but that doesn't seem to be true for all WebHelp skins. I get errors when trying to use the V3 Responsive skins -- are they in fact not supported? It seems that the V2 skins are supported; any others that I could try?
EWriter (like CHM) is for Windows only, not mobile devices. So it doesn't need to be responsive, but you can use the native (non PP) responsive skins if you wish. You can use any skins in EWriter other than the PP V3 responsive skins which are intended for Webhelp on mobile devices. In PP the V2 skins are specifically marked for EWriter, and offer better functionality for the Keyword Index and multi-tabbed viewing than V3.
Definitely not deprecated -- EWriter is the future for integrated software Help! Tim will no doubt be answering about his plans for future PP developments and new EWriter skins.2) If the v3 skins aren't supported, will there be new/updated v2 eWriter skins, or are they being deprecated in favor of the "full" webhelp?
Yes, very easily. See context links: http://help.ec-software.com/index.html? ... ctions.htm3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?
Over to Alex on that one -- put it on the Wish List here if it's important to you. You can set the initial width of the navigation pane in the skin settings. If you use one of the native responsive skins, the splitter position is controlled by the skin.4) Any way to get it to remember the position of the splitter?
Using a V2 skin the Up/Down keys and Home/End keys are working in the Index for me, and in the topics and Search results. But you need to click on the topic pane to focus it first. Likewise after clicking to focus it they work in the navigation pane for scrolling the TOC, but not to select items.5) The up/down cursor keys don't work in the contents / index windows -- are they not supported?
If you want to use the keyboard to select items in the TOC, click the Previous or Next buttons to focus them. Then you can use the Enter key repeatedly to select the topics in sequence.
There is limited keyboard support in EWriter, but Alex has just added Ctrl-0 zoom reset in the latest beta, and no doubt could add more. Using the native responsive skins, only the Home/End keys seem to work in EWriter (Alex?).
regards,
Martin.
- Tim Green
- Site Admin
- Posts: 23186
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: H&M 7.1, PP 3.15, eWriter
Hi Rex,
Martin has provided detailed answers to pretty much everything so I just have a couple of additional comments. The V3 skins wouldn't make sense in EWriter because they are specifically designed to respond to phones, tablets and desktop browsers, and a large amount of what they do would be irrelevant there.
The main thing the cookies as session variables are going to provide now is the ability for you to pass your own parameters to your own scripts in the skin with your URLs, for example with something like
You only need to pass this with one call and it will then be saved in a session variable cookie for the entire session. Then you could read the cookie on every page load and do something to the page on the basis of it before displaying it. Since the cookies persist for the entire session, this also means they persist on new calls from your app, which reload the entire UI within the viewer. For example, you could hide or display texts on the page based on style names, or load different boilerplate texts into named <div> containers on the page. These can be saved in topic files without TOC entries, which will be excluded from the search as long as their IDs start with an underscore (e.g. _text1, _beginnerlicense).,
Martin has provided detailed answers to pretty much everything so I just have a couple of additional comments. The V3 skins wouldn't make sense in EWriter because they are specifically designed to respond to phones, tablets and desktop browsers, and a large amount of what they do would be irrelevant there.
The context links Martin was referring to there are actually also for accessing topics, but using CHM context numbers instead of topic IDs. In the V2 EWriter/WebHelp skins you have URL switches that you can include in your call to open with the search or index panes passively, or combined with a specific search in either pane. These switches work in EWriter because it actually has its own internal mini web server. See the "Using URL Switches" topic in the V2 WebHelp and EWriters skins section of the Premium Pack help chapter for details.3) Is there any way to bring up the eBook with a specific pane (contents, index, search) selected?
That depends on how long you want to remember it. You definitely won't be able to remember it across different viewer sessions, because there is no external storage for state data. Every time the viewer opens it comes with a clean slate. It is effectively like a fresh instance of a virtual machine containing only a browser. However, we have just updated the viewer so that cookies work as session variables. This means that you can store state data in a cookie and that will persist across multiple calls to the viewer from your application. It thus becomes possible to save state information. If I find the time before the release of the 3.2 update next week I'll add persistence of the splitter position and the top menu state (open/closed) to the EWriter skins with that.4) Any way to get it to remember the position of the splitter?
The main thing the cookies as session variables are going to provide now is the ability for you to pass your own parameters to your own scripts in the skin with your URLs, for example with something like
Code: Select all
myviewer.exe mybook.ebk "index.html?overview.html&license=beginner"
I'm very much open to suggestions on this. The current EWriter skins are still a bit top-heavy and not as fast as I would like, for example. My first next project in that direction would be some slim EWriter skins using WebHelp 3 technology but without the mobile device overheads, so you get the benefits of the radically improved browsing speed within EWriter.Definitely not deprecated -- EWriter is the future for integrated software Help! Tim will no doubt be answering about his plans for future PP developments and new EWriter skins.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
-
- Posts: 454
- Joined: Thu Nov 16, 2006 1:29 pm
- Location: London, UK
Re: H&M 7.1, PP 3.15, eWriter
Just out of curiosity, wouldn't sessionStorage and localStorage be more appropriate/efficient/easier to code etc?Tim Green wrote:we have just updated the viewer so that cookies work as session variables.
- Tim Green
- Site Admin
- Posts: 23186
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: H&M 7.1, PP 3.15, eWriter
No. And for a while at least, we still have to pay lip service to older versions of Windows that don't run IE11. And since WebView is always the current version of IE it wouldn't work there.Simon Dismore wrote:Just out of curiosity, wouldn't sessionStorage and localStorage be more appropriate/efficient/easier to code etc?
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
-
- Posts: 454
- Joined: Thu Nov 16, 2006 1:29 pm
- Location: London, UK
Re: H&M 7.1, PP 3.15, eWriter
Oh, I thought local storage was supported all the way back to IE8.Tim Green wrote:No. And for a while at least, we still have to pay lip service to older versions of Windows that don't run IE11. And since WebView is always the current version of IE it wouldn't work there.Simon Dismore wrote:Just out of curiosity, wouldn't sessionStorage and localStorage be more appropriate/efficient/easier to code etc?
- Tim Green
- Site Admin
- Posts: 23186
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: H&M 7.1, PP 3.15, eWriter
Hmm... I thought there were at least wonky performance issues pre-11 but I'll have to check that. What I just discovered is really interesting is that localStorage persists across sessions in EWriter. That opens up some fascinating possibilities, but also some possibilities for some rather nasty bugs:Simon Dismore wrote:Oh, I thought local storage was supported all the way back to IE8.
The problem is that localStorage for EWriter is globally the same domain anywhere on the current computer. I just tried writing a value in one book stored in one location and I was able to read it from a completely different book in a different location and a completely new session. So anything you store in one EWriter book is persistently available to ALL other EWriter books. It would probably be necessary to change the internal domain to avoid this, and until that is possible my personal instinct would be to use sessionStorage only.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
-
- Posts: 454
- Joined: Thu Nov 16, 2006 1:29 pm
- Location: London, UK
Re: H&M 7.1, PP 3.15, eWriter
That makes sense. Is the ewriter host domain or port configurable? I suppose domain-specific storage would be for title-specific settings, with a shared local storage for settings that apply to all titles, e.g. splitter position, maybe font size. Perhaps you could fake the title-specific stuff by using a naming convention, e.g. localStorage.setItem(<%TITLE%>+'.currentpage',<%TOPICID%>). Interesting stuff!Tim Green wrote:Simon Dismore wrote:The problem is that localStorage for EWriter is globally the same domain anywhere on the current computer. I just tried writing a value in one book stored in one location and I was able to read it from a completely different book in a different location and a completely new session. So anything you store in one EWriter book is persistently available to ALL other EWriter books. It would probably be necessary to change the internal domain to avoid this, and until that is possible my personal instinct would be to use sessionStorage only.
This stack overflow discussion might be useful if you are trying localStorage in IE8, btw.
- Tim Green
- Site Admin
- Posts: 23186
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: H&M 7.1, PP 3.15, eWriter
Hi Simon,
Just did some more testing: IE8 is really a non-issue because the EWriter/WebHelp skins don't support it anyway, and all post-XP versions of Windows can and should install IE11.
On ports: Every EWriter viewer instance has a different port number, starting consecutively with 8000, but localStorage is still persistent across all of them. You can't change the domain because it's 127.0.0.1 (i.e. localhost) and storage is clearly persistent for the whole kit and caboodle. My suggestion for this would be to use a prefix based on the book name for all persistent localStorage values and to only do this for innocuous things like slider position and header state. And never put critical data like license keys or user license levels there, only use sessionStorage for that, if at all.
PS: It's important to be aware that localStorage is easy to enumerate: Anything on the same domain can read out all the keys and values stored there. As long as it passes the same domain test it's available to any other page on the domain.
Just did some more testing: IE8 is really a non-issue because the EWriter/WebHelp skins don't support it anyway, and all post-XP versions of Windows can and should install IE11.
On ports: Every EWriter viewer instance has a different port number, starting consecutively with 8000, but localStorage is still persistent across all of them. You can't change the domain because it's 127.0.0.1 (i.e. localhost) and storage is clearly persistent for the whole kit and caboodle. My suggestion for this would be to use a prefix based on the book name for all persistent localStorage values and to only do this for innocuous things like slider position and header state. And never put critical data like license keys or user license levels there, only use sessionStorage for that, if at all.
PS: It's important to be aware that localStorage is easy to enumerate: Anything on the same domain can read out all the keys and values stored there. As long as it passes the same domain test it's available to any other page on the domain.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: H&M 7.1, PP 3.15, eWriter
Hi Tim,Tim Green wrote:I'm very much open to suggestions on this. The current EWriter skins are still a bit top-heavy and not as fast as I would like, for example. My first next project in that direction would be some slim EWriter skins using WebHelp 3 technology but without the mobile device overheads, so you get the benefits of the radically improved browsing speed within EWriter.Definitely not deprecated -- EWriter is the future for integrated software Help! Tim will no doubt be answering about his plans for future PP developments and new EWriter skins.
My hope for the future of EWriter would be to get away entirely from using a web browser for the HTML rendering and do the whole thing in Delphi, similar to the old HM5 EBook format. This would do away with any worries about security, local storage, use of cookies, and all the funnies in IE etc., such as the right-click menu cursor issue. Doing it all in Delphi would mean you can do anything you want, and it works on all systems.
It's not such a fanciful idea. David Baldwin's THtmlFrameViewer component already supports a browsing history and most CSS, and is only lacking in javascript. If you do everything in Delphi you don't need javascript, and the code is now open source for anyone to try. What's more it runs on Wine for my Linux/Mac/CrossOver users, which EWriter doesn't. This is a bit of bog-standard H&M Webhelp output opened in THtmlFrameViewer:
I've already made several changes in the code to allow easy zooming, file links and call-backs. My intention is to implement the expanding/collapsing TOC in Delphi, and all the other javascript stuff such as toggles, and to add a search function using the Zoom Indexer.
But that's just me messing about. I'm sure if the EC Software wizards put their minds to it, EWriter could be transformed into an amazing stand-alone application with no reliance on any web browser.
Martin.
You do not have the required permissions to view the files attached to this post.
- Tim Green
- Site Admin
- Posts: 23186
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: H&M 7.1, PP 3.15, eWriter
Hi Martin,
What benefit would you get from expending a huge amount of effort to recreate the wheel like that? And what genuine disadvantages do you have when using the IE WebView in EWriter? Remember, you are NOT using an open clone of the IE browser. That is a frequent misunderstanding regarding WebView: It's not the browser, it's just the HTML rendering engine with CSS and JS support. It is effectively an HTML virtual machine in a sandbox.
That reminds me of Dr. Johnson's remark on the dispute over the authorship of Shakespeare's plays, where he said that they were "either written by William Shakespeare, or by someone else of the same name."My hope for the future of EWriter would be to get away entirely from using a web browser for the HTML rendering and do the whole thing in Delphi,
What benefit would you get from expending a huge amount of effort to recreate the wheel like that? And what genuine disadvantages do you have when using the IE WebView in EWriter? Remember, you are NOT using an open clone of the IE browser. That is a frequent misunderstanding regarding WebView: It's not the browser, it's just the HTML rendering engine with CSS and JS support. It is effectively an HTML virtual machine in a sandbox.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: H&M 7.1, PP 3.15, eWriter
Hi Tim,Tim Green wrote:What benefit would you get from expending a huge amount of effort to recreate the wheel like that?
It would be a better wheel. When something crops up which you don't like, such as the poor right-click menu in WebView, you can fix it in your own code. And it is not such a huge amount of effort -- David Baldwin, and no doubt others, has already done all the heavy lifting. His HTML rendering engine is very pleasant -- frames, tables, borders, background-colors, hover effects, everything you could want. And if it isn't what you want you can change it. Have you ever tried to change anything in IE?
My problem of course is that I always want to change things. For example there is no obvious reason why the Earth should revolve anti-clockwise.
regards,
Martin.
- Tim Green
- Site Admin
- Posts: 23186
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: H&M 7.1, PP 3.15, eWriter
That is physically impossible with the state of HTML rendering engines at the moment. Either it would be based on an existing engine, which would be redundant, or it would be garbage. There is nothing in between, because an HTML engine is either 100% perfect or completely useless. It would be shooting yourself in both feet to publish a commercial product like Help+Manual with anything except the standard engine for the platform, which is the IE WebView in the case of Windows.Martin Wynne wrote:It would be a better wheel.
This is so far away from the realm of possibility that it is not worth discussing. It is never ever going to happen.
Then you're going to have to build your own.My problem of course is that I always want to change things.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: H&M 7.1, PP 3.15, eWriter
OK then, don't use HTML for EWriter output. Use the same RVF viewer which you use for the H&M editor. You already have the topics in RVF format, so you have a head start. I'm using Sergey's TRichView in my application and it is very capable, as you know. But I have changed it a bit.
Seriously, there is no reason why the HTML rendering has to be full-featured perfect for EWriter. It is required only to provide 100% rendering for the sub-set of HTML that can be produced by the RVF to HTML converter. Since you know what that is, you could develop the EWriter renderer accordingly.
Martin.
Seriously, there is no reason why the HTML rendering has to be full-featured perfect for EWriter. It is required only to provide 100% rendering for the sub-set of HTML that can be produced by the RVF to HTML converter. Since you know what that is, you could develop the EWriter renderer accordingly.
Martin.
- Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: H&M 7.1, PP 3.15, eWriter
Hi Tim,Tim Green wrote:It is effectively an HTML virtual machine in a sandbox.
This is not strictly true. For example if javascript is turned off in IE, it stops working in EWriter too (with no explanation to the user of what's happening). One of my users has already remarked about this (he allows scripts to run only in Firefox, not in IE). No doubt there are other settings in IE which affect EWriter in the same way.
I have added a <noscript> warning on my page template about this.
regards,
Martin.