[TLContrib] How do I properly modify an existing map file?

Norbert Preining preining at logic.at
Mon Mar 26 15:31:17 CEST 2012


Hi Leo,

good to hear about your efforts!

On Mo, 26 Mär 2012, Leo Liu wrote:
> I am familiar enough with updmap, 

good.

> On the other hand, I need to change texfonts.map, which is a kpathsea faculty to set font name mapping for TFM (c.f. CTAN://info/doc-k/kpathsea.pdf). There is not such a utility to update texfonts.map, thus I wrote one for my package. AFAIK, zhmCJK is the only one package to use texfonts.map.

I still don't understand why you need that, but I trust you.

> Besides texfonts.map, there're also other font mappings that cannot be handled by updmap utility. For example, dvipdfmx uses cid-x.map for TrueType and OpenType CID fonts,

That will change *COMPLETELY* with TL2012. In collaboration with
Japanese TeX group I have worked on support for different font sets
etc. We will have an implicit setting for embedding Kanji with variants,
set in the updmap.cfg file, for example
	kanjiEmbed	hiragino
	kanjiEmbed	-04
will select the map files
	ptex-hiragino-04.map
	uptex-hiragino-04.map
	otf-hiragino.map
	otf-up-hiragino.map
for creating a map file 
	kanjix.map
which is used by dvipdfmx.

These entries come from addMap entries called:
	otf- at kanjiEmbed@.map
	otf-up- at kanjiEmbed@.map
	ptex- at kanjiEmbed@@kanjiVariant at .map
	uptex- at kanjiEmbed@@kanjiVariant at .map
(in different packages) and the respective strings are replaced
at updmap-sys run time with the settings in updmap.cfg

Furthermore, there will be a multi-updmap in TL2012 (and is already
in Debian/sid) that reads *ALL* updmap.cfg.


For details on the Japanese support, please see:
http://tutimura.ath.cx/ptexlive/?tlptexlive%A5%EA%A5%DD%A5%B8%A5%C8%A5%EA


> BTW, do I have to use perl script for a postaction, or I can use a Lua script? (It doesn't matter.)

YOu can use both, the tlmgr runner checks for
	.pl extension -> run it with perl ...
	.texlua -> run it with texlua ...
anything else needs to be excutable as is, ie it is run with system (from perl).

BUT: please wait .. I *really* would prefer a different solution. 
If I understand the problem, I can adapt the TeX Live infrastructure
to cater for all these problems .... I did it for Japanese, and we
can work on a proper solution for all the idiographic languages.

> But it is useful for my package --- and it is one of the core techniques of the package.

Ok, I see. Can you still explain me what you want to achieve? I have
solved similar problems in cooperation with the Japanese group, who
have very similar requirements (if not more complex, since they
mix several scripts, in both horizontal and vertical).

> A CJK font (via CJK package) is split into hundreds of individual ones. For example,
> when you use `kai' font family in the C70 font encoding under CJK package, CJK characters
> (like 汉字) would refer to 256 TFM files:

Ahh, that is you use plain tex/etex/pdftex. It would be interesting for
you to also look into (u)ptex that provides proper handling of Kanji/Hanzis
in different settings, but I guess that is an old story for you.

> A very important feature is that all CJK ideograms are square, and usually have the same
> size (width and height). It is not necessary to produce different TFM files for every fonts.
> The zhmCJK package let the different Chinese fonts share only one TFM file, and use TFM
> font mapping instead of reproducing them time and time again. That's why I need to use
> texfonts.map faculty.

Ahh, so you are doing the rewrite from tfm names to actual font names
in texfonts.map. Nice idea.

The Japanese have used since long different embeddings. SO you create
one dvi, and using dvipdfmx you can select various different map files,
or pre-set ones, to use the font you like.


> zhmCJK is not installed in TeX Live, and we (the ctex-kit project) plan to merge current
> zhmCJK package and zhmetrics package. Then it will be deleted from tlcontrib.

We should discuss this NOW!!!! Together with everyone interested, I can
bring some of the Jpanese developers into it, and maybe we can get
some Korean, too.

The point is, we should find a nice solution that works *across* most
of the engines/writing styles/languages.

> I'm sorry that the document of zhmCJK is written only in Chinese and the problem we meet
> is not typical in other languages. And I won't explain all the special techniques used in the
> package here. But I think it would suffice.

I would listen to your explanations with pleasure, if you don't mind.
And - also depending on where you live - we could organize a in-person
meeting. I am based in northern Japan near the Japanese sea, so not
far from China.

Let us work out a good solution for all that.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining            preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan                                 TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
SMARDEN (vb.)
To keep your mouth shut by smiling determinedly through you
teeth. Smardening is largely used by people trying to give the
impression that they're enjoying a story they've heard at least six
times before.
			--- Douglas Adams, The Meaning of Liff


More information about the TLContrib mailing list