Re: Slow TOC tree in webhelp when there are a largenumber of heading entries

When I ran a medium-size webhelp document on MSIE 8 and clicked a search 
result I also got slow performance. And this error, which even appears 
when I run the small webhelp demo.

================
Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 
3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.2; .NET CLR 
3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Timestamp: Fri, 25 Feb 2011 20:59:29 UTC

Message: Object doesn't support this property or method
Line: 65
Char: 13
Code: 0
URI: file:///C:/webhelp/demo/out/common/main.js
================

Here's the referenced line in main.js:
   if (style != null && !style.match(/background-color: Background;/)) {

The generated HTML has this line with the background-color style:
<div id="leftnavigation" style="padding-top:3px;
    background-color:white;">

Maybe this error explains why expanded TOC trees don't have shaded 
backgrounds in MSIE 8, as they do in other browsers.

Re: to get glossseealso to work for auto-glossary

Re: Slow TOC tree in webhelp when there are a largenumber of heading entries

Thanks for reporting the information Denis. I've opened a tracker item
for it:
https://sourceforge.net/tracker/?func=detail&aid=3266134&group_id=21935&atid=373747

David

On 03/31/2011 06:22 PM, Denis Bradford wrote:
> When I ran a medium-size webhelp document on MSIE 8 and clicked a
> search result I also got slow performance. And this error, which even
> appears when I run the small webhelp demo.
>
> ================
> Webpage error details
>
> User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
> Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR
> 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.2; .NET CLR
> 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
> Timestamp: Fri, 25 Feb 2011 20:59:29 UTC
>
>
> Message: Object doesn't support this property or method
> Line: 65
> Char: 13
> Code: 0
> URI: file:///C:/webhelp/demo/out/common/main.js
> ================
>
> Here's the referenced line in main.js:
>   if (style != null && !style.match(/background-color: Background;/)) {
>
> The generated HTML has this line with the background-color style:
> <div id="leftnavigation" style="padding-top:3px;
>    background-color:white;">
>
> Maybe this error explains why expanded TOC trees don't have shaded
> backgrounds in MSIE 8, as they do in other browsers.
>
> Googling on this connection, I read that MSIE 8 doesn't support the
> match function. I tried switching to the search function, with the
> same result.
>
> Too bad you can't just advise people not to use MSIE -- that might
> solve a whole bunch of other problems too 
>
> Cheers,
> Denis
>
> On 03/31/2011 06:41 PM, david <at> thingbag.net wrote:
>> Also see the Recommended Apache Configurations section to improve
>> performance. In fact, those settings are all things Kasun researched
>> last summer  The TDG example on thingbag.net that Kasun pointed to
>> benefits from those settings:
>>
>> http://docbook.sourceforge.net/release/xsl/current/webhelp/docs/content/ch02s02.html
>>
>>
>> The TDG example is a pretty large book and it works ok in webhelp. At
>> some point, however, you would indeed hit a limit since one of the side
>> effects of having no frameset is that the toc tree is on every page in a
>> div.
>>
>> A possible improvement would be to store the toc tree in a separate js
>> file, so it could be cached. It's on the list of things we'd like to
>> improve: http://docbook.xmlpress.net/tiki-index.php?page=WebHelp2011
>>
>> Thanks,
>> David
>>
>

Re: Unable to indent text in text output -- SOLVED

Hi Aankhen,
   Woohoo! I figured it out. solution below.

<snip>
>>
>> Here’s my xsl file:
>> ------
>> <?xml version='1.0' encoding="utf-8"?>
>> <xsl:stylesheet
>>          xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>>          xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
>>
>>          <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/>
>>
>> <xsl:template match="para[ <at> role = 'box']">
>> <xsl:text>
>> </xsl:text>
>> <xsl:apply-templates/>
>>
>> </xsl:template>
>> ------
>
> I don’t see any indentation here; there’s just a newline within the
> ‘xsl:text’ element.  BTW, you don’t need to declare the ‘fo’ namespace
> unless you’re using it.

Oops.  Copy and paste error.  Sorry about that.  Thanks on the 'fo'. 
I've removed it.

<snip>

>
> Are you sure that this is a DocBook thing that you’re talking about?
> It sounds to me like you’re referring to the way HTML collapses
> whitespace: outside of the ‘pre’ element, any sequence of whitespace
> characters is rendered as a single space, while any leading/trailing
> whitespace is trimmed.[1] You have a few options for preserving
> whitespace:
>
> 1. The ‘pre’ element, which will render all whitespace exactly as it
> appears in the source.  It will also use a monospaced font and only
> break lines where you break them in the source, so it’s not very
> well-suited for your needs.
> 2. Non-breaking spaces (&nbsp; in HTML,&#160; or&#xA0; in any
> SGML-derived language), which are never collapsed by the browser.
> Something like “&nbsp;&nbsp;&nbsp;” will be rendered as “      ”.
> You could make every space a non-breaking space when you’re trying to
> maintain a layout, but that would lead to unfortunate consequences
> since, as the name indicates, line breaks are not allowed there.
> 3. CSS: set the ‘para.propagates.style’ parameter to ‘1’ so that the
> resultant HTML paragraphs have ‘box’ for their class names, then add
> whatever indentation or other styling you’d like to your CSS, such as:
>
>      .box { margin-left: 0.5em; }

For html output I do #3 already. and yes, it works quite well. :)

Yes, the whitespace was being collapsed.  <xsl:text 
disable-output-escaping="yes">  was what I needed to do.

Here's my entire xls file:

------
<?xml version='1.0' encoding="utf-8"?>
<xsl:stylesheet
         xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:import 
href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/>

<xsl:template match="para[ <at> role = 'box']">
<xsl:text 
disable-output-escaping="yes">&#xA0;&#xA0;&#xA0;&#xA0;&#xA0;</xsl:text>
<xsl:apply-templates/>
<xsl:text disable-output-escaping="yes">&lt;br&gt;</xsl:text>
</xsl:template>
</xsl:stylesheet>
------

I've been trying to figure that out for, well, longer than I want to admit.

Thank you very much!!!!!!!!!
Matt

Re: Unable to indent text in text output -- SOLVED

Hi Matt,

On Fri, Apr 1, 2011 at 08:36, Matt Dew <marcoz <at> osource.org> wrote:
>  Woohoo! I figured it out. solution below.
>
> <snip>
>>>
>>> Here’s my xsl file:
>>> [snip]
>>
>> I don’t see any indentation here; there’s just a newline within the
>> ‘xsl:text’ element.  BTW, you don’t need to declare the ‘fo’ namespace
>> unless you’re using it.
>
> Oops.  Copy and paste error.  Sorry about that.  Thanks on the 'fo'. I've
> removed it.

Ah, okay.

> [snip]
>
>> 3. CSS: set the ‘para.propagates.style’ parameter to ‘1’ so that the
>> resultant HTML paragraphs have ‘box’ for their class names, then add
>> whatever indentation or other styling you’d like to your CSS, such as:
>>
>>     .box { margin-left: 0.5em; }
>
> For html output I do #3 already. and yes, it works quite well. :)
>
> Yes, the whitespace was being collapsed.  <xsl:text
> disable-output-escaping="yes">  was what I needed to do.
>
>
> Here's my entire xls file:
>
> ------
> <?xml version='1.0' encoding="utf-8"?>
> <xsl:stylesheet
>        xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
>
> <xsl:import
> href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"/>
>
> <xsl:template match="para[ <at> role = 'box']">
> <xsl:text
> disable-output-escaping="yes">&#xA0;&#xA0;&#xA0;&#xA0;&#xA0;</xsl:text>
> <xsl:apply-templates/>
> <xsl:text disable-output-escaping="yes">&lt;br&gt;</xsl:text>
> </xsl:template>
> </xsl:stylesheet>
> ------
>
>
> I've been trying to figure that out for, well, longer than I want to admit.

Happens to me practically every day.

> Thank you very much!!!!!!!!!

Glad I could help.  There’s something I don’t understand, though:
you say that you already do #3 for HTML output; why not do it for
XHTML as well? :-S Why do it this way? (Also, if you’re producing
XHTML, you probably want to close that ‘br’.)

BTW, as I said in the previous mail, you don’t need to make every
space a non-breaking space (and in fact, that can have unfortunate
consequences if you put too many of them on one line).  Just changing
every other space would do.

Aankhen

Webhelp and Modular Docs

Re: Webhelp and Modular Docs

Hi Gregorio,
Give the attached build.xml a try. It includes support for resolving
xinclude. This version also supports profiling via 2-pass profiling (the
xinclude step also does the profiling).

Note that if you're doing complicated stuff like pulling in sections
from sibling directories and those sections contain images, there will
be problems. I'll need to do some fancy stuff to collect images in cases
like that, make sure there are no naming collisions, and put them all in
the output dir.

David

On 04/01/2011 11:27 AM, gpevaco <at> aol.com wrote:
> Hello everyone: 
>
>
>
> While attempting to use Webhelp to generate some HTML from Docbook files, I came upon a modular document,
that contains XInclude references to other documents. Webhelp failed there. 
> Which leads me to ask, Is there any way that the Webhelp can process modular documents that use the
xi:include? 
>
> If I actually combine the documents into a single XML file, then it works just fine. 
> However this defeats the purpose of having modular documents. 
> So the question is can Webhelp be used for modular documents?
>
>  
> Thank you in advance. 
>  
> /Gregorio 
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe <at> lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help <at> lists.oasis-open.org

Writing mode, xsl-fo output

How might I change writing mode for pdf output please?

To include some rl-tb text in a docbook output?

-- 

regards 

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Re: Writing mode, xsl-fo output

Hi Dave,
This section has some basic information:

http://www.sagehill.net/docbookxsl/Localizations.html#WritingMode

But when you say "some rl-tb" text, do you mean a mixed language document?   In that 
case, the writing mode value should be for the dominant language, since the document's 
writing mode determines the page layout.. Any inline translated text should get the 
correct text direction based on its Unicode character range.

Can you describe in more detail what your needs are?

Bob Stayton
Sagehill Enterprises
bobs <at> sagehill.net

----- Original Message ----- 
From: "Dave Pawson" <davep <at> dpawson.co.uk>
To: <docbook-apps <at> lists.oasis-open.org>
Sent: Friday, April 01, 2011 10:28 AM
Subject: [docbook-apps] Writing mode, xsl-fo output

> How might I change writing mode for pdf output please?
>
> To include some rl-tb text in a docbook output?
>
>
>
> -- 
>
> regards
>
> -- 
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe <at> lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help <at> lists.oasis-open.org
>
>
> 

Re: Qanda: HTML: Not renumber on qandadiv