Re: [cjk] [mailman] texlive svn write access Fw: Re: revisiting ttf2tfm and dvipdfmx

[Hin-Tak Leung]

Peter Breitenlohner wrote:
> On Thu, 18 Jul 2013, Hin-Tak Leung wrote:
>
> > > > The command line is simply:
> > > > ttf2tfm wcl-01.ttf -P 3 -E 4 -q -w   address@hidden@
> > >
> > > but didn't mention that the same font caused indeterminism!
> > >
> > > Peter
> >
> > I did, in the same e-mail where the above first appear, further down - here it
> > is, again, in full - Note "The two fonts mentioned above, ...":
>
> OK, I have just tested this. Running ttf2tfm (FreeType 1) three times in
> exactly the same way gave identical results for subfonts 01-54 and a
> segfault for subfont 55.  Doing the same with a copy of ttf2tfm in a
> different directory gave different .tfm files.  Converting them to .pl files
> shows why that is so: the TFM header contains the command line, including
> the relative or absolute path to ttf2tfm and they may differ.  Removing
> header bytes >=18 from the .pl files gives identical results.

Thanks.

By indeterminism, I did not mean the outcome differs from 10 years ago, but
that the outcome differ between two recent and consecutive runs separated by not 
more than a few hours or days. I have a 10-year-old script which I
am adding new fonts to, and as a side-effect of adding new font entries,
every font old and new get processed again, and the tfm files shows up 
differently, since all the generated files now sit on top of git. the old public 
version - cjk/doc/pdfhowto/examples/gen-map.pl have only about 90 font
instance entry, more than half of that open or public fonts - the first 50 or so 
entries are publicly available fonts - at least at a time in the past. e.g. the 
Taiwanese government [the 7-11th fonts on that list] now provide a completely 
different set of 4-5 fonts, more interesting and varied type-face wise than the 
old, but I don't see those old fonts posted any more.
(the script I have has 460 entries and still growing).

In case it is important, fedora has some sort of system-wide security feature 
whose name I forgot, controlled by the environment variable MALLOC_PERTURB_ 
which you can look it up on. I don't know if your system has that. As far as I 
remember the feature initialises uninitialized memory differently each time a 
binary is launched (and can be switched off by unsetting MALLOC_PERTURB_ if it 
proves bothersome). If the indeterminism disappears if I switchs that off, all 
it says is that ttf2tfm is writing some uninit'ed memory to output files, and 
therefore does random things when this feature is on. Since ttf2tfm is not 
supposed to write uninit'ed memory to output (very few programs are supposed 
to!), I am not going to look into that possibility; but it might help you 
tracking the indeterminism down if that's important and you can find equivalent 
dev aids.