Oops, I ought to have asked this question when the patch
was applied on 2007; I was impressed as something strange.
Anyway, I was reassured that I could find it before some
complaints from Chinese or Korean users.
Here is a small patch to fix it. At least, changing from
"kana" to "hani" is very useful for SimSun and MingLiU on
Win32 platform.
Also I fixed Korean entry by changing "kana" to "hang",
but Batang (bundled to Microsoft Windows) have other
problems, and I will submit another set of patches.
Regards,
mpsuzuki
On Mon, 26 Mar 2012 19:10:16 +0900 (JST)
Koji Otani <[email protected]> wrote:
>Because I had not enough knowledge about Chinese and Korean fonts, I
>think.
>I'll appreciate it if you would fix them.
>----------
>Koji Otani
>
>From: suzuki toshiya <[email protected]>
>Subject: Why TrueType vertical glyphs for Adobe-CNS1, -GB1, -Korea1 use "kana"
>script tag?
>Date: Mon, 26 Mar 2012 18:03:58 +0900
>Message-ID: <[email protected]>
>
>mpsuzuki> Dear Otani-san,
>mpsuzuki>
>mpsuzuki> During the testing for GlobalParamsWin.cc improvement with MinGW,
>mpsuzuki> I found that the vertical glyphs for Adobe-CNS1, -GB1, -Korea1
>mpsuzuki> with external (non-embedded) TrueType fonts do not work well with
>mpsuzuki> Chinese/Korean TrueType fonts bundled to Microsoft Windows; SimSun,
>mpsuzuki> MingLiU and Batang.
>mpsuzuki>
>mpsuzuki> The reason is very clear; FoFiTrueType::setupGSUB() prepares the
>mpsuzuki> vert or vrt2 GSUB features for default language system and specified
>mpsuzuki> script. In current poppler, "kana" script tag is used in all cases
>mpsuzuki> of Adobe-CNS1, -GB1, -Korea1. But SimSun, MingLiU, and Batang fonts
>mpsuzuki> have no layout features for "kana" script tag (furthermore, these
>mpsuzuki> fonts do not know anything about "kana" script).
>mpsuzuki> The reason why "kana" is used always is because of your patch applied
>mpsuzuki> on 2007:
>mpsuzuki>
>mpsuzuki> commit 14a8361039d708661b8699b2e7c4496135021a85
>mpsuzuki> Author: Albert Astals Cid <[email protected]>
>mpsuzuki> Date: Fri Jul 13 22:18:05 2007 +0000
>mpsuzuki>
>mpsuzuki> * fofi/FoFiTrueType.cc
>mpsuzuki> * fofi/FoFiTrueType.h
>mpsuzuki> * poppler/CairoFontEngine.cc
>mpsuzuki> * poppler/CharCodeToUnicode.cc
>mpsuzuki> * poppler/CharCodeToUnicode.h
>mpsuzuki> * poppler/GfxFont.cc
>mpsuzuki> * poppler/GfxFont.h
>mpsuzuki> * poppler/SplashOutputDev.cc: Patch by
>mpsuzuki> Koji Otani <[email protected]> to fix several problems with
>Japanese fonts.
>mpsuzuki> Fixes bug 11413
>mpsuzuki>
>mpsuzuki> Could you explain the background why you used "kana" for all cases?
>mpsuzuki> Or, you can list the fonts that you used for testing your patch in
>2007.
>mpsuzuki>
>mpsuzuki> I think using "hani" for Chinese, "hang" for Korean is safer, but
>mpsuzuki> if there are many Chinese/Korean fonts using "kana" script tag (and
>mpsuzuki> not using "hani" or "hang" tags for vertical shaping), more
>enhancement
>mpsuzuki> for vertical glyphs is needed. I will work for it.
>mpsuzuki>
>mpsuzuki> Regards,
>mpsuzuki> mpsuzuki
>mpsuzuki>
diff --git a/poppler/GfxFont.cc b/poppler/GfxFont.cc
index ac4942d..fe908b7 100644
--- a/poppler/GfxFont.cc
+++ b/poppler/GfxFont.cc
@@ -2237,13 +2237,13 @@ int *GfxCIDFont::getCodeToGIDMap(FoFiTrueType *ff, int *mapsizep) {
} CMapList[] = {
{
"Adobe-CNS1",
- "kana",
+ "hani",
"Adobe-CNS1-UCS2",
adobe_cns1_cmaps,
},
{
"Adobe-GB1",
- "kana",
+ "hani",
"Adobe-GB1-UCS2",
adobe_gb1_cmaps,
},
@@ -2261,7 +2261,7 @@ int *GfxCIDFont::getCodeToGIDMap(FoFiTrueType *ff, int *mapsizep) {
},
{
"Adobe-Korea1",
- "kana",
+ "hang",
"Adobe-Korea1-UCS2",
adobe_korea1_cmaps,
},
_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler
