[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#80458: Add fonts.dir for Chinese fonts (abiword 0.7.12)



Hello CJK guys,

At Mon, 26 Feb 2001 12:34:59 +0800,
ha shao wrote:
> 
> Hmm... Some how I  missed the original mail.
> 
> On Sun, Feb 25, 2001 at 05:12:44PM -0700, foka@debian.org wrote:
> > I was digging through the fonts.dir that the CLE (Chinese GNU/Linux
> > Extension Project) use, and found a slightly different version.
> > I have made some slight modification (to capitalize the font names so they
> > look better.  :-)  I have attached it here as an .tar.bz2 archive.
> > I prefer CLE's fonts.dir over the ones that ha shao suggested, although I am
> > pretty sure that we may need to tweak those CLE fonts.dir even further, when
> > the details of Ghostscript-CJK and fonts are finalized.
> > 
> 
> Yes, the changes are better. But only the normal font has the correct
> font encoding (GB-EUC). Others are still in GB as the same as the wrong
> encoding in my original fonts.dir. I did not test the abiword printing
> at the time cause GS-CJK was not announce yet then. Now we can test
> CJK printing too.

I took a look at ha shao's fonts.dir and Anthony's, and got some
weird impressions. Maybe it is due to my less knowledge about
Chinese, so please point out what i'm misunderstanding.

First about Anthony's. CJK PostScript font names generally consist of
fontname and CMap name. CMap name represents charset, encoding and
direction of font. Usually only one CMap name is supported for each
language by each application. But Anthony's fonts.dir for zh-CN have
two sorts of CMaps in PostScript font names: GB-EUC-H and GB-H.
The former stands for GB2312 charset in EUC encoding, while the latter
stands for GB2312 charset in ISO2022 encoding. I cannot think abiword
supports PostScript output in different encodings for a single charset
because there's no clue for abiword to detect which encoding should be
used for the output.

ha shao seems to adopt GBK-H as CMap name for both GB2312 and Big5. GBK-H
is not defined by Adobe as CMap name in Adobe-GB1 or Adobe-CNS1 character
collections, so GS-CJK i'm preparing cannot handle it. If GBK-H is a sort
of mistyping of GBK-EUC-H, which defined by Adobe as CMap name in
Adobe-GB1 character collection, it is not suited for Big5 PostScript
printing. I understand GBK charset includes only Simplified Chinese characters.

In addition, ZenKai-Medium lacks CMap name, so GS-CJK would never handle
it either.

BTW, all these worries would be gone away if defoma was accepted. It can
automatically set available CJK PostScript fonts and correspondent XLFDs
appropriately. (I've already realized something like that in tgif.
Tgif in my computer has all the available PostScript fonts including CJK
ones in a font-selection menu without no manual editting of Resource file.
Correspondent XLFDs are automatically set for each of the fonts. I announced
that at debian-devel with test packages, but haven't got any responce
about that :/)

> GS-CJK.  He told me that the PS fontname fetched from Arphic's TTF is
> 'GBZenKai' for typeface kai. So maybe we will use the GBZenKai for
> Kai font or add aliases in GS-CJK to link Arphic-KaiGB-GB-EUC-H with
> /GBZenKai-Medium-GBK-EUC-H.

Yes, GBZenKai-Medium is the PostScript font name of one of the Arphic TTFs.
I doubt GB-EUC-H can substitute for GBK-EUC-H.

Regards,

--
Yasuhiro Take aka hirot / <take@debian.org>

Attachment: pgpf_m7NVrYri.pgp
Description: PGP signature


Reply to: