headers
David Cramer | 1 Dec 2007 01:16

RE: Weird characters in generated HTML

<a id="foo"/> shouldn't be a problem (my docs are full of them...I do
generate xhtml and stay out of quirks mode, but I don't think that
matters here) unless you do something like a{ color: blue;
text-decoration: underline;} in your css. Then everything after a <a
id="foo"/> until the next time a closing </a> tag is reached will be
blue. Do a[href]{ color: red; text-decoration: underline;} instead.

David 

> -----Original Message-----
> From: Johnson, Eric [mailto:Eric.Johnson <at> iona.com] 
> Sent: Friday, November 30, 2007 5:18 PM
> To: Barton Wright; David Cramer
> Cc: docbook-apps
> Subject: RE: [docbook-apps] Weird characters in generated HTML
> 
> As far as I can tell it is all of the anchors. Not just the 
> olink ones.
> I'm calling Saxon, with Xerces, from ant using the java task:
> 
>         <java classname="com.icl.saxon.StyleSheet"
> classpathref="xslt-classpath" fork="true">
>             <sysproperty 
> key="javax.xml.parsers.DocumentBuilderFactory"
> value="org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"/>
>             <sysproperty key="javax.xml.parsers.SAXParserFactory"
> value="org.apache.xerces.jaxp.SAXParserFactoryImpl"/>
>             <sysproperty
> key="org.apache.xerces.xni.parser.XMLParserConfiguration"
> value="org.apache.xerces.parsers.XIncludeParserConfiguration"/>
(Continue reading)

Permalink | Reply | 15 comments |
headers
Dave Pawson | 1 Dec 2007 09:19
Picon

Re: Weird characters in generated HTML

Johnson, Eric wrote:
> As far as I can tell it is all of the anchors. Not just the olink ones.
> I'm calling Saxon, with Xerces, from ant using the java task:
> 

Since your questions focus on ant, java and xslt, why are you asking
them on the docbook mailing lists?

Try the ant list, the xslt list etc.

regards

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Permalink | Reply | 1 comment |
headers
David Cramer | 1 Dec 2007 22:39

RE: Weird characters in generated HTML

I think it's a fair question for the docbook-apps list. He's getting
different behavior from the docbook xslts using different processors and
using the xslt processor he was told is the preferred one (saxon), he's
getting obiviously bad output (everything's a hyperlink). Other lists
wouldn't know enough about how we put all the tools together. The xslt
list would probably tell him there's no difference between <a id="foo"/>
and <a id="foo"></a>. I think he's actually got a poorly written css
rule. 

David 

> -----Original Message-----
> From: Dave Pawson [mailto:davep <at> dpawson.co.uk] 
> Sent: Saturday, December 01, 2007 2:19 AM
> To: Johnson, Eric
> Cc: docbook-apps
> Subject: Re: [docbook-apps] Weird characters in generated HTML
> 
> Johnson, Eric wrote:
> > As far as I can tell it is all of the anchors. Not just the 
> olink ones.
> > I'm calling Saxon, with Xerces, from ant using the java task:
> > 
> 
> Since your questions focus on ant, java and xslt, why are you 
> asking them on the docbook mailing lists?
> 
> Try the ant list, the xslt list etc.
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacques Foucry | 3 Dec 2007 11:32

About figure references

Hello,

I try to customize my figures legend.

In french Figure x.yy should be on small caps and the legend it self  
should be in italic.

So I took form Bob's book a customization code and I customize it again:

	<xsl:template name="formal.object.heading">
		<xsl:param name="object" select="."/>
		<xsl:param name="placement" select="'before'"/>
		
		<fo:block>
			<xsl:choose>
				<xsl:when test="$placement = 'before'">
					<xsl:attribute
						name="keep-with-next.within-column">always</xsl:attribute>
				</xsl:when>
				<xsl:otherwise>
					<xsl:attribute
						name="keep-with-previous.within-column">always</xsl:attribute>
				</xsl:otherwise>
			</xsl:choose>
			<fo:inline xsl:use-attribute-sets="formal.label.properties" font- 
variant="small-caps">
				<xsl:call-template name="gentext">
					<xsl:with-param name="key" select="local-name($object)"/>
				</xsl:call-template>
				<xsl:text> </xsl:text>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olivier Ishacian | 3 Dec 2007 13:55
Favicon

[ANN] XMLmind XML Editor 3.7.0

XMLmind XMLmind is pleased to announce a new version of XMLmind XML Editor.
   _____________________________________________

XMLmind XML Editor Personal Edition 3.7.0 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.)
   _____________________________________________

v3.7.0 (November 15, 2007):

   * The DITA add-on for XMLmind XML Editor now
     fully supports the DITA DTD 1.1. It includes
     its own minimal copy of DITA Open Toolkit
     version 1.4. If you need this add-on, please
     install it using Options|Install Add-ons.

   * New Tools|Helper Application sub-menu. This
     menu contains entries allowing to use
     third-party applications to view or edit part
     or all of the document being edited.

   * New date/time picker dialog box. This dialog
     box is used by the Attribute Tool, the
     putAttribute and addAttribute commands, new
     form controls called date-time-picker,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johnson, Eric | 3 Dec 2007 16:50
Favicon

Weird olink database error

In my travails to move a build system from xsltproc based to Saxon
based, I've hit several snags where the output from xsltproc and Saxon
are different using the exact same style sheets. I've been asking
questions here, because I suspect the users here would have more
familiarity with the complete toolset that users on other lists. If that
is incorrect, I will redirect my questions to the more appropriate list.

The latest snag I've hit is that when building the olink target data
base using the xhtml chunking sheet set to only build the target
database, Saxon adds a blank line followed by the XHTML DOCTYPE to the
top of the file. I worked around this by switching to the html version
of the style sheet, but since we generate the docs in xhtml, it would be
better if I could use the xhtml version. Again, I'm using the same
customization layer, just different XSLT processors. Style sheet version
1.73.1 with xsltproc is fine. Style sheet version 1.73.1 with Saxon
creates extra stuff.

Do I need to use the Saxon extensions to clear this up? 

Many Thanks for the help,
Eric
Permalink | Reply | 7 comments |
headers
Johnson, Eric | 3 Dec 2007 16:38
Favicon

RE: Weird characters in generated HTML

 David,
The change to the CSS did the trick!! Thanks.
Cheers,
Eric

-----Original Message-----
From: David Cramer [mailto:dcramer <at> motive.com] 
Sent: Friday, November 30, 2007 7:16 PM
To: Johnson, Eric; Barton Wright
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML

<a id="foo"/> shouldn't be a problem (my docs are full of them...I do
generate xhtml and stay out of quirks mode, but I don't think that
matters here) unless you do something like a{ color: blue;
text-decoration: underline;} in your css. Then everything after a <a
id="foo"/> until the next time a closing </a> tag is reached will be
blue. Do a[href]{ color: red; text-decoration: underline;} instead.

David 

> -----Original Message-----
> From: Johnson, Eric [mailto:Eric.Johnson <at> iona.com]
> Sent: Friday, November 30, 2007 5:18 PM
> To: Barton Wright; David Cramer
> Cc: docbook-apps
> Subject: RE: [docbook-apps] Weird characters in generated HTML
> 
> As far as I can tell it is all of the anchors. Not just the olink 
> ones.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Johnson, Eric | 3 Dec 2007 16:08
Favicon

RE: Weird characters in generated HTML

David,
Thanks for the tip. I'll check the CSS for a bum style in the style
sheet. It is odd that simply swapping the XSLT processor generated such
different results.
Cheers,
Eric 

-----Original Message-----
From: David Cramer [mailto:dcramer <at> motive.com] 
Sent: Friday, November 30, 2007 7:16 PM
To: Johnson, Eric; Barton Wright
Cc: docbook-apps
Subject: RE: [docbook-apps] Weird characters in generated HTML

<a id="foo"/> shouldn't be a problem (my docs are full of them...I do
generate xhtml and stay out of quirks mode, but I don't think that
matters here) unless you do something like a{ color: blue;
text-decoration: underline;} in your css. Then everything after a <a
id="foo"/> until the next time a closing </a> tag is reached will be
blue. Do a[href]{ color: red; text-decoration: underline;} instead.

David 

> -----Original Message-----
> From: Johnson, Eric [mailto:Eric.Johnson <at> iona.com]
> Sent: Friday, November 30, 2007 5:18 PM
> To: Barton Wright; David Cramer
> Cc: docbook-apps
> Subject: RE: [docbook-apps] Weird characters in generated HTML
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pedro Pastor | 3 Dec 2007 19:04
Picon
Favicon

RE: Weird olink database error

Hi Eric,

I suffer from the same problem but using the "website" XSL application. In
this case Saxon issues a HTML DOCTYPE on the top of the file.

I've posted the same question in this forum some weeks ago but I get no
response at all. I hope you were more fortunate than me.

Regards,

Pedro 

-----Mensaje original-----
De: Johnson, Eric [mailto:Eric.Johnson <at> iona.com] 
Enviado el: lunes, 03 de diciembre de 2007 16:51
Para: docbook-apps
Asunto: [docbook-apps] Weird olink database error

In my travails to move a build system from xsltproc based to Saxon based,
I've hit several snags where the output from xsltproc and Saxon are
different using the exact same style sheets. I've been asking questions
here, because I suspect the users here would have more familiarity with the
complete toolset that users on other lists. If that is incorrect, I will
redirect my questions to the more appropriate list.

The latest snag I've hit is that when building the olink target data base
using the xhtml chunking sheet set to only build the target database, Saxon
adds a blank line followed by the XHTML DOCTYPE to the top of the file. I
worked around this by switching to the html version of the style sheet, but
since we generate the docs in xhtml, it would be better if I could use the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Pawson | 3 Dec 2007 20:24
Picon

Re: Weird olink database error

Pedro Pastor wrote:
> Hi Eric,
> 
> I suffer from the same problem but using the "website" XSL application. In
> this case Saxon issues a HTML DOCTYPE on the top of the file.

> The latest snag I've hit is that when building the olink target data base
> using the xhtml chunking sheet set to only build the target database, Saxon
> adds a blank line followed by the XHTML DOCTYPE to the top of the file. 

Why is this an issue for xml processing? Is it wrong?

http://saxon.sourceforge.net/saxon6.5.5/xsl-elements.html#xsl:output
specifies the xslt output options.

If you ask for xhtml output then Saxon gives it.
If you ask for xml output then no doctype should be output.

http://docbook.sourceforge.net/release/xsl/current/doc/html/chunking.html
provides the docbook customization.

regards

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Permalink | Reply | 1 comment |

Gmane