From: W. Eliot Kimber (eliot@isogen.com)
Date: Sat Nov 09 2002 - 19:51:59 PST
Gustaf Liljegren wrote:
> Eliot wrote:
>
>
>>I am trying to configure XEP under Windows to render Asian languages
>>(Japanes and Simplified Chinese to start with) and I'm not having much
>>luck, but largely because I have no idea what I should be doing.
>
>
> What you should be doing is to copy your CIDFont directory to /afm. You
> normally find it in your Acrobat directory (also Acrobat Reader, if you
> choosed to install CJK fonts). Then just call the fonts in 'font-family'
> using the names or aliases specified in fonts.xml.
I was able to make this work for Simplified Chinese (haven't tried for
Japanese yet, but I'm sure it will work). Using the fonts with the
latest Adobe CJK font packs for Windows, I had to make some small
modifications to the stock 3.03 fonts.xml file:
<font name="STSongStd-Light-Acro"
ttf="CIDFont/STSongStd-Light-Acro.otf"
adobe-encoding="UniGB-UCS2-H"
adobe-ordering="GB1"
adobe-supplement="2"
embed="false">
<alias name="STSong"/>
</font>
The original fonts.xml didn't have the "Std" after "STSong" and didn't
include the ".otf" extension (maybe the Unix versions don't have the
extension?).
One problem I'm now having is that my bullets are not rendering. That
is, I have set the font globally to STSongStd-Light-Acro (specified on
fo:root and not overridden anywhere). Blocks that contain •
(bullet) don't render a bullet. I assume that this is because the
Acrobat fonts don't have a glyphs for that character, yes?
I don't have this problem with XSL Formatter's rendering, presumably
because it is using a Unicode font? I appologize if I'm still being a
bit dim about fonts--I know that Nikolai has explained some of these
details in the past.
> I have only tried this with character entities, but I guess it should work
> in plain text too. Perhaps one good exercise is to try writing a little
> Chinese in a hexeditor to see how plain text Chinese works, unless you have
> a Chinese editor comfortable with UTF-16. I haven't done that myself.
To an XML processor there's no difference between a numeric character
reference (•) and the Unicode character with the same value.
All the documents I'm working with are native Unicode with no numeric
character references. For working with Unicode data generally I like
Unipad (www.unipad.org)--it can do all sorts of useful transformations,
including to and from XML numeric character references, all the
different Unicode and locale-specific encodings, to and from \u0000
notation (as used by Java), etc. It has a pretty complete set of glyphs
and very handy Unicode database browser.
For XML editing, I find that Excelon Style Studio does really well with
full Unicode.
Note also that the Unicode encoding used to store a file has nothing to
do with the national language it's written in (that is, what part of the
Unicode code page it uses)--there's no functional difference from an
editing standpoint between UTF-8 and UTF-16 except the amount of storage
required--UTF-8 is more efficient if most of your data is in the ASCII
range, UTF-16 is more efficient if most of your data in the two-byte
range. But neither will be usable by a non-unicode-enabled editor. Or
said another way, if your editor isn't Unicode aware, it will screw up
UTF-8 data just as badly as it does UTF-16 data if your document
contains characters above 255.
The bigger problem seems to be finding Chinese editors built to the
locale-specific code pages and encodings that can save to UTF-8 or
UTF-16 reliably.
But that's not an XEP (or even an FO) issue.
Cheers,
E.
-- W. Eliot Kimber, eliot@isogen.com Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 ------------------- By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST