Jirka Kosek | 29 Oct 18:11 2014
Picon

Re: [WebHelp] Incorrect initial scroll to anchor in Chrome

On 27.10.2014 19:04, Jan Tosovsky wrote:
> This seems to be caused by the following script located in the main.js file:
> 
> var hash = window.location.hash;
> if (hash) { 
>    var targetOffset = $(hash).offset().top - 120;
>    $('html,body').animate({scrollTop: targetOffset}, 200);
>    return false;
> }

Could you try replacing $('html,body') with $('#content'). I recall that
there were some problems related to former selector, but I'm not sure
whether this will help here.

					Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek     e-mail: jirka <at> kosek.cz     http://www.kosek.cz
------------------------------------------------------------------
  Profesionální školení a poradenství v oblasti technologií XML.
       Podrobný přehled školení http://xmlguru.cz/skoleni/
------------------------------------------------------------------
  http://docbook.cz    Stránky o dokumentačním formátu DocBook
  http://xmlguru.cz    Blog mostly about XML for English readers
------------------------------------------------------------------

Janice Manwiller | 28 Oct 13:02 2014

Checking for different types of links (xref vs link/linkend vs link/href)

Is there a way in the customization layer to check for different types of links?

What I want to do is in PDFs, do the following:

- For xref links (links within a guide) and link/href links (links to websites), do the standard blue link text

- For link/linkend links (links to other guides), do not have any formatting.

The reason for this is that for our PDF output, where each guide is a separate file, the links between guides do not work. They're currently formatted as links, but aren't clickable.

In the WebHelp output, which is generated as a single collection, the links do work, so I want to leave them as links in the source file.

I know that olinks are designed to be used for links between documents, but my understanding is that olinks do not work in WebHelp output.

I tried a workaround in the FO XSL file where only xref links were blue:

  <xsl:attribute-set name="xref.properties">
   
<xsl:attribute name="color">
       
<xsl:choose>
               <xsl:when test="self::xref">blue</xsl:when>
                <xsl:otherwise>inherit</xsl:otherwise>
         </xsl:choose>
      
</xsl:attribute>
  </xsl:attribute-set>

But ended up with no formatting on any links.

Thanks,

Janice
David Cramer | 28 Oct 07:29 2014
Picon

Re: [WebHelp] Incorrect initial scroll to anchor in Chrome

On 10/27/14, 1:04 PM, Jan Tosovsky wrote:
...
> While target offset is -195 in FF, it is 2200 in Chrome. The required anchor
> is not scrolled precisely to its location, but ca 300 px towards the bottom.
> However, on page reload it is sometimes correct, sometimes more or less than
> the initial value. This inconsistency is really weird.
> 
> I've found several threads mentioning incorrect Chrome behaviour when
> determining offset top value on StackOverflow, but it is not very clear to
> me if this is our case.
> 
> Has anybody any experience with this or fix?

As you've noticed, that code is trying to compensate for the fact that
there's a fixed header and links to anchors in a page would otherwise
appear under the fixed header (i.e. at the top of the window). I've
recently come across a better solution to that problem that uses only
css. It goes something like this (assuming you're linking to <a/> tags
and assuming a header-height of 195px):

  a:before {
      display: block;
      content: " ";
      margin-top: -195px;
      height: 195px;
      visibility: hidden;
      z-index: -1;
    }

Adjust the selector as needed if the links are to div tags or whatever.
In the case of the DocBook xslts, I think a and div tags that have id
attributes would be the right things to add this rule to.

This strategy is much easier to maintain if you're using sass/scss
because you can use variables, defining $header-height in one place and
then reusing it to define the height of the header and the offests in
rules like this.

My suggestion would be to rip out the javascript and move to a solution
like this.

Regards,
David
Jan Tosovsky | 27 Oct 19:04 2014
Picon

[WebHelp] Incorrect initial scroll to anchor in Chrome

Dear All,

I've noticed incorrect scrolling the page in Chrome when the URL contains a
hash character.

This seems to be caused by the following script located in the main.js file:

var hash = window.location.hash;
if (hash) { 
   var targetOffset = $(hash).offset().top - 120;
   $('html,body').animate({scrollTop: targetOffset}, 200);
   return false;
}

While target offset is -195 in FF, it is 2200 in Chrome. The required anchor
is not scrolled precisely to its location, but ca 300 px towards the bottom.
However, on page reload it is sometimes correct, sometimes more or less than
the initial value. This inconsistency is really weird.

I've found several threads mentioning incorrect Chrome behaviour when
determining offset top value on StackOverflow, but it is not very clear to
me if this is our case.

Has anybody any experience with this or fix?

Thanks, Jan
jmt | 23 Oct 12:08 2014
Picon

footnotes author

Hello list,

I have a document with notes from different authors, e.g.

<para>
    some text
    <footnote role='author'>bla bla</footnote>
    another sentence
    <footnote role='translator'>glop glop</footnote>
</para>

The document is to be rendered in html, epub and pdf. How do I attribute the 
notes according to the role, e.g.

[1] [author] bla la
[2] [translator] glop glop

Thanks in advance !

jmt

--

-- 

          http://www.dxdydz.net

            Jean-Marie Thomas

Informatique scientifique et technique
Richard Hamilton | 22 Oct 18:48 2014
Picon

epub3 and named entities

It looks as though the next version of epubcheck may reject epub3 files that use named character entities
(&amp;, etc.).

Right now, the stylesheets will generate at least some of these, even if you use the numeric equivalent
(e.g., if you use &#38; for ampersand in your source, the output will be &amp;).

Is there an option that will keep Saxon (which is what we currently use) from making this change? Or are there
options with other processors that might be a better choice?

Thanks,
Dick Hamilton
-------
XML Press
XML for Technical Communicators
http://xmlpress.net
hamilton <at> xmlpress.net
Olivier Ishacian | 21 Oct 19:41 2014

[ANN] Release of XMLmind XML Editor v6.1

XMLmind is happy to announce the version 6.1 of XMLmind XML Editor.
    _____________________________________________

XMLmind XML Editor Evaluation Edition v6.1 can be downloaded from
http://www.xmlmind.com/xmleditor/download.shtml

Professional Edition users, please upgrade using this form:
http://www.xmlmind.com/store/download.php

(The above form is usually accessed through
http://www.xmlmind.com/xmleditor/upgrade.html.)
    _____________________________________________

XMLmind XML Editor v6.1 (October 20, 2014)
------------------------------------------

* Many enhancements making XMLmind XML Editor more powerful
   and more comfortable to use.

* Some important bug fixes.

* New documentation. See below.
    _____________________________________________

More information:
http://www.xmlmind.com/xmleditor/changes.html

XMLmind XML Editor - Support of XPath 1.0
http://www.xmlmind.com/xmleditor/_distrib/doc/xpathsupport/index.html

XMLmind XML Editor - How to adapt "Paste from Word" to your needs
http://www.xmlmind.com/xmleditor/_distrib/doc/pastefromword/index.html
Janice Manwiller | 16 Oct 13:44 2014

Trouble formatting PDF TOC entries

I'm trying to update the formatting of a PDF TOC. I mostly want to add additional space above and bold the chapter entries.

I found the following sample for toc.line.properties in the DocBook XSL reference, and as a test added it to my FO stylesheet.

<xsl:attribute-set name="toc.line.properties"> <xsl:attribute name="font-size">10pt</xsl:attribute> <xsl:attribute name="font-weight"> <xsl:when test="self::chapter | self::preface | self::appendix">bold</xsl:when> <xsl:otherwise>normal</xsl:otherwise> </xsl:attribute> </xsl:attribute-set>
According to the guide, this should make all entries 10pt and chapter entries bold.

However, when I try to generate the DocBook output using our maven docbkx tool, it doesn't generate at all, and I get an error indicating that a "when" element must always be enclosed by a "choose" element.

If I add the choose element, like:
<xsl:attribute-set name="toc.line.properties"> <xsl:attribute name="font-size">10pt</xsl:attribute> <xsl:attribute name="font-weight"> <choose> <xsl:when test="self::chapter | self::preface | self::appendix">bold</xsl:when> <xsl:otherwise>normal</xsl:otherwise> </choose> </xsl:attribute> </xsl:attribute-set>
then the output generates, but there is no effect on the TOC formatting. The chapter entries aren't bold.

Any ideas on how to get this to work?

Thanks,

Janice
Thomas Schraitle | 16 Oct 10:56 2014
Picon

Tests Framework for DocBook Stylesheets & Customizations?

Hi,

when developing customizations for the DocBook stylesheets I have
always the feeling I forget something important and work without any
"safey net". ;)
As such, it would be great to have a "test framework" which could
automatically check the transformation results with the expected
behaviour. 

I know of XSpec from Jeni Tennison which goes in this direction.
However, as far as I know, this is for XSLT 2, not XSLT 1. It's used
for developing and testing the upcoming XSLT 2 DocBook stylesheets.

I'm not sure how easily could this be adapted to our current XSLT 1
base. Are there other (better?) solutions?

How do *you* develop and test your stylesheets? Has anybody used such
frameworks? Any help is greatly appreciated. :)

--

-- 
Gruß/Regards,
    Thomas Schraitle
Thomas Schraitle | 14 Oct 14:11 2014
Picon

Multiple Languages in one DocBook Document

Hi,

ok, lets assume, we have an article. Its main language is in English.
Furthermore, our document needs some paragraphs in a different language.
The natural way would be to use the lang attribute like in the
following excerpt (DocBook 4.5):

---------
 <article lang="en">
    <title>Language Test</title>
    <para lang="de">Dies ist ein deutscher Absatz.</para>
    <para lang="ar">هذه هي الفقرة العربية.</para>
 </article>
---------

Transforming* the above document into XSL-FO leads to the following
fo:block structures:

  <fo:block space-before.optimum="1em" space-before.minimum="0.8em"
        space-before.maximum="1.2em">Dies ist ein deutsches
  Zitat</fo:block>

  <fo:block space-before.optimum="1em" space-before.minimum="0.8em"
        space-before.maximum="1.2em"> هذه هي الفقرة العربية.</fo:block>

I would have expected to see a language attribute (and perhaps a
writing-mode as well). Unfortunately, it's not there. As such, in the
German and Arabic paragraph English hyphenation rules are applied. This
is obviously not correct. :)

I tried a sect1 element with a lang attribute with the same result.

Looking into the FO stylesheets, I identified some spots which I would
consider it as "fishy":

1. fo/param.xsl, parameter writing.mode
   Its default value is taken from the language file by using the
   gentext template. 
   However, the lang argument is set to "/*[1]" which is valid for a
   document with one main language. Unfortunately, this value does not
   help when using multiple languages.

2. fo/block.xsl, template match="para"
   The para template does not contain any code which would add the
   missing language or writing-mode attributes.

I tried it also with the latest snapshot release (28-Sep-2014 17:02,
r9945) but the results are the same.

Could someone confirm or extend my analysis? Does someone know what goes
wrong here? :)

* Used 1.78.1 of the DocBook XSL stylesheets
  libxml2: 2.9.1
  libxslt: 1.1.28

--

-- 
Gruß/Regards,
    Thomas Schraitle
Richard Hamilton | 2 Oct 02:22 2014
Picon

Bad DOCTYPE on toc.ncx in epub2 stylesheets snapshot

The subject line says nearly everything.

If I try to create an epub2 file using a recent snapshot (Sept. 28), toc.ncx gets written correctly, except
it has a DOCTYPE for an xhtml file:

<!DOCTYPE ncx
  PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

There is a valid xmlns attribute on the root element, and if you remove the DOCTYPE lines completely, the
file is fine. In 1.78.1 this does not happen.

I poked around the stylesheets, but couldn't figure out what's going on, and I didn't see anything in the
revision history that seemed pertinent.

Has anyone run into the same thing?

Best regards,
Dick Hamilton
-------
XML Press
XML for Technical Communicators
http://xmlpress.net
hamilton <at> xmlpress.net

Gmane