Hello!
2005/11/8, KURASAWA Nozomu (nabetaro) <nabetaro@caldron.jp>:
> 1.
> Generated HTML Help (chm) for Japanese has broken index.
> Because HTML Help (chm) must be written by Shift_JIS encode.
You need to set htmlhelp.encoding parameter in HTML Help customization
layer to right encoding for correct national characters display in
index, e.g. <xsl:param
name="htmlhelp.encoding">windows-1251</xsl:param> for Russian, I guess
it's spell as shift-jis for Japanese ;-)
There is a distinct index page in Tortoise[SVN | Merge] docs, which
doesn't produced in HTML Help at all (with XSL stylesheets v1.65.1
from tools package).
Upgrading to current v.1.69.1 will solve this problem, but introduce new:
processing of XInclude put "xml:base" attribute in root element of
included parts and XSL stylesheets take it in account now, so external
files (images referenced in files located in /tsvn_dug and
/tsvn_repository folders in our case) get that folders in front of its
names (relative-uri). To cope with this, we may:
1) instruct xsl processor don't perform base URI fixup - or
2) create subfolders in image folder, distribute graphic files
accordingly references, update all links to them in docs and set
img.src.path parameter pointing to image folder (I don't test this, I
suppose it's should work) - or
3) add another bit in customization layer, which replace @fileref
template and which don't use relative uri's (it's workaround, but it
works for me :-)
There is one more trouble with Index page: default template can't deal
with national characters in index grouping, and all Russian entries (I
guess, Japanese too) come into one group, 'symbols'. The solution is
autoidx-ng.xml (xsl:include it in customization layer), but it don't
work with xsltproc (I use it with Saxon, Saxon setup deserve a
separate message).
> 2.
> In Docbook's xsl, default font cannot display Japanese charactors.
> So we use userconf.xml and font.xml files. The other languages have
> same problems.
>
I think it's not Docbook XSL, it's FOP. To display non-Latin
characters in PDF it needs to embed fonts with necessary glyphs, and
what these files (and valid font files) are needed for. FOP don't
support proper mapping of Unicode characters, so type1 fonts have no
use, and search in doc don't work, even in only-Latin-characters
words. FOP stalled at v.0.20.5, but it's developed under the hood, and
maybe new release will take it right somewhere in the future. I'm
using XEP personal edition, which is free, but place a little stamp at
the bottom of every page.
There is also a free academic desktop license, devoted to "qualified
educational and non-profit non-government institutions", so I don't
know does TortoiseSVN project fall under this category.
> I think that the all problems are solved by "Language Specific XSL Files".
> For examples (in Japanese),
> * htmlhelp_ja.xsl
> * pdfdoc_ja.xsl
> * html_ja.xsl
>
> Maybe, We need Language Directory?
I think only language-specific features will be in language-specific
files, defaults must be the same, they have so much in common :-). In
XSL stylesheets including file have priority over included, so every
language-specific file may use defaults file with no harm to
language-specific features.
I have a couple of questions: will we use ...
- new version of XSL stylesheets? (requires some changes in docs or
customized stylesheets)
- saxon instead of xsltproc? (Saxon is java-based and therefore
xsltproc faster)
- XEP instead of FOP? (with FOP we sucrifice search in docs in some languages)
Regards,
Stan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Nov 8 13:10:19 2005