docbook-apps

My book provides a workaround for this problem of FOP not supporting the
font-selection-strategy property. See:

http://www.sagehill.net/docbookxsl/SpecialChars.html#SwitchSymbol

It requires a stylesheet customization, as well as changing the XML source files for
any missing characters. Hopefully the FOP developers will fix this limitation soon.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net

Hi Bob.
Yes, I have already been told about this.
The problem is that my symbols are inside text, and If I was to replace them with some tags, I will get back to my problem of storing HTML style data in XML, thus using CDATA, and so on...
Do you think it is possible to do the customization on the stylesheet, so that it will detect special characters and replace, say α-bungarotoxin by the <symbol role="symbolfont">α</symbol>-bungarotoxin ?
I read somewhere that the TRUNK version of FOP has some changes in that matter, I may give it a try...

Thanks for everything
Regards,
Fabien



-----Message d'origine-----
De : Bob Stayton [mailto:bobs@sagehill.net]
Envoyé : jeudi 8 juillet 2010 19:44
À : Fabien Tillier; rob.cavicchio@emc.com; docbook-apps@lists.oasis-open.org
Objet : Re: [docbook-apps] RE: XSL-FO and unicode

My book provides a workaround for this problem of FOP not supporting the
font-selection-strategy property. See:

http://www.sagehill.net/docbookxsl/SpecialChars.html#SwitchSymbol

It requires a stylesheet customization, as well as changing the XML source files for
any missing characters. Hopefully the FOP developers will fix this limitation soon.

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net



Original Message -----
From: "Fabien Tillier" <f.tillier@cerep.fr>
To: <rob.cavicchio@emc.com>; <docbook-apps@lists.oasis-open.org>
Sent: Thursday, July 08, 2010 8:41 AM
Subject: RE: [docbook-apps] RE: XSL-FO and unicode


If I only set Arial Unicode MS <xsl:param name="body.font.family" select="'Arial
Unicode MS'"/>, I get the symbols, but only those :( (and numbers...)
And Acrobat tells me the used fonts are Helvetica and Symbol...
As I like to try things, I set the fonts to
<xsl:param name="symbol.font.family" select="'Arial Unicode MS'"/>
<xsl:param name="body.font.family" select="'Helvetica,Arial,Serif'"/>
Thus, trying to use Arial Unicode MS for symbole (though I am completely sure it won't
work)
And I was right. So, I am afraid I am in a dead-end...

-----Message d'origine-----
De : rob.cavicchio@emc.com [mailto:rob.cavicchio@emc.com]
Envoyé : jeudi 8 juillet 2010 16:57
À : Fabien Tillier; docbook-apps@lists.oasis-open.org
Objet : RE: [docbook-apps] RE: XSL-FO and unicode

I understand your frustration. I happen to be dealing with a lot of these
font/character issues myself right now, so my head's in it. Hopefully I can help
further. The situation is very different for HTML vs. PDF.

As far as HTML goes, unless you are publishing HTML Help (CHM), I recommend sticking
with UTF-8 for HTML output, and if possible make sure all your font style declarations
end with one of the standard font keywords ("monospace", "sans-serif", or "serif").
When the HTML output is displayed, for each character the browser should automatically
select an available font if the font you explicitly specified doesn't contain that
character.


PDF has a much more limited fallback mechanism, and furthermore FOP itself does not
even fully implement the XSL-FO 1.1 specification. As a result you have to jump
through a lot more hoops to guarantee the correct display of all Unicode characters.


> When I look in the properties, only
> Helvetica font is used, not Symbol, which I indicate in the XSL-FO
> stylesheet with
> <xsl:param name="symbol.font.family" select="'Symbol'"/>
> <xsl:param name="body.font.family" select="'Helvetica,Arial,Serif'"/>

Unfortunately I think you are running into a limitation of FOP that the DocBook
stylesheets don't seem set up to let you circumvent. I went and looked at the DocBook
stylesheet reference at
http://docbook.sourceforge.net/release/xsl/current/doc/index.html (sorry I didn't do
this before), and according to the documentation, the symbol font names "are
automatically appended to the body or title font family name when fonts are specified
in a font-family property in the FO output". But as we've said, FOP disregards all but
the first font name, so appending more font names to the end of the list is not going
to have any effect.


> As of inserting Arial Unicode in FOP, I hesitate, as the ttf file is 22Mb
> in size...

I believe that FOP subsets all fonts, so you probably don't have to worry about the
size. The font does only come with MS Office, but if you know that all systems you
publish on will have MS Office installed, then the simplest solution is probably this:

<xsl:param name="body.font.family" select="'Arial Unicode MS,Helvetica,Arial,Serif'"/>


You might then run into a further limitation, however. My understanding is that "Arial
Unicode MS" does not have bold and italic variations, so if you do this you might find
that bold and italics do not show up in the PDF. I have not yet experimented to see
what really happens here.



>

Fabien Tillier [mailto:f.tillier@cerep.fr] wrote:


> Do you think it is possible to do the customization on the stylesheet, so
> that it will detect special characters and replace, say α-
> bungarotoxin by the <symbol role="symbolfont">α</symbol>-bungarotoxin
> ?

This is certainly possible to do in XSLT. I have done something similar to create HTML entities for special characters. You need to customize the template that matches your text node, cycle through each character using text functions such as "substring", and then just compare the character to the numerical entity; something like this:

<xsl:when test="$character = 'α'">
<fo:inline font-family="'Symbol'"><xsl:value-of=select="$character" /></fo:inline>
</xsl:when>


> I read somewhere that the TRUNK version of FOP has some changes in that
> matter, I may give it a try...

Ooh, that would be good to know. Please let us know what you find.


*************************
Rob Cavicchio
Principal Technical Writer & Information Architect
EMC Captiva
Information Intelligence Group
EMC Corporation
3721 Valley Centre Drive, Ste 200
San Diego, CA 92130

P: (858) 320-1208
F: (858) 320-1010
E: rob.cavicchio@emc.com

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.